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: Stefan Monnier
Subject: bug#1085: 23.0.60; all-completions, try-completion inconsistent: Info-read-node-name-1
Date: Mon, 06 Oct 2008 10:37:28 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

> It has been true in general. It has just been false for a few exceptions.

Different uses of "in general".

> I think it should be true always.

There are 2 different needs.  For the user's convenience, the
*Completions* buffer should only list "foo for fot" rather than
"/toto/foo /toto/for /toto/fot" and similarly for various other
completion cases.  Currently all-completions returns the first list and
the `boundary' thingy can indicate that the missing prefix is "/toto/".
You want to change that so that all-completions returns the second list,
which still requires some way to figure out that the part that should be
stripped from display is "/toto/".
Efficiency and history are on the side of the current behavior.

> It should be possible to bring those exceptions into the fold.

For what benefit?

>  One should be able to use `all-completions' to construct a cons
>  completion table that is equivalent to the original TABLE argument,
>  regardless of how TABLE is defined (e.g. function, obarray).

Use the `boundary' thingy.  And note that this is new in Emacs-23.
In previous versions of Emacs there simply was no standardized way to do
that reliably.

>> In practice the main case where this "invariant" does not hold is when
>> the completion table is the one for file names, where all-completions
>> returns names that do not "full" (i.e. do not include the directory
>> name).

> Why shouldn't it be true in that case also? It isn't now, but it could
> be, could it not? File name completion could be made to keep the same
> user behavior it has now and still respect the invariants I mentioned.

Because the output of all-completions has historically been used for the
*Completions* output, so aesthetic and convenience may impose
other constraints.

>> For code that needs to live with this problem (e.g. minibuffer.el),
>> Emacs-23 introduces a new way to call the completion table 
>> function with a `boundary' argument.

> Why should `Info-read-node-name-1' in particular "need to live with
> this problem"?

Info-read-node-name-1 does not "live with this problem".  On the
contrary it makes good use of this freedom.

> Why shouldn't it return, for a CODE of t, a valid list
> of completions satisfying the invariants I mentioned? Why not do
> it right?

I don't know what you mean by "a CODE of t".

> Ideally (this part is for the wish list), we would provide completion
> not only for input such as `(ema', giving all-completions `("(emacs)"
> "(emacs-mime)")', but also for input such as `(emacs)Mac', giving
> all-completions `("(emacs)Mac Directories" "(emacs)Mac
> Environment"...)'.

It's indeed on the wishlist.  I'm pretty sure there's a TODO about it in
the code.  But it has noting to do with the dicsussion at hand.

>                   (mapcar (lambda (file) (concat "(" file ")")) ctwc))

That's not correct when completing "(/usr/shar".

> I hope you'll reconsider the policy wrt support for the invariants
> I suggested, instead of encouraging (yes) n'importe quoi.

I have banged my head against this problem for a long time, while
working on the minibuffer.el code (and its predecessors), so I don't
expect to change my mind any time soon.  The only thing you'd accomplish
with your proposal is "change", but it would just shift the problems
from one place to another without any actual benefit.


        Stefan






reply via email to

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