emacs-devel
[Top][All Lists]
Advanced

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

Re: [External] : Re: Indicate better the current use of the echo area /


From: Daniel Mendler
Subject: Re: [External] : Re: Indicate better the current use of the echo area / minibuffer [was: Controlling Isearch from minibuffer]
Date: Thu, 13 May 2021 18:33:03 +0200

On 5/13/21 6:16 PM, Daniel Martín wrote:
> It's unexpected if you come from other applications, but I don't think
> it's a bad UX.  Once you get used to how Isearch works, in my opinion
> it's much more efficient than using the minibuffer.  For example, it's
> very common to use incremental search to navigate to a particular place
> in a buffer, and, once you are in the desired position, do something
> like C-n, C-v, or C-p to move the point further and end the search at
> the same time.  This use case wouldn't be as convenient if incremental
> search used the minibuffer.  Try it in the CtrlF package, for example.

Yes, of course. But this is where the preferences may differ. Some
people prefer to navigate the search string, others may prefer to
navigate the buffer and quit the transient Isearch keymap in that case.
The patch by Augusto does not remove the current Isearch mode. The
default would stay as is.

>> There exists the ctrlf package on MELPA which also uses the minibuffer,
>> but it feels hardly justified to install an extra package only to get a
>> minibuffer-controlled search mode. I also don't want to replace such a
>> tightly integrated component like Isearch with an external package. If a
>> minibuffer mode can be added to Isearch with small effort and in a
>> reasonably clean way, why not do that?
>
> That's the problem.  Given the amount of subtle use cases currently
> supported by Isearch, I think that even adding a separate option to use
> the minibuffer would not be a simple implementation (for example, you
> can perform an incremental search in the minibuffer itself, etc.).

The incremental search in the minibuffer is a feature I use rarely. It
is okay if this feature is not available if the minibuffer is used
itself to control the search.

This is not up to me to tell, it seemed the patch by Augusto providing
the minibuffer-controlled search is "full featured", such that it works
as one would except from Isearch, as long as one accepts that the
minibuffer is used for controlling the search.

What other subtle edge cases do you have in mind?

> To be fair, I see some good things about using the minibuffer (for
> example, it'd be simpler to perform certain actions, like scrolling the
> window, without exiting the search), but all the things that we'll lose
> or will change don't quite justify the new feature, IMHO.

Nothing will be lost, except some simplicity. The current Isearch will
stay as is. Only the command `isearch-edit-string` will be made more
incremental with live updating results. From what I've seen the question
is if the "loss in simplicity/purity" is justified since Isearch will
get an additional interaction mode, which deviates from the currently
existing interaction mode.

Daniel Mendler



reply via email to

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