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

[Juri Linkov]

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