[Top][All Lists]

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

Re: RFC: [PATCH] isearch enhancements: symbol mode; syntactic filtering

From: Daniel Colascione
Subject: Re: RFC: [PATCH] isearch enhancements: symbol mode; syntactic filtering
Date: Thu, 07 Jul 2011 17:49:09 -0700
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0

On 7/7/2011 5:20 PM, Juri Linkov wrote:
- Syntactic filtering: control whether to match in comments, strings, and
normal text.

This is easier to implement using `isearch-filter-predicate' as shown in

It may be easier to implement that way, but the results aren't as good. Integrating the filtering mode into isearch allows it to be saved along with all other isearch state. Also, my approach doesn't conflict with other uses of isearch-filter-predicate.

I do like the idea of displaying isearch state information in the modeline instead of the minibuffer, however.

Unfortunately, I failed to find a good keybinding for this feature,
so it sunk into obscurity.

The ones I proposed should be reasonably accessible, and they don't conflict with anything useful directly from isearch.

- Symbol search: like word search, but looks only at symbol boundaries

This is much needed.  But I think it should have a keybinding separate
from word search.  Currently, `M-s w' toggles word search,
so a new keybinding `M-s _' could toggle symbol search.

Adding symbol search as a new kind of word search makes sense because the new search mode is conceptually similar to, and mutually exclusive with, classic word search; having accepted this idea, it naturally follows to allow users to cycle through normal, word, and symbol searches makes sense. I have no objection to providing a way to go directly to symbol search, however: being able to cycle backwards with a prefix argument to M-s w would be sufficient, I think.

I like the idea of using M-_ to refer to something having to do with symbols; in my patch, I bind this key to a function that both sets symbol-search mode _and_ filters out matches in comments and strings; I call it identifier-mode. I find myself wanting exactly this behavior fairly frequently. We can certainly bikeshed a bit about the actual keybindings.

- One ring: optionally share a search ring between normal and regular
expression searches. The additional history storage described below allows
this mode to work reliably.

Maybe sharing a search ring between normal and regexp searches
would be better to implement in the same way as sharing
`from' and `to' histories is implemented in `query-replace'?
Like two variables `query-replace-from-history-variable' and
`query-replace-to-history-variable', isearch could provide
two variables `isearch-ring-variable' and `isearch-regexp-ring-variable'.

We can do it that way too. I also considered using a variable alias, to point regexp-search-ring at search-ring, but your approach is cleaner.

Speaking of search rings: would anyone object (after feature freeze, of course) to allowing history functions to use something other than equal (e.g., equal-including-properties) as the comparison function for duplicate detection?

- Case sensitivity is now displayed alongside other isearch settings in the
isearch prompt.  Previously, the only indication we gave of case
sensitivity was a fleeing message displayed briefly each time the user
toggled the setting.

This is a good change as well, but one possible problem is that
its message string "case-insensitive " (17 characters) is too long
for the isearch prompt.

"(CI)"? "nocase"? "case"? My isearch strings tend not to be long enough to actually cause problems this way.

- isearch no longer prints "pending". I don't see why this message would
be useful.

"pending" reminds the user that the actual search position doesn't
correspond to the search parameters displayed in the search prompt.
This happens after e.g. changing the search type to regexp or word.
Updating the search position might be more surprising for users.

I don't feel that the user needs to be reminded of the situation; I think the user will intuitively understand what's happening when the point fails to move.

reply via email to

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