emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: how to control isearch for invisible text


From: Drew Adams
Subject: RE: how to control isearch for invisible text
Date: Sat, 12 Aug 2006 10:56:55 -0700

    > So, now, how about:
    >
    > - documenting `isearch-invisible' in the Emacs manual?

    It is `search-invisible'.

Oops; sorry.

    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?

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.

    > - 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(!).

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

    > - 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, for various reasons. Query-replace is
general, just like isearch.

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.

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

    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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]