bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1

[Drew Adams]

> No you completely misunderstand, there's no relationship
> between the "prefix" stuff and the directory info that
> used to be fudged into PREDICATE.
> 
> That directory info that used to be passed in PREDICATE is
> now passed via buffer-local variables instead.

Right. I did misunderstand that. You use the boundaries thing to pass along the
context "(" for Info file name "(em", but you don't use it to pass the directory
for file-name completion - and I do see (and did, but forgot) how you pass the
directory in the latter case. My bad about that part.

I was following my analogy and thought that you did the same thing for both,
using the directory part as a boundary/contextual "prefix" of the relative file
name.

But IIUC, there is no invalidation of the invariants for file-name completion.
The directory used for completion is separate and kept separate from the input,
the completion candidates, and the completion result, which are all relative
names. The result of hitting RET for `read-file-name' is an absolute file name,
but the result of the completion itself - e.g. the result of
`read-file-name-internal', is just the relative name.

If you agree about that, then let's come back to "(em", which is a case, we
agree, where the invariants are currently invalidated. IIUC, you say it is a
case where the invariants *must* be invalidated. My question is why. Why
couldn't we treat this completion the same way we treat file-name completion?

I'm not saying that we must fix this for Info for Emacs 23.1 - I agreed that
such generalized Info completion is for the wishlist now. I'm only asking why it
shouldn't be the policy that the invariants are respected. Is there any case
where they logically *cannot* be respected?

I think that's what I'm missing: an example where there is no way to avoid a
mismatch between a completion per `try-completion' and a completion per
`all-completions'.

It seems to me that the invalidation for "(em" was introduced by treating "(" as
a prefix (using the boundaries mechanism) and not treating "(emacs)" the same
way we treat directories for file-name completion. That might be all we want to
do for now, but is Info completion a case where there is no choice but to
invalidate the invariants?

IIUC, completion of "(em" in Info now treats the "(" part as contextual boundary
info to be temporarily ignored while completing against a list of Info file
names. For that treatment, you use `boundaries'. 

And it is that treatment that introduces a difference between the completions of
`all-completions', which are Info file names such as "emacs-mime", and the
completions of `try-completions', which are names such as "(emacs-mime)". (In
Emacs 22, before `boundaries', a different treatment was used here, which also
invalidated the invariants.) Is this description of the situation correct?

Please think of what I'm writing not as disputing but as trying to understand. I
believe you that you know what you're talking about here. ;-) I just want to
understand it better.