emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs completion matches selection UI


From: Ted Zlatanov
Subject: Re: Emacs completion matches selection UI
Date: Mon, 16 Dec 2013 17:15:49 -0500
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)

On Mon, 16 Dec 2013 13:35:47 -0500 Stefan Monnier <address@hidden> wrote: 

>> ;; It is difficult to know when to exit completion-in-region-mode (i.e. hide
>> ;; the *Completions*).
SM> [...]
>> If there was a special popup to show a list of items, [...], it would
>> abstract these difficulties and cut some nasty code out of
>> minibuffer.el.

SM> No, it wouldn't.  The problem needs to be solved either way.

SM> `company-mode' solves this problem not by popping up a special GUI
SM> element, but by defining which operations can be performed while this
SM> element is displayed, and which operations cause the element
SM> to disappear.  And completion-in-region-mode does the same, tho using
SM> the *Completions* buffer rather than a special GUI element, and making
SM> different choices about which operations can be performed while the
SM> completions are displayed and which operations make the
SM> completions disappear.

I am trying to say that Emacs itself, outside of the
window/frame/etc. logic, should have code to "show a list of choices and
pick one."  An API to list selection, from the minibuffer or from a
buffer, with consistent key bindings and no dependence on the context in
which it was invoked.  This seems to be what `widget-choose' could do
with some polish, and that's where I'd put effort.  Do you agree?  To
me, It seems crazy that there is no standard way to do this and that so
many packages, internal and external, have invented their own UI to do it.

The choices about available operations during selections and which
operations should cancel or complete the selection should be entirely
inside an API like `widget-choose' and *standard*.  I think the trigger
to bring the selection UI up is the only thing that should be up to the
client.  In the case of `completion-in-region-mode', do you see how it
would remove a large chunk of code that deals with post-change and key
customizations?  Or am I just not getting it?

>> For the UI case of "I'm in the minibuffer and want to complete
>> something" I would rather wait for the general list popup to be
>> available with `widget-choose' than add the special down/up keybindings
>> that we discussed.

SM> Again, this has nothing to do with whether the list is displayed in
SM> a *Completions* buffer or on a shoestring.  The questions are "when
SM> should the list be displayed", and after that, "when should we enter the
SM> special mode where the user can navigate in this list".

This was a separate UI case and I think we agreed (broadly) earlier on
these questions.  I am saying I'd rather wait to implement this until I
have a standard Emacs-wide API to display a list of candidates, so I am
not writing blocks of code to work around the currently implemented
*Completions* UI.  From `completion-in-region-mode' and reading the
other code around minibuffer.el I believe it will be hard to write
maintainable code to do this otherwise.

>> I think the change is too risky for the short time we have this week.

SM> I'm not sure which change you're thinking of, but I probably agree.

I meant the change to implement the second UI case, the one to make
up/down bring up the candidate selection UI as we discussed.

Ted




reply via email to

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