[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
bug#22479: 25.0.50; isearch and query-replace histories do not remember if we were looking for symbols
Wed, 03 Feb 2016 02:39:19 +0200
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
>>> - 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 _
>>> 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
> 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.