[Top][All Lists]

[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.

reply via email to

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