Re: Isearch interaction model

[Daniel Colascione <dancol@dancol.org>]

On 03/04/2018 07:39 AM, Eli Zaretskii wrote:
>> From: Juri Linkov <juri@linkov.net>
>> Date: Sun, 04 Mar 2018 00:50:27 +0200
>> Cc: Emacs developers <emacs-devel@gnu.org>
>>
>>>> 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.)
>>>>
>>>
>>> Yep.
>>
>> 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.