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

[Drew Adams]

> > > I really doubt that many people would use `:foo' instead of
> > > `foo' to look for the keywords.

Seems like the most natural thing, to me. If you want to look up "bobsled",
you type "bobsled"; you don't type "obsled".

> > > 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?

I would look up the keyword :type by entering its name, ":type". I think
most users would.

`'type', or `(quote type)', is not the keyword, and neither is `type'. The
keyword is the symbol `:type', that is, the symbol whose name is ":type"
(not "type").

> > 2) Looking up ":type" as opposed to "type" is in no way
> >    analogous to looking up "'keymap" as opposed to "keymap".
>
> Well, then maybe we have quite different perceptions of
> the Emacs Lisp syntax and semantics.

Perhaps we have. What is your perception of this?

(symbol-name :type)  => ":type"
(symbol-name ':type) => ":type"
(symbol-name 'type)  => "type"

(symbol-value :type)  => ":type"
(symbol-value ':type) => ":type"
(symbol-value 'type)  => Error, void variable type

The symbol whose name is ":type" has itself as its value. And this is not
the same symbol as the symbol whose name is "type" (and which has no
predefined value). The latter is not a keyword.

> The colon plays a role that is very similar to
> the quote: it is used to mean the literal symbol name as opposed to
> the value of the symbol.

The literal symbol name of :type is ":type". It is not "type".

The colon is part of the name; it is not just a quoting mechanism.
Evaluation to self is not implicit quotation: (eval (eval (eval :foo))) is
:foo, but (eval (eval (eval 'foo))) is usually something quite different
from `foo'.

Keywords are constant symbols - symbols that evaluate to themselves, just
like t and nil. Would you say that there is an invisible quote-like thingy
in front of t and nil that although we can't see it "is used to mean the
literal symbol name as opposed to the value of the symbol" t or nil?

> > 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.
>
> That's not what I'd suggest to do in this situation.
> I'd suggest to type "i link TAB".

Good point. To find the index entry for `:type' users can hit `type TAB'
instead of `:type RET'. Fair enough. But you know, some users just might not
think to do that. After all, if they've used Emacs before version 22 (which
introduced index-entry completion), then they just might not be in the habit
yet.

Don't get me wrong - I'm happy we have the `type, defcustom keyword'
workaround. But some users might never use TAB here and so never notice it.
Or, like me, they might have learned about it but they might forget it
occasionally - old habits die hard. And, even if they do notice and do
remember, they might not know the intimate details about Info's colon
difficulties (!), so they might naturally try `i :type TAB', with no match
and no message teaching them their mistake.

So, let's draw user attention to the workaround. I repeat my previous
suggestion about displaying a helpful message when the user enters a keyword
name such as `i :foobar' (i.e. with a colon), whether with TAB or RET, but
amend it to suggest that they use `i foobar, defcustom keyword'. (I withdraw
my suggestion of suggesting `s :foobar'.) IOW, if Info can't handle colons,
but users don't know that and might well try to use them, then let's inform
them how to get the job done.

It's not ideal for completion to give the impression that the keyword is
`type' when it is really `:type' ("type, defcustom keyword"), but at this
point it seems unavoidable. I hope this can be fixed in the future.