[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22479: 25.0.50; isearch and query-replace histories do not remember
From: |
Juri Linkov |
Subject: |
bug#22479: 25.0.50; isearch and query-replace histories do not remember if we were looking for symbols |
Date: |
Wed, 03 Feb 2016 02:39:19 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) |
>>>> 5. More ideas? ;)
>>>
>>> - We can retain the two histories: regex, non-regex
>>>
>>> - Any fancy (word, symbol, etc) searches can be stored into the regex
>>> history, bookmarked with the appropriate regexen ("\_<", "\_>" for
>>> instance)
>>>
>>> - When reading the history to present to the user, these can be parsed
>>> out. So for instance when the user looks through the symbol-search
>>> history by hitting
>>>
>>> M-s _
>>> C-s
>>>
>>> emacs can look through the regex history, only selecting entries in
>>> \_<...\_>. The C-M-s history can either include all of these, or show
>>> only unbookmarked entries; both would be ok, I think.
>>
>> This approach is compromising but unreliable
>
> Indeed it is a compromise. It feels to me to be much better than what we
> have now, and the issues aren't too significant... I think...
>
>> (doesn't distinguish between the case when the user uses the symbol
>> search M-s _ or types \_<...\_> directly in the regexp search)
>
> True, but I think this is OK. The symbol-search history would include
> M-s _ searches AND those C-M-s searches where the intent was to look for
> symbols; I think this is fine. The regex-search history would include
> all symbol searches also; maybe that is less fine, but it isn't crazy.
> The text search history would include none of these; this is GOOD, and
> is not what we do now.
How then you would deconstruct an original search string from a
char-fold regexp? Almost impossible with such garbage-looking
regexp like you demonstrated in bug#22520.
>> (need to remember other search parameters like case-fold and
>> lax-whitespace).
>
> Hmmm. This clearly requires metadata so some of your other, more
> intrusive proposals would be required to handle this.
Might be not too intrusive given that we already have such metadata
in isearch-cmds. This means extending the isearch-cmds structure
to search-ring, and maybe renaming it to isearch-ring.