unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: how to control isearch for invisible text
Date: Sat, 12 Aug 2006 10:56:55 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMIEHGCKAA.drew.adams@oracle.com> (raw)
In-Reply-To: <85slk16fib.fsf@lola.goethe.zz>

    > 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	other threads:[~2006-08-12 17:56 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-12  8:30 how to control isearch for invisible text Drew Adams
2006-08-12  8:49 ` David Kastrup
2006-08-12 17:09   ` Drew Adams
2006-08-12 17:16     ` David Kastrup
2006-08-12 17:56       ` Drew Adams [this message]
2006-08-12 19:21         ` David Kastrup
2006-08-12 20:54           ` Drew Adams
2006-08-12 21:02             ` David Kastrup
2006-08-12 21:17               ` Drew Adams
2006-08-12 21:34                 ` David Kastrup
2006-08-12 22:07                   ` Drew Adams
2006-08-12 22:27                     ` David Kastrup
2006-08-12 23:02                       ` Drew Adams
2006-08-13  0:28     ` Stefan Monnier
2006-08-13  7:14       ` David Kastrup
2006-08-13 17:52         ` Richard Stallman
2006-08-13 18:00           ` David Kastrup
2006-08-14  0:36           ` Stefan Monnier
2006-08-14  7:12             ` David Kastrup
2006-08-14 12:14               ` Stefan Monnier
2006-08-14 12:24                 ` David Kastrup
2006-08-14 12:59                   ` Stefan Monnier
2006-08-14 13:48                     ` David Kastrup
2006-08-14 14:43                       ` Stefan Monnier
2006-08-14 15:05                         ` David Kastrup
2006-08-14 15:23                           ` Drew Adams
2006-08-14 15:32                             ` David Kastrup
2006-08-15 12:41                             ` Richard Stallman
2006-08-15 12:40             ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=EIENLHALHGIMHGDOLMIMIEHGCKAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).