bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#4718: 23.1; C-h f gives doc for the wrong function


From: Drew Adams
Subject: bug#4718: 23.1; C-h f gives doc for the wrong function
Date: Tue, 13 Oct 2009 21:24:12 -0700

> You're saying that you would rather it didn't work for `dolis' <RET>
> either, then.

No, I'm not saying that. I have no problem with the behavior of Emacs 22 and
before.

Letting RET complete using prefix completion is not problematic in the way that
letting it do so with partial completion is. With only prefix completion, `dolis
RET' can only complete to something that has `dolis' as a prefix. When there is
only one such completion, it is not very hard to guess what that is.

That is, with prefix completion the gap between what is known (the input) and
what is unknown (the completion) is small and predictable. If you choose to hit
RET, it's because you pretty much know what you're going to get.

That's especially true, the longer the input. In the case I gave,
`dired-byte-compile', the input is already quite long for a function name. That
means both (a) it is unlikely that the sole completion would be much longer and
therefore hard to guess and (b) it is not unreasonable for both the program and
the user to consider the input as pretty much the whole function name.

IOW, RET, with the meaning "this is what I want" fits well here. RET in that
sense does not fit well with partial completion, where your input could complete
to pretty much anything. You have very little knowledge of what the completions
are. We've already seen bizarre examples of typing one thing and getting
something totally unforeseen as a result. I don't think anyone denies that.

The point is that that unknown is more or less controllable by users when TAB is
involved. They see the result before entering it or cancelling. RET is another
story altogether. You cannot have a good idea what will happen when you push
that big red button.

I suppose the end result will be that users will eventually learn to hit TAB RET
systematically instead of RET. I would rather see the program make them jump
through such a hoop (confirm) only when it's really needed. That is, only when
using partial completion, since prefix completion has never posed a problem in
this regard.

That's one solution I see: not ask for confirmation except when the completion
does not have the input as a prefix. (By input, I mean modulo directory name, $
for env vars, etc.) IOW, treat the problem only where it is - there is no
problem for the classic prefix completion.






reply via email to

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