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: (fn ...) - please fill it at the point of generation Date: Fri, 28 Dec 2007 13:38:17 -0800 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1198877994 24670 80.91.229.12 (28 Dec 2007 21:39:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Dec 2007 21:39:54 +0000 (UTC) To: "Emacs-Devel" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 28 22:40:08 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 1J8Mvu-0006mi-Cb for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2007 22:39:58 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8MvZ-0003IM-75 for ged-emacs-devel@m.gmane.org; Fri, 28 Dec 2007 16:39:37 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8MvU-0003He-MJ for emacs-devel@gnu.org; Fri, 28 Dec 2007 16:39:32 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8MvS-0003Gi-KZ for emacs-devel@gnu.org; Fri, 28 Dec 2007 16:39:31 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8MvS-0003GY-AH for emacs-devel@gnu.org; Fri, 28 Dec 2007 16:39:30 -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 1J8MvR-0002LK-TT for emacs-devel@gnu.org; Fri, 28 Dec 2007 16:39:30 -0500 Original-Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id lBSLdRCY000427 for ; Fri, 28 Dec 2007 14:39:27 -0700 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id lBSDj1X6004634 for ; Fri, 28 Dec 2007 14:39:26 -0700 Original-Received: from dhcp-amer-whq-csvpn-gw3-141-144-81-155.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3468062201198877890; Fri, 28 Dec 2007 13:38: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 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:85563 Archived-At: IIUC, it is make-docfile.c that adds the "(fn ..)" to a doc string, which causes the displayed documentation to show the function's signature. A while ago, I asked that this printed signature be wrapped. My motivation was that a very long line can throw off window-fitting and frame-fitting that might measure the longest line length, resulting in, say, wasted frame space. This was fixed - thanks. However, I also recuperate doc strings using function `documentation' and present them as completion candidates, and in this case the signature is still one long line. I would like the filling to be done at the point where the (fn...) is generated, not just when it is displayed by `C-h f'. The entire doc string is correctly within reasonable width limits, except for this one line, which can get way out of hand. Here, for instance is the (fn...) line for function `quail-define-package' (the mailer will fill it, but imagine it unfilled): (quail-define-package name language title &optional guidance docstring translation-keys forget-last-selection deterministic kbd-translate show-layout create-decode-map maximum-shortest overlay-plist update-translation-function conversion-keys simple) That's a line length of 250 characters! AFAIK, the only purpose of this signature string is for documentation, that is, for contexts in which a normal line length is expected. The fact that it can be essentially limitless is, to me, a bug - it doesn't fit its use in a doc string. Could this please be fixed, so that functions such as `documentation' and `documentation-property' return a doc string that has reasonable-length lines? Thanks.