[Top][All Lists]

[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: Fri, 20 Dec 2013 10:54:57 -0500
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)

On Fri, 20 Dec 2013 09:32:11 -0500 Stefan Monnier <address@hidden> wrote: 

>>>> If theres another point to this debate, please forgive me, because
>>>> I have missed it.
>>> Personally, I'm trying to understand what it is that Ted is suggesting.
>> I've explained it so many times I'm starting to wonder if my English is
>> the problem.

SM> It's never really control of language, but each word can mean many
SM> different things, and we seem to have very different assumptions and
SM> contexts, hence the difficulty.

Yes, I see that.  Sorry for any confusion I've brought to the
discussion, and thanks for separating the various areas.

SM> The way I see it, the subject under discussion can be divided into various
SM> mostly orthogonal elements:
SM> - when does the completion code get invoked:
SM>   - upon hitting TAB
SM>   - after typing the first N chars of a completable element
SM>   - when entering minibuffer
SM>   - ...

I am not looking to improve this, it's quite good already.

SM> - what completion operations take place:
SM>   - insert a few chars at point
SM>   - bring up a list of candidates
SM>   - ...

I think this should be unified as much as possible into a single
operation that takes place in any context, outside of the user's
control.  IOW this should be the place where Emacs standardizes to only
one completion/selection API, possibly through the `completion-*'

SM> - how to display the list of candidates:
SM>   - in a separate buffer
SM>   - at point, via clever overlay tricks
SM>   - at point, via a special frame
SM>   - at point, via a x-popup-menu
SM>   - ...

This should probably be customizable, but the default IMO should be
different between graphical and text mode, the way that `widget-choose'
does it.  See the parallel discussion with Dmitry about the possible
approaches here, including icons and tables with annotations and so on.

SM> - what operations can be performed while the list of candidates is 
SM>   - keep on editing as if the list was not displayed
SM>   - select among candidates with the mouse
SM>   - select with up/down
SM>   - ...

The current defaults for this are not consistent and were the original
reason for starting the thread.

The default here is tricky, since we have the in-buffer
vs. in-minibuffer split to consider.  I agree with Dmitry that
auto-narrowing the candidates is important by default; the up/down
selection is important too but must not interfere with buffer motion
when completing in a buffer of course.  If we can find something
consistent that works as a default in all the invocation contexts, I
think that would offer the biggest benefit to Emacs usability.

SM> - how/when to update the list of completions and to pop it down.

That should be entirely internal to the API and not exposed, I think.

SM> - what Lisp function to call to display the list of elements.
SM>   We currently don't really have something clear here.  IIUC this is the
SM>   API part you care about (the rest is mostly behavior rather than API).

Yes, this is the API that should get called by any package (internal or
external) that wants to ask the user to interactively select completion
candidates or just one item from a list.

>> Yup, absolutely.  The autocomplete web browser widgets (e.g. the jQuery
>> UI one) have that on-the-fly narrowing.  This specifically conflicts
>> with the way in-buffer completion works right now,

SM> It doesn't conflict at all.  The current UI doesn't update *Completions*
SM> on-the-fly, but it very much could (and pretty easily too).

OK, that's great.

>> and the in-minibuffer completion kind of works like this if you turn
>> `icomplete-mode' on and hit TAB to see the candidates every time you
>> type a character.  IMO this should be an API option.

SM> I don't see why it should appear in the API.  It looks like a user
SM> preference instead.  See below for a very crude approximation.

Yes, I think you're right, but I can't think of a case where I don't
want auto-narrowing, so I suggest always turning it on.


reply via email to

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