Re: how to control isearch for invisible text

[David Kastrup <dak@gnu.org>]

"Drew Adams" <drew.adams@oracle.com> writes:

>     I consider it far too special to be
>     documented in the Emacs manual: this is a variable that should, if at
>     all, be used by the modes or packages making stuff invisible.
>
> Then why is it a defcustom? Why can you customize it?

Not much of a reason I see there.

> I don't think it's special, or I wouldn't, as a user, have asked for
> such a feature. I don't see why this shouldn't be useful for
> users. When I'm searching, and there is some invisible text (which I
> may or may not know), I'd like to be able to toggle isearch, to make
> it (in)sensitive to that text.
>
>     > - and the Elisp manual?
>
>     Not sure whether it is important enough for that.
>
> I think it's especially important for the Emacs manual.

I don't, and I explained why.

>     > - creating a toggle for it?
>
>     Why?  It is not a user-level feature.
>
> It's a user option - customizable. And so it should be, IMO. That's
> why I was asking for such an option - as a user. I want to
> interactively control whether isearch hits hidden text. One use is
> to find whether something particular is perhaps present but
> hidden(!).

But that depends on the mode in question.

>     Providing a toggle would be the task of any mode that makes
>     stuff invisible and that would require to have it accessible.
>
> Why would each mode do that?

Because invisibility does not serve a unique purpose.

> Why not have a general toggle for isearch - the same binding for all
> modes? If I have a mode that hides dired details, that mode will
> provide a toggle to show/hide the details, but it shouldn't have to
> also provide a toggle for isearch sensitivity to hidden text. If
> each mode does that, then users will not have a single, consistent
> binding to rely on - and the toggle should be available while
> isearching. To me, this is no different from toggling
> case-sensitivity or regexp sensitivity.

To me it is.  Case is not something a mode applies to a buffer, nor
are regexps.

>     > - having `occur' and `query-replace' respect the option?
>
>     Sounds sort of reasonable, at least with query-replace.  With
>     occur, I am less sure, since it is sort of an internal grep.
>     But since occur could not reasonably display something useful
>     without making it visible, it might be an idea.
>
> I think the use case is basically the same, for isearch, occur, and
> query-replace. I can imagine a mode that might temporarily or
> selectively hide things in an *Occur* buffer,

Who is talking about the occur buffer?  We are talking about the
source buffer.  The occur buffer would not copy overlays, anyway.

> for various reasons. Query-replace is general, just like isearch.

I said it sounded reasonable for query-replace.

> I can imagine that one might be able to get into trouble using
> query-replace with invisible hits, but I also think it could be
> useful.

Invisible hits are made visible when searching: no trouble here.

>     > Also, I'm curious why the treatment of an `invisible'
>     > text-property value of `isearch-open-invisible' is limited to
>     > overlays. Why shouldn't the same behavior hold for the
>     > property if applied directly to text (that is, without an
>     > overlay)?
>
>     Because you can make some text visible without modification when
>     there is an invisible overlay over it.  If there are invisible
>     text properties, you can't remove them without changing the
>     buffer, and searching should not change the buffer.
>
> Ah, I guess you mean that the parallel use case would exist for text
> without overlays, but it would be difficult or impossible to
> implement.

No, the parallel use case does not exist.  Text with invisible
property is intended to never be a visible part of the buffer.
Overlays, in contrast, can be removed and put back without a buffer
change.

>     Fiddling with invisibility-spec would affect all invisible regions,
>     not just the one at point.
>
> Not sure I understand what you mean, there. Is that part of the
> explanation of the implementation difficulty?

There is no implementation difficulty.  It is not useful to search for
text that is not part of the visible buffer and can't become so
without changing its properties.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum