RE: how to control isearch for invisible text

["Drew Adams" <drew.adams@oracle.com>]

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

So do you consider the defcustom a bug, rather than a feature? You say this
is "not a user-level feature", but, in fact, it is.

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

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

My wish to search for invisible text or not does not necessarily depend on
the mode. What depends on the mode? Just which text is hidden. This is about
being able to turn on/off search of invisible text, not about the choice of
which text is to be invisible.

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

So what? Different modes can decide to capitalize words differently too, and
some modes (e.g. SQL) are generally case-insensitive while others (e.g.
Emacs Lisp) are case-sensitive, but isearch case sensitivity can still be
toggled. By your argument, people should not be able to toggle
case-sensitivity: if the mode is case-sensitive, then you should search only
that way; if the mode is case-insensitive, then you should search only that
way.

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

Invisible text doesn't necessarily "apply to a buffer". Text can be
invisible for different reasons.

And case can very well be something that "applies to a buffer" - play with
SQL mode and see if its buffers are generally sensitive to case.

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

Sorry, I meant the source buffer that is searched to create the *Occur*
buffer.

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

How can you make such a blanket statement? Someone or some application could
easily make some text in a buffer invisible for a particular use, without
using an overlay. And someone might well want to be able to search that text
in either mode: show/ignore invisible text. Nothing is verboten or
predetermined about how someone or some application might use invisible
text.

You say that "searching should not change the buffer". But the change can be
temporary. (Plus, query-replace is likely to change the buffer anyway.)

    Overlays, in contrast, can be removed and put back without a buffer
    change.

There are lots of temporary "buffer changes" in Emacs. Adding and removing
an overlay is also a kind of "buffer change", even if it doesn't change the
text.

I'm not saying people shouldn't use overlays in the way you describe - far
from it. I'm only asking why isearch shouldn't behave the same for invisible
text, with or without an overlay.

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

You're just repeating here that you don't see the usefulness. I ask why it
wouldn't be useful, and you answer only "It is not useful."

Can you explain what you meant about "fiddling...not just the one at point"?

I'm guessing perhaps you meant something like this: Toggling isearch's
showing of invisible hits would, in the case of invisible text (no
overlays), require toggling the behavior for the whole buffer. If that's
your point, so what? What's wrong with toggling the behavior for the whole
buffer?

And why would that be the case necessarily? Why could't isearch temporarily
show only the current hit, and then make it invisible again when you move on
to another hit?