From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.emacs.devel Subject: Re: (fn ...) - please fill it at the point of generation Date: Sat, 29 Dec 2007 18:08:49 +0100 Message-ID: <87d4spqvha.fsf@ambire.localdomain> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1198948245 24410 80.91.229.12 (29 Dec 2007 17:10:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Dec 2007 17:10:45 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 29 18:10:57 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 1J8fD6-00035F-Ie for ged-emacs-devel@m.gmane.org; Sat, 29 Dec 2007 18:10:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8fCl-0003Q9-5i for ged-emacs-devel@m.gmane.org; Sat, 29 Dec 2007 12:10:35 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8fCh-0003Nq-3Z for emacs-devel@gnu.org; Sat, 29 Dec 2007 12:10:31 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8fCf-0003Kv-Cs for emacs-devel@gnu.org; Sat, 29 Dec 2007 12:10:30 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8fCf-0003Kl-7N for emacs-devel@gnu.org; Sat, 29 Dec 2007 12:10:29 -0500 Original-Received: from ppp-64-39.21-151.libero.it ([151.21.39.64] helo=ambire.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1J8fCe-0003Z3-Rc for emacs-devel@gnu.org; Sat, 29 Dec 2007 12:10:29 -0500 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1J8fB3-0002RH-Gu for emacs-devel@gnu.org; Sat, 29 Dec 2007 18:08:49 +0100 In-Reply-To: (Drew Adams's message of "Sat, 29 Dec 2007 07:53:36 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gnu/linux) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:85617 Archived-At: () "Drew Adams" () Sat, 29 Dec 2007 07:53:36 -0800 What's the advantage of having one line in a doc string that doesn't fit the doc-string pattern (convention)? How is that more general and less of a special case? "one line" to munge is more general than "one form". put another way: more tools know how to parse the former than the latter. we want to be nice to tools (for now; one hopes some day they will reciprocate the kindness :--). the "docstring pattern (convention)" is applicable for viewing the docstring. although the part under discussion is technically included in the "string", it should be semantically distinguished from the rest of the string because it is not intended for direct viewing. that part is markup, requiring further processing at the presentation stage. to conflate the presentation and the generation is a step towards bad design. a good middle path would be to pool common presentation methods, as long as those methods are not imposed on the phases uninvolved w/ presentation. keep the phase sep, bro! thi