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 15:07:18 -0700	[thread overview]
Message-ID: <EIENLHALHGIMHGDOLMIMIEHJCKAA.drew.adams@oracle.com> (raw)
In-Reply-To: <85ejvl4ozu.fsf@lola.goethe.zz>

    > I have no "actual situation". I was searching through a buffer that
    > had some invisible text (as an overlay), and I wanted to know if
    > there was an isearch option for finding it - that's all. You
    > answered "yes" - thank you.
    >
    > I suggested documenting that option better and making it a toggle in
    > `isearch'. You said it shouldn't be documented better, it shouldn't
    > be a user option after all, and, a fortiori, it shouldn't be toggled
    > in `isearch'.

    What was it that rendered the text invisible in the first place?

I used `dired-details-toggle' (a command in library dired-details.el) to
hide details in Dired (and, as I said, it uses an overlay). It happened that
I wanted to search for something invisible in that context, and I wondered
if there was a search option. That's all - there is nothing special about
that context. A single keystroke can make everything visible anyway, so
there is no special advantage in that context to searching for invisible
text.

    I know search-invisible since preview-latex has to deal with it
    (actually, it is just the XEmacs port, since the Emacs port works with
    display properties instead).  The mode was responsible for hiding
    stuff away, and consequently it was also responsible for letting them
    show up.  Since the behavior of isearch needed fixing, I had to check
    in the source file, anyway.  The details were complicated enough that
    it would have needed quite long and complicated explanations in the
    Elisp manual, for material that would get checked in the code, anyway.

    This is my contact with search-invisible.  Now could you please
    explain what mode rendered parts of your text invisible so that one
    can get an idea whether a global user option makes sense in connection
    with that?

As I said, the context that made me wonder about a possible search option is
irrelevant; there is no special need for searching invisible text in that
context. It occurred to me that it might be useful, generally, to be able to
search invisible text; that's all.

    > I do hope the user option `search-invisible' 1) remains a user
    > option, 2) gets better documented, as it seems useful, and 3) gets
    > an associated toggle in `isearch'.

    Would you please present an actual example where this would be useful?

Sorry, I don't have one, as I already stated in my last message. My crystal
ball tells me it will be useful, but my crystal ball has been wrong before
too. I like being able to toggle isearch options on the fly, and this is
apparently an isearch option (until/unless you kill it).

More importantly, I think the option should be documented - perhaps in the
section on invisible text, if there is to be no isearch toggle for it. If
you want to remove the user option and make it a plain `defvar', that's your
choice; I have no actual example that will dissuade you. End of story.

  reply	other threads:[~2006-08-12 22:07 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
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 [this message]
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=EIENLHALHGIMHGDOLMIMIEHJCKAA.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).