emacs-devel
[Top][All Lists]
Advanced

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

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


From: Eli Zaretskii
Subject: Re: Documentation for "Clone Buffers" (corrected version)
Date: Sat, 20 Mar 2004 16:04:33 +0200

> Date: Fri, 19 Mar 2004 12:47:25 -0500
> From: address@hidden (Karl Berry)
> 
> Although automatically looking in libc's index would probably work for
> 90% of cases in practice, it does not solve the general problem.

I'm not even sure it solves 90% of cases, unless all of the cases
come from libc functions lookup.

>     My model here is `man' 
> 
> I agree, we need a procedure for this that works as well as man's does,
> without having to load thousands of dir entries by default.

But the Info system is _not_ `man', so some problems don't have a
solution that works as ``well'' as `man' does.

> Thus my original idea (although I guess I did not fully explain it):
> 1have one subnode of dir for commands, one for library functions, one for
> file formats, etc., analogous to the man sections.  Keep the top level
> dir itself for the manuals as a whole.

That would work, but do we really have the power to enforce such an
organization of DIR?  Unlike `man', the Info manuals are not written
by the same person/team, so coordinating all of them is much more
difficult.  Even the current guidelines that Karl tries to promote for
quite a few years now are not yet as widespread as we'd like them to
be.

> Then  info commands printf
> vs. info functions printf
> will get the right thing.  That is, from the cmd line.  I don't know
> what the best interface would be for Emacs.
> 
> As a bonus, we could make
>   info 1 printf
> also work by letting `1' mean the first menu entry on the cmd line (as
> it does interactively)!

I'd suggest instead to invest efforts in producing an Info
`apropos'-style database, so that "info printf" could search all of
the Info manuals in reasonable time.  This is localized to the Texinfo
pacakge (assuming Emacs asupports that as well), so its introduction
would be much easier.




reply via email to

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