[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Documentation for "Clone Buffers" (corrected version)

From: Miles Bader
Subject: Re: Documentation for "Clone Buffers" (corrected version)
Date: Sat, 20 Mar 2004 14:27:09 -0500
User-agent: Mutt/1.3.28i

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

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

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

[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.]

Somebody has to do something, and it's just incredibly pathetic that it
has to be us.  -- Jerry Garcia

reply via email to

[Prev in Thread] Current Thread [Next in Thread]