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

From: "Drew Adams" <[email-masked]>
Date: Wed, 8 Oct 2008 09:24:31 -0700

> >> > 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.
> >> Your 3rd invariant is invalidated because all-completions does not
> >> return the directory part of a completion.
> 
> > But if you call try-completion directly using a relative file name,
> > then it, just like all-completions, returns the completed relative
> > file name - completed in the default directory.
> 
> Not if the relative file name includes a slash.
> 
> > (try-completion "icicles." 'read-file-name-internal nil) 
> > gives "icicles.el".
> 
> That's just a happy corner case.  We're discussing the general case.

Why couldn't that be the general case.

You seem to be reasoning based on the current implementation (e.g. that's not
the way it is), not based on the general discussion here.

> >> > Why couldn't we treat this completion the same way we treat 
> >> > file-name completion?
> >> We do treat it identically.
> > Not if I understand correctly. Isn't it true that we use the boundary
> > thing (with prefix "(") for the Info file/node completion, and we 
> > don't use it for file-name completion?
> 
> We use it for file-name completion just the same.

But do we need to? That's the question. Is it necessary to use boundaries in a
situation like this?

> If you're in the particular case where the file name has no directory
> component, then the prefix is the empty string so you may get fooled
> into thinking that it's not used, but it is.

You seem to be just repeating how it's done now, and not listening to my
argument. Is there any reason that `boundaries' needs to be used for file-name
completion? Couldn't `try-completion' always use relative file names?

That's the question - is there any reason why try-completion and all-completions
*must* be incompatible (in the sense of the invariant being invalidated) for
file-name completion. You seem to be ignoring that question and just responding
that in the current implementation they are incompatible.

You said earlier that the directory is passed separately, which it is. What
information is needed besides the relative file name and the directory in which
completion is to be done? If they are all that are needed for both
try-completion and all-completions, then why do they need to be incompatible?

I'm asking about *required* behavior/design - what is necessary and what
alternatives are possible, not just how it happens to be implemented now.

I'll give up after this. *Seems* like you're not really trying, but I'm not
jumping to that conclusion yet. If I'm misunderstanding something, I'd like to
learn it.