[Top][All Lists]

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

Re: Isearch interaction model

From: Daniel Colascione
Subject: Re: Isearch interaction model
Date: Sun, 4 Mar 2018 09:13:44 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 03/04/2018 07:39 AM, Eli Zaretskii wrote:
From: Juri Linkov <address@hidden>
Date: Sun, 04 Mar 2018 00:50:27 +0200
Cc: Emacs developers <address@hidden>

I think the answer is to have one history which records the mode used
for each search, so that it is reused correctly.  (When it makes sense,
the user can change the search mode after selecting the history element.)


One of the main questions to decide is how to attach search parameters
to the search string in the search history in a backward-compatible way.
We can't do this by adding text properties with search parameters
to the search string because text properties on strings can't be saved
in the desktop file or by other history saving libraries.

I see no way other than introducing a new incompatible history variable
that will keep previous searches with parameters in the same format
as is used currently by the search stack in isearch-cmds.

So what? That's fine.

Aren't we over-engineering this stuff?

No. Exposing search-type-specific histories is what's gross, especially as you increase the number of search types beyond the traditional two.

Why does it *matter* whether you search for something as a regular expression or a symbol or a word? What matters is what you were trying to find, and LRU ordering is a good way to make it easy to find what you meant.

IMNSHO, separate histories
could be just fine, since it's easy enough to change the Isearch mode
after you have the previous search string in the minibuffer.

Sure, and you can find ways to accept and work around spacebar heating too. The existence of workarounds is not excuse for poor UI.

And if
you remember your previous searches, you most probably also remember
whether you searched for a string as a symbol or a word or whatever.

That's imposing an additional cognitive burden on humans for the sake of an isearch implementation detail.

By contrast, breaking back-compatibility for this reason sounds gross
to me.

What backwards compatibility? The presence of individual history variables across major versions is not guaranteed.

reply via email to

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