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

[Daniel Colascione]

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
> http://thread.gmane.org/gmane.emacs.devel/34742

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.