From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Miles Bader Newsgroups: gmane.emacs.devel Subject: Re: Documentation for "Clone Buffers" (corrected version) Date: Sat, 20 Mar 2004 14:27:09 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <20040320192709.GA31243@fencepost> References: <200403201415.i2KEFNq19043@f7.net> <7494-Sat20Mar2004171547+0200-eliz@elta.co.il> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1079811227 885 80.91.224.253 (20 Mar 2004 19:33:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 20 Mar 2004 19:33:47 +0000 (UTC) Cc: juri@jurta.org, emacs-devel@gnu.org, Karl Berry Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Sat Mar 20 20:33:40 2004 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1B4mE0-0008BO-00 for ; Sat, 20 Mar 2004 20:33:40 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1B4mE0-0003al-00 for ; Sat, 20 Mar 2004 20:33:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4mCh-0000t1-TC for emacs-devel@quimby.gnus.org; Sat, 20 Mar 2004 14:32:19 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.30) id 1B4mCJ-0000rl-JS for emacs-devel@gnu.org; Sat, 20 Mar 2004 14:31:55 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.30) id 1B4mBm-0000ko-3G for emacs-devel@gnu.org; Sat, 20 Mar 2004 14:31:53 -0500 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.30) id 1B4mBl-0000ka-Sc for emacs-devel@gnu.org; Sat, 20 Mar 2004 14:31:21 -0500 Original-Received: from miles by fencepost.gnu.org with local (Exim 4.24) id 1B4m7h-00019V-En; Sat, 20 Mar 2004 14:27:09 -0500 Original-To: Eli Zaretskii Content-Disposition: inline In-Reply-To: <7494-Sat20Mar2004171547+0200-eliz@elta.co.il> User-Agent: Mutt/1.3.28i Blat: Foop X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.4 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:20649 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:20649 On Sat, Mar 20, 2004 at 05:15:47PM +0200, Eli Zaretskii wrote: > > Not all library functions are in libc. > > If you refer to additional libraries, I think a programmer has a good > knowledge in what library each function lives. After all, it's the > same programmer who needs to add a -lFOO switch to the link command > line. I think you would be surprised... :-) Another problem is that the name of the manual is often not the name of the library. Consider a toolkit that come with 34 different libraries (which normally you just always link against); it's fairly likely that it comes with just one info manual covering everything. This is probably good: the programmer is more likely to think of the function as being in `that toolkit', than he is to quickly remember which library it's in (though he can probably figure it out). Anyway, the point is that the mapping is often fuzzy, and the man command arguably is doing the right thing by just ignoring the whole issue -- library functions usually try to be fairly unique anyway, so why not take advantage of that and reduce the burden on the programmer when looking up documentation? [A similar issue occurs with command packages -- should the user have to remember that the foo command is in the net-utils or the shell-utils package? No, but it's annoying to have the info index filled up with command names too.] -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia