emacs-devel
[Top][All Lists]
Advanced

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

Re: [External] : Re: Simple isearch concerns


From: Augusto Stoffel
Subject: Re: [External] : Re: Simple isearch concerns
Date: Tue, 11 May 2021 11:01:47 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

On Tue, 11 May 2021 at 13:20, Yuri Khan <yuri.v.khan@gmail.com> wrote:

> On Tue, 11 May 2021 at 04:31, Juri Linkov <juri@linkov.net> wrote:
>
>> When you type 'C-f' in a web browser, it activates the "minibuffer".
>> Then you can type a search string.  As soon as you type a character
>> in the minibuffer, it immediately updates the search state
>> in the original window.  You can edit the search string
>> while the minibuffer is active, and the search results are
>> updated immediately.  Also each browser window has own search.
>
> That makes sense for a web browser, because a web browser is typically
> used only for viewing content and not editing. It typically also has
> no point (except in form fields and editable content). (There is also
> an optional accessibility feature that gives you a point which you can
> move around the page and select text with the keyboard.)
>
> The typical use case in a browser is to enter a search term and jump
> through its occurrences. As soon as you have found the one you want,
> you just keep reading from that point.
>
> Because browsing the Web is mostly a mouse-driven activity, and only a
> few keys are involved, a browser can afford giving all text editing
> keys to the search bar, including Home/←/→/End to move the insertion
> point within the search box and any text selection and cut/copy/paste
> keys.
>
> On the other hand, in a text editor such as Emacs, the use case is
> different. You want to find an occurrence and then work with buffer
> text in its neighborhood, and you want to switch from searching to
> editing with as little friction as possible — preferably none. Isearch
> supports exactly this use case, by making any unbound key terminate
> the search and then perform its usual action, and making an exception
> for Backspace so you can correct small typing mistakes. This comes at
> the price of making editing the search string itself a bit less
> convenient — one has to press M-e for that.

The approach Isearch uses to read the search string is fine, but, unlike
you seem to be claiming, it has no fundamental advantage over using the
minibuffer.

In the minibuffer-based Isearch, one could easily make every movement
command (or any random subset of them) quit the minibuffer first.  In
fact, the patch already adds this behavior for `isearch-query-replace'
and a few other commands.



reply via email to

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