[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-re
From: |
Drew Adams |
Subject: |
bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1 |
Date: |
Mon, 6 Oct 2008 21:42:21 -0700 |
> 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.
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Drew Adams, 2008/10/04
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Drew Adams, 2008/10/04
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Stefan Monnier, 2008/10/05
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Drew Adams, 2008/10/06
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Stefan Monnier, 2008/10/06
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Drew Adams, 2008/10/06
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Stefan Monnier, 2008/10/06
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1,
Drew Adams <=
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Stefan Monnier, 2008/10/07
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Drew Adams, 2008/10/07
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Stefan Monnier, 2008/10/07
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Drew Adams, 2008/10/07
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Stefan Monnier, 2008/10/07
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Drew Adams, 2008/10/08
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Stefan Monnier, 2008/10/08
- bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1, Drew Adams, 2008/10/08