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: Stefan Monnier
Subject: Re: Emacs completion matches selection UI
Date: Tue, 17 Dec 2013 13:29:30 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

> Yes, I understand.  But this is at odds with the way that
> `completing-read' and `widget-choose' and most modern UIs work.

You mean it's feature that the other systems lack.  Yes, agreed ;-)

> The user has explicitly invoked a completion command, right?

There's no doubt that it can be made more modal, but it's more
convenient if the mode is exited seamlessly.  Historically, TAB
completion is non-mini buffers did not affect the subsequent behavior.
This was a convenient feature with the downside that the *Completions*
buffer was left around.  So I wanted to fix this problem while
preserving the property that the mode stays out of the way.

> Right, it wouldn't care about the invocation context, the "dismiss on
> input when called in a buffer context" behavior would be an option.  For
> those who like it, it can stay.  I don't think it should be the default.

I'm not sure why you see it as something the user wouldn't like.
More specifically, why would you want to force the user to use special
commands to leave the "completion choice mode"?
I must be missing something.

> `completing-read' moves the focus of the user from point to the
> minibuffer IIUC, and then makes the entire interaction
> minibuffer-centric.  That seems to be the fundamental reason why we
> invented `completion-in-region-mode', to avoid that context switch.

Indeed, using completing-read to complete text from a normal buffer
would be inconvenient (tho it's done occasionally).
`completion-in-region' is a lot more lightweight for the user, staying
out of the way as much as possible.

> Otherwise yes, `completing-read' could be the list-selection API.

I think "list-selection" is a restrictive way to think about it: hitting
TAB to complete doesn't necessarily mean "the user wants to select
a completion candidate".  It can also mean "the user wants to complete
"fo" to "fooba" and then complete this identifier by adding something
else that's not in any of the completion candidates.

> Could `completing-read' call `widget-choose' regardless of the
> invocation point and show a graphical popup or a simple text buffer?
> Even in the minibuffer I think that would look OK.

We wouldn't use completing-read, for API reasons.  But indeed, the
minibuffer.el code is slowly moving towards using the same completion
mechanism as in other buffers (completion-at-point).

> Or maybe `completing-read' could be called for in-buffer completion if
> the minibuffer could somehow be moved closer to point?  Imagine if the
> minibuffer could slide up to point during the completion (perhaps by
> simply growing it upwards until it reaches point), then there wouldn't
> be a disorienting focus switch.  Ideally the entire minibuffer would
> slide up and look the same otherwise, but that's probably going to be
> hard to implement.

Still very disruptive.


        Stefan



reply via email to

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