From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: (fn ...) - please fill it at the point of generation Date: Sat, 29 Dec 2007 07:53:17 -0800 Message-ID: References: <8763yhk4nn.fsf@catnip.gol.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1198943613 11197 80.91.229.12 (29 Dec 2007 15:53:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Dec 2007 15:53:33 +0000 (UTC) Cc: Emacs-Devel To: "Miles Bader" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 29 16:53:46 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1J8e0P-0005sY-G5 for ged-emacs-devel@m.gmane.org; Sat, 29 Dec 2007 16:53:45 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8e04-00041u-Bd for ged-emacs-devel@m.gmane.org; Sat, 29 Dec 2007 10:53:24 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8dzz-0003zY-Q8 for emacs-devel@gnu.org; Sat, 29 Dec 2007 10:53:19 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8dzy-0003xC-0K for emacs-devel@gnu.org; Sat, 29 Dec 2007 10:53:18 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8dzx-0003wv-Q3 for emacs-devel@gnu.org; Sat, 29 Dec 2007 10:53:17 -0500 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J8dzt-0002oy-4p; Sat, 29 Dec 2007 10:53:13 -0500 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lBTFrA1R008540; Sat, 29 Dec 2007 08:53:11 -0700 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lBTEqXAC026646; Sat, 29 Dec 2007 08:53:10 -0700 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-21.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3468937081198943586; Sat, 29 Dec 2007 07:53:06 -0800 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal In-Reply-To: <8763yhk4nn.fsf@catnip.gol.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:85613 Archived-At: > >> Why don't you just wrap them yourself, in the code that calls > >> `documentation'? Wrapping is, in general, a display thing, so it > >> seems best to not add hair in more primitive code to worry about it. > > > > Why change all such code, instead of preventing the bug in the > > first place? Code that generates user doc should be smart > > enough to respect the GNU Emacs convention for line length. > > What's the big deal? > > Why do you assume that applications _want_ it wrapped? It's a doc string. All lines in a doc string follow a convention, including being within a max length. Why should this be the only exception? > It's really not part of the doc string as such, it's an interface > description. That's a good feint. This part of the doc string isn't right, so to fix things we'll just say it's not part of the doc string. I don't agree. It is served up with `documentation' - there is no way around that, except to try to parse the doc string after retrieval to remove that part. If it is not part of the doc string, then leave it out of `documentation', and have a separate function to retrieve only the interface spec. > Wrapping it simply introduces extra noise. Needing to wrap it in multiple places (`describe-*',...) instead of one because it was not written correctly in the first place introduces far more noise. > > 2. Pretty much all other lines of every doc string are correct in this > > regard. Why should this be the lone exception and force all > > code that uses doc-strings to patch things up after the fact? > > See above. Oh, you mean where you simply declare it not to be part of the doc string?