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: Sun, 30 Dec 2007 00:05:18 +0100 Message-ID: <87y7bdp0ep.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 1198969637 16583 80.91.229.12 (29 Dec 2007 23:07:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 29 Dec 2007 23:07:17 +0000 (UTC) To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 30 00:07:31 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 1J8km9-00022K-JU for ged-emacs-devel@m.gmane.org; Sun, 30 Dec 2007 00:07:29 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8klo-000465-80 for ged-emacs-devel@m.gmane.org; Sat, 29 Dec 2007 18:07:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J8klk-00042J-AT for emacs-devel@gnu.org; Sat, 29 Dec 2007 18:07:04 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J8klf-0003qJ-EL for emacs-devel@gnu.org; Sat, 29 Dec 2007 18:07:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J8klf-0003q6-Ah for emacs-devel@gnu.org; Sat, 29 Dec 2007 18:06:59 -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 1J8kle-0002Lf-P7 for emacs-devel@gnu.org; Sat, 29 Dec 2007 18:06:59 -0500 Original-Received: from ttn by ambire.localdomain with local (Exim 4.63) (envelope-from ) id 1J8kk3-0003O7-18 for emacs-devel@gnu.org; Sun, 30 Dec 2007 00:05:19 +0100 In-Reply-To: (Drew Adams's message of "Sat, 29 Dec 2007 10:14:57 -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:85642 Archived-At: () "Drew Adams" () Sat, 29 Dec 2007 10:14:57 -0800 If that is the intention, then, yes, it should be not only semantically but also practically distinguished from the rest of the string (which is presentation-ready). IOW, we should have separate retrieval functions for the doc string per se and the interface spec (signature). what you seek has been done, just not where you seek it. the function `documentation' is called by others that make this distinction. why don't you look at using those, instead? are they deficient in some way? if they are not, will changing `documentation' behavior make them so? will you fix those bugs then? i think if you let go of the desire to have `documentation' work like these other functions, you may find the other functions readily suitable for your needs. The only way currently to recuperate the doc string gives you all of it, including the part you consider not to be part of the doc string but "markup". i don't see that as a problem. the required treatment of that string, to separate the parts, is not onerous. if it feels onerous, no worries, see my point above. If that last line (interface spec) is not part of the doc string, and you want to keep it unfilled because filling is presentation, then `documentation' (or some other function) should return only the doc string per se, not the whole kit and caboodle. Especially since `documentation' is written in C, so it can't be hacked without rebuilding Emacs. you seek to change code, but what is better is to change your view of the data that the code returns. since the data is regular, any wrangling required to fit it to your requirements can be purely additive. isn't that tantalizing enough for you? IOW, either the "interface spec" is part of the doc string or it is not. If it is, then it too should be presentation-ready, like the rest of the string. If it is not, then we should have a separate function that gives us only the doc string (without interface spec). i see many SHOULD in your argument, but i don't understand why. here are two perlis quotes that are relevant: If a program manipulates a large amount of data, it does so in a small number of ways. -- Alan Perlis It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures. -- Alan Perlis i'm afraid i cannot communicate the elegance of the current system, but only my fear that you are proposing to wreak it. thi