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
> From: Stefan Monnier Sent: Monday, October 06, 2008 7:06 PM
>
> > > You want to change that so that all-completions returns
> > > the second list [i.e. list of absolute, not relative
> > > file names]
>
> > No, not necessarily. I only want `try-completion',
> > `all-completions' and `test-completion' to be on the same
> > page, in the sense of the invariants I mentioned.
>
> Then I missed those invariants.
> Could you spell them out again one by one?
Actually, it was you who first used the term "invariants", referring presumably
to the behavior I had described/requested. ;-)
But without at first using that term, I did speak of invariants:
1. User's input should be a prefix of what it is completed to in the minibuffer,
which should be the same as the common prefix of all its completions, the result
of `try-completion':
> M-: (try-completion "(el" 'Info-read-node-name-1)
>
> It returns "(elisp)", meaning that this is the common prefix of all
> completions of "(el". [This is reasonable, and it satisfies the
> requirement that "(el" is a prefix of "(elisp)".]
2. `all-completions' elements correspond to `test-completion':
> And each of the completions returned by `all-completions' must
> also satisfy `test-completion'. In particular,
> (test-completion STRG (all-completions strg TABLE)) must always
> return t, for all STRG and TABLE. In this case, for STRG = "(el" and
> TABLE = `Info-read-node-name-1', it returns nil.
3. `all-completions' elements correspond to `try-completion':
> the valid completions returned by `all-completions' have the
> common prefix that is returned by `try-completion' (which
> must in turn have the input as its prefix [see #1]).
I don't know how independent these are; there is probably some overlap. But they
seem like good rules to shoot for.
> PS: Regarding the behavior of info completion for "(emacs)",
I assume by that you mean completion of things like "(emacs)Mac O" to
"(emacs)Mac OS" and even completion of "(emacs)" to all of the Emacs manual
nodes (a la completion of a directory /some/dir/ for files).
> it can't be done right until someone writes the relevant code.
> Basically the current code doesn't know how to do completion
> in this case, so try-completion can't return anything use[ful?],
> and neither can all-completions, or test-completion.
Yes, I realize that.
The code I sent lets you complete just the file-name part - "(ema" to "(emacs"
and "(emacs-" to "(emacs-mime"). That's as far as it goes.
I even thought about temporarily moving to the manual and doing a node
completion there, then prefixing each node by "(emacs)" etc. But aside from the
ugliness of that approach and my laziness, I wasn't sure of the behavior I
wanted.
I think now that a straight analogy to file-name completion wouldn't be bad:
"(emacs)Fo" in the minibuffer and all of the Emacs manual node names in
*Completions* - without "(emacs)" prefix - just like for file names. Just as
with file names, you could delete the default directory (manual's file name -
"(emacs)" from the minibuffer if you wanted. Just as with file names, you could
change the directory (manual's file) explicitly in the minibuffer.
Yes, I know that these musings might seem to contradict some of the invariants
mentioned above. I think that if Info node completion behaved just like
file-name completion I'd be happy. Dunno.
> The current code instead just tries to return something
> that's safe:
Safe = ? I don't follow.
> try-completion returns the string unchanged, which indicates
> that it's a valid completion and that there's
> more completions out there; test-completion returns t to basically say
> the same;
I think they are OK.
> and all-completions returns nil so that
> minibuffer-completing-help doesn't give some bogus list
> of completions.
That's not good, I think. nil means there are no completions.
> The try-completion and test-completion outputs are fairly reasonable.
Yes.
> The all-completions one is less satisfactory since returning nil seems
> to imply that the input is not a valid completion, whereas
> try-completion and test-completion say that it is.
We agree.
> Returning a list containing a copy of the input wouldn't
> be right either since it would imply that the current
> input is the sole completion.
Agreed.
That's why I fixed it to return the complete set of manuals (files): ("(emacs)"
"(emacs-mime").
But it would be good to be able to complete beyond "(emacs)" to all of the Emacs
manual nodes - like completing "/some/d" to "/some/dir/" and then completing
that to all of the directory's files.
> Basically, we'd need a special `dont-know' return value,
> but it doesn't seem worth the trouble.
I don't follow you there. What do you mean?
All of the manuals (files) are known, and all of the nodes in each manual are
known. So such completion should be possible.
- Drew
P.S. Could you explain a little about boundaries and what you meant about using
that feature. This is not clear to me.
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.