GNU bug report logs -
#1085
23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1
Previous Next
Full log
View this message in rfc822 format
> > 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.
Yes and no. If you use find-file, then yes, you're right, because it calls, in
effect, try-completion passing an absolute file name:
(try-completion "c:/mydir/icicles." 'read-file-name-internal nil) gives
"c:/mydir/icicles.el", whereas, as you say, all-completions uses relative file
names.
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.
(try-completion "icicles." 'read-file-name-internal nil) gives "icicles.el".
That was my point. If the directory information is passed separately, not
included in the file name, then try-completion and all-completions use the same
set of completions (relative file names). There is no invalidation of the
invariant - the two coexist harmoniously - the completions for try-completion
and for all-completions are the same.
> > 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.
I still have the same question - why?
> > 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? And doesn't the use of that feature invalidate the
invariant?
This bug report was last modified 15 years and 343 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.