bug-gnu-emacs
[Top][All Lists]
Advanced

[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.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]