[Top][All Lists]

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

RE: address@hidden: RE: cannot find :enable in Elisp manualindex]

From: Drew Adams
Subject: RE: address@hidden: RE: cannot find :enable in Elisp manualindex]
Date: Tue, 29 May 2007 14:03:10 -0700

> > That's really too bad, if it's the case. Keywords are important
> > things to put in an index (not to mention the fact that some
> > languages to be documented might use colons in special ways).
> > If this is really not feasible, then users are reduced to
> > using search in Info to find a keyword
> > such as :type, :display, or :enable - pretty primitive
> Actually, I don't think it's so bad as you make it sound -- in the
> case of Emacs Lisp (as opposed to, for example, C++), because I really
> doubt that many people would use `:foo' instead of `foo' to look for
> the keywords.  After all, the colon is similar to the quote ' in Emacs
> Lisp, and you aren't going to lobby for indexing 'keymap or
> 'wrong-number-of-arguments, would you?


1) Info is not just for Emacs and Emacs Lisp.

2) Looking up ":type" as opposed to "type" is in no way analogous to looking
up "'keymap" as opposed to "keymap". I can't believe that you would suggest
such a thing.

> > (but still far better than visiting the many "type",
> > "display", "enable" etc. index entries).
> Please suggest how to qualify the index entries for the keywords that
> use such common words, so that they would clearly stand out in the
> list popped by TAB-completion.

I don't understand the request. I see no problem with showing ":type" in
*Completions*. Please explain.

You should be able to type ":type" (without the quotes) at the `Info-index'
prompt, and have it take you to a node that discusses :type.

> > Is there no way to escape a colon somehow, so that Info does
> > not interpret it?
> Sadly, no.

Dommage. That would be a useful enhancement.

> > I haven't used TeX/LaTeX/Texinfo for 20 years, but my memory of
> > LaTeX and Tex, at least, is of something very powerful and
> > flexible.
> TeX and LaTeX are powerful, but Texinfo is implemented by a very
> simple one-pass processor and a bunch of TeX macros, so it doesn't
> have a power that is anywhere near that.
> > Suggestion: If a user enters a colon at the `Info-index' prompt,
> > print a message saying 1) that the colon is being ignored, and
> > 2) you can, as an alternative, use search (`s' or `C-s') to
> > search the manual for a term that contains a colon.
> I think index search is so much more powerful that `s', even with the
> colon problem, that it's not a good idea to suggest `s'.

1: I agree with you 100% about the relative utility of `i' over `s' - in

2: I disagree with you 100% in the case of keywords. Try it. Pick one and
count how many keystrokes or whatever it takes to get you to a node that
actually discusses that keyword using both `i' and `s'. The latter wins
hands down.

With `i :link', you have to visit 17 index entries out of 20 before you get
to a node containing :link. But `s' with `:link' takes you immediately to a
node discussing :link - in fact, of course, all hits of `s :link' discuss
:link. Similarly for other keywords: With :tag you must visit 6 out of 6
`tag' entries to finally get to :tag; with :group 4/11; :load 19/42;
:require 4/5; :version 24/30.

Neither `i :enable' nor `i :keymap' in the Elisp manual will _ever_ get you
to a page with that keyword - they're not indexed at all. Of course, to find
that out for :keymap, say, you will need to visit all 45 entries and check
for ":keymap" in each one!

It's hard to imagine why you would "think index search is so much more
powerful that `s', _even with the colon problem_." Maybe we have different
ideas of "powerful".

#1 + #2: That's why I wrote: "users are reduced to using search
in Info to find a keyword". "Reduced to" in the sense of limited
functionality, because `i' is usually much better than `s' (when there is an
appropriate index entry). "Reduced to" also in the sense of forced to,
because `s' is better than `i' for keywords (sadly).

reply via email to

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