bug#4708: 23.1; completion-try-completion adds an extra $: $$HOMj

[Drew Adams]

> That try-completion will return nil when applied to "/foo/bar/$$HOMj",
> so basically the $HOMj -> $$HOMj is considered to be a form 
> of completion.

Sorry, I don't follow that. Could you say it differently? And did you mean
try-completion or completion-try-completion? Sorry, I don't know what you mean
here.

> That decision is taken by read-file-name-internal.  Can you try the
> patch below to see if it improves the behavior?

Yes, it seems to fix the problem. Thanks.

> Note that a completion table might very well allow completion 
> from /u to /usr/ even if none of the files in /usr/ are
> acceptable completion candidates.  I.e. try-completion may
> sometimes return a string even if there is no real valid
> completion with that prefix.  This is simply because it may
> be too costly for the function to verify it (e.g. having
> to traverse the whole /usr/ subtree).

I understand.

The problem is not so much what is done and the given trade-offs chosen for a
case like that. The problem is to keep users in control - at the very least
giving them knowledge of what the story is. If the command in question tells
users just what you said, then they can know what to expect and can act en
connaissance de cause.

What's not good is to surprise users or keep them guessing about what's
happening and why. This is a problem with DWIM generally. It's no big deal for
something inconsequential, but it can matter where user actions depend on the
result.

Users need to have a reasonable mental model of the behavior (which need not
reflect how things are actually implemented, of course).

Part of helping them in this respect is providing feedback. I've said before
that partial completion can be surprising and confusing - that's nothing new.
But what's worse is that we slip silently from one kind of completion attempt to
another, and another.

We don't say, "No prefix completions found. Do you want to try now for partial
completions?". After running down an unknown number of completion methods under
the covers, we don't even let the user know at the end which method was
ultimately successful.

The user has no way of knowing what kind of completion was actually used, which
means no good way of determining how the result relates to his input.

This can make him lose confidence in his mental model, his general understanding
of the program, and ultimately himself. We should be empowering users, not
making them feel like they're not in control or have no idea what's going on.

Sure, sometimes it doesn't really matter. You don't need to know the details
about how Google finds what it finds - as long as the results seem sensible to
you most of the time. I believe that with the latest completion enhancements
Emacs users are too often confused and surprised, and that we could do a better
job of helping them understand - at least what happened and why.

Anyway, this bug seems to have been fixed - thx.