GNU bug report logs -
#20105
25.0.50; Emacs manual, `i HOME RET' sends you to `Moving Point', which is wrong
Previous Next
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Sat, 14 Mar 2015 02:37:01 UTC
Severity: minor
Found in version 25.0.50
Done: Drew Adams <drew.adams <at> oracle.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> Yes, "emacs -Q" here. And it's not a surprise you have those missing
> candidates in the index, that's how I can see them ;-)
>
> Are you sure you did 'i home TAB' in the latest manual, though?
Yes, exactly that, in this build:
In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
of 2015-02-27 on LEG570
Repository revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'
> > > > But why is `HOME' capitalized as a candidate if it points to info
> > > > about the key?
> > >
> > > Don't know. Looks like some feature of completion.
> >
> > Really? My guess is instead that it comes from this explicit index
> > entry (which I see in Emacs 24 but not 23): (I removed some whitespace.)
> >
> > * HOME: Moving Point. (line 57)
>
> By "feature" I meant that it replaces "home" which I typed by "HOME",
> for whatever reasons. The _only_ reason that I could accept as
> legitimate is if _all_ completion candidates started with an
> upper-case "HOME". But that's not what we have here. So it looks
> like some attempt at being smart is misfiring.
Yes, I guess so.
But I'm guessing that what happens might have to do with searching the
indexes in order, where Key Index comes first. And in that index,
`HOME' is the only entry matching input `home'. It is also the only
matching entry in the Variable Index.
> > That's from the Key Index. However, note that there are also these
> > two entries in the Variable Index, which seem not to be used when
> > I do `i home TAB':
> >
> > * HOME: General Variables. (line 59)
> > * HOSTNAME: General Variables. (line 70)
>
> HOME _is_ used, except that completion removes duplicates (I guess).
I guess so too. That is a mistake. The calling function should
decide whether completion should remove duplicates (IMHO). And in
this case, it should not (IMHO).
> As for HOSTNAME -- why should it be used? I don't see it used here.
My bad for mentioning HOSTNAME. Might have been a copy&paste error.
Or it might have reflected a senior moment.
> > From what I see, the only explicit index entries that include `HOME'
> > (capitalized) refer to the home directory, not to the <home> key.
>
> No, the entry that revers to "Moving Point" is also capitalized.
Right. Do you agree that that is wrong? I doubt that that is the
only problem here. But it would be a start, to fix that entry.
It should be changed to something like `home keyboard key' or `home
key (keyboard)', I think.
(We might also want to add an entry for `<home> keyboard key'.)
Also, I question whether the quote marks should be included in these
two index entries:
* 'HOME' directory on MS-Windows: Windows HOME. (line 6)
* 'HOME' directory under MS-DOS: MS-DOS File Names. (line 35)
Et voila: That's probably why typing `host' does not match either of
these entries. And it's perhaps why it does work for you: the curly
quotes are perhaps not present for you, in the indexes.
---
Interestingly, copying and pasting those into this mail shows them
as curly quotes, but in Info they appear to be straight. They are
LEFT SINGLE QUOTATION MARK etc. I guess it is the default Info font
that makes them appear straight.
But I thought that we had arranged to use the older makeinfo or
whatever, and that Emacs was arranging to keep simple backtick and
apostrophe in the produced Info buffers. No? I see now that Isearch
for ` or ' fails miserably in Info, wrt finding such quoted names.
This makes it hard for users who want to use keyboard keys ` and '
for searching. That's a clear regression in usefulness, IMHO.
This bug report was last modified 10 years and 131 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.