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: Fri, 28 Dec 2007 19:23:20 -0800 Message-ID: References: <87bq8ajkfm.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 1198898620 5807 80.91.229.12 (29 Dec 2007 03:23:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Dec 2007 03:23:40 +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 04:23:53 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 1J8SIi-0003pX-3u for ged-emacs-devel@m.gmane.org; Sat, 29 Dec 2007 04:23:52 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8SIM-0003F5-Qt for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2007 22:23:30 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8SII-0003Bw-Iq for emacs-devel@gnu.org; Fri, 28 Dec 2007 22:23:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8SIH-00038w-4x for emacs-devel@gnu.org; Fri, 28 Dec 2007 22:23:25 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8SIG-00038W-V5 for emacs-devel@gnu.org; Fri, 28 Dec 2007 22:23:25 -0500 Original-Received: from agminet01.oracle.com ([141.146.126.228]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J8SID-00026M-7c; Fri, 28 Dec 2007 22:23:21 -0500 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by agminet01.oracle.com (Switch-3.2.4/Switch-3.1.7) with ESMTP id lBT3NIHk026235; Fri, 28 Dec 2007 21:23:18 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lBT2kuwA006387; Fri, 28 Dec 2007 20:23:18 -0700 Original-Received: from dhcp-amer-csvpn-gw1-141-144-64-21.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3468275091198898590; Fri, 28 Dec 2007 19:23:10 -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: <87bq8ajkfm.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:85583 Archived-At: > > Could this please be fixed, so that functions such as > > `documentation' and `documentation-property' return a > > doc string that has reasonable-length lines? Thanks. > > 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. 1. It's not so easy in my particular context. But this is not about me. It's about any code that uses doc strings (and cares about line length). 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? 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? An ounce of prevention is worth a pound of cure. 3. We have already added code to the `describe-*' commands to fix this at their end. Fixing the problem where this text is automatically added to the doc string, instead, will fix it for any and all code that uses doc strings, present and future. And the band-aid code can then be removed from the help functions, where it never really belonged anyway. Doc strings are important, general constructs; they are not only for this or that already existing `describe-*' command (or apropos command or...). That was the wrong place to fix the problem, but it took me a while to discover that.