GNU bug report logs - #11378
24.1.50; Suggestion: Let M-i in isearch cycle `search-invisible'

Previous Next

Full log

Message #38 received at 11378 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> jurta.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: michael_heerdegen <at> web.de, 11378 <at> debbugs.gnu.org
Subject: Re: bug#11378: 24.1.50;
	Suggestion: Let M-i in isearch cycle `search-invisible'
Date: Wed, 30 May 2012 03:40:05 +0300

> I suggest renaming it to isearch-filter-predicates or
> isearch-filter-functions.

isearch-filter-functions is more usual name for the hook-like
functionality than isearch-filter-predicates.

> Also the docstring should describe its
> `isearch-message-prefix' property (BTW, why "prefix"?).

The prefix is what's displayed before the search string in the message.
The suffix is after the search string in square brackets.

>> +Type \\[isearch-toggle-filter-strings] to toggle searching inside strings.
>> +Type \\[isearch-toggle-filter-comments] to toggle searching inside comments.
>
> To me, the most useful filter would be "search in comments and strings"
> or "search in code only (i.e. exclude comments and strings)", neither of
> which is covered by those two toggles.

Then the combination of comments and strings could be named "text" with
its filter bound to `M-s f t'.  And the inverse filter to exclude
comments and strings could be bound to `M-s f T'.  Also it could be
enabled only in prog-mode.

>> @@ -2489,13 +2560,11 @@ (defun isearch-search ()
>>        (setq isearch-case-fold-search
>>  	    (isearch-no-upper-case-p isearch-string isearch-regexp)))
>>    (condition-case lossage
>> -      (let ((inhibit-point-motion-hooks
>> -	     (and (eq isearch-filter-predicate 'isearch-filter-visible)
>> -		  search-invisible))
>> +      (let ((inhibit-point-motion-hooks search-invisible)
>>  	    (inhibit-quit nil)
>>  	    (case-fold-search isearch-case-fold-search)
>>  	    (search-spaces-regexp search-whitespace-regexp)
>
> Why is this correct?

I believe that binding `inhibit-point-motion-hooks' to t unconditionally
shouldn't cause an unwanted effect because `isearch-done' takes care
about moving point outside of intangible text at the end of the search
(the source lines that begin with the comment ";; If we ended in the middle
of some intangible text, move to the further end of that intangible text.")
But currently I know no test case to prove the effect of
`inhibit-point-motion-hooks'.

BTW, in etc/TODO I noticed this task:

*** Outlining
**** Support for incremental search automatically making hidden text visible.

It seems this is already implemented at least for outline
(but needs more testing in org-mode).

Anyway I intend to rewrite the filter `isearch-filter-visible' to just
check if the text is visible.  The code that opens overlays should be
moved to the main search loop to work independently from the filter.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.