unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: nljlistbox2@gmail.com (N. Jackson)
To: 20092@debbugs.gnu.org
Subject: bug#20092: 24.4.91; False matches with incremental search in Info
Date: Thu, 12 Mar 2015 11:29:05 -0300	[thread overview]
Message-ID: <87bnjy9tn2.fsf@moondust.localdomain> (raw)
In-Reply-To: <87zj7ix55f.fsf@moondust.localdomain> (N. Jackson's message of "Thu, 12 Mar 2015 00:31:56 -0300")

I'm having a hard time figuring out the intended behaviour of I-search
when search-invisible has the value `open'. I think the documentation
here could be improved somewhat, especially since this is the default
value. The way the documentation reads now the feature seems less than
completely baked.

I'm guessing that the intended behaviour is roughly that when a search
finds a match in text that is invisible to the user, then, 1) if the
value of search-invisible is nil then the match is ignored; 2) if the
value of search-invisible is t then the match is deemed to be
immediately before the start of the invisible text (This is the rather
confusing behaviour that prompted me to report this bug.); and 3) if the
value of search-invisible is `open' then the chunk of invisible text is
made visible ("opened") temporarilly, and the match shown within it.

The Emacs manual doesn't have "search-invisible" in the index but it is
in the variables index. However the variables index entry doesn't link
to the definition of the variable but rather to the node "Outline
Visibility" where it is only mentioned in passing and the meaning of
`open' is not mentioned at all.

A search of the manual turns up "search-invisible" in two places. The
first is in the node "Query Replace" and reads:

    "The option ‘search-invisible’ determines how ‘query-replace’ treats
    invisible text.  *Note Outline Search."

The link to "Outline Search" here seems to be broken; it goes to
"25.10.3 TeX Printing Commands".

The second place it is found is in "Outline Visibility". This is the
most helpful (perhaps that's whey the Variable Index points here) but,
as I mentioned above, it doesn't discuss `open':

    "When incremental search finds text that is hidden by Outline mode, it
    makes that part of the buffer visible. If you exit the search at that
    position, the text remains visible. To toggle whether or not an active
    incremental search can match hidden text, type ‘M-s i’. To change the
    default for future searches, customize the option ‘search-invisible’.
    (This option also affects how ‘query-replace’ and related functions
    treat hidden text, *note Query Replace.) You can also automatically make
    text visible as you navigate in it by using Reveal mode (‘M-x
    reveal-mode’), a buffer-local minor mode."

The docstring for search-invisible says:

#+BEGIN_SRC emacs-lisp
      "If t incremental search/query-replace can match hidden text.
    A nil value means don't match invisible text.
    When the value is `open', if the text matched is made invisible by
    an overlay having an `invisible' property and that overlay has a property
    `isearch-open-invisible', then incremental search will show the contents.
    \(This applies when using `outline.el' and `hideshow.el'.)

    To temporarily change the value for an active incremental search,
    use \\<isearch-mode-map>\\[isearch-toggle-invisible].

    See also the related option `isearch-hide-immediately'.

    See also `reveal-mode' if you want overlays to automatically be opened
    whenever point is in one of them."
#+END_SRC

The discussion of `open' here seems to describe implementation rather
than behaviour.

It's not clear what one is to make of the sentence "This applies when
using `outline.el' and `hideshow.el'."; this almost suggests the
semantics of `open' are undefined elsewhere.

It seems odd to have a function (isearch-toggle-invisible) to "toggle"
the state of a variable that can have three states; cycling seems more
appropriate. In any case looking at the code, it does actually toggle
(between nil and t), but also changes `open' to nil, and then one can
never "toggle" back to `open'. Of course, this applies to
isearch-invisible not search-invisible, so maybe it is not important.

Sorry to be so nit-picky. However, clarifying this a little bit seems
necessary to decide if this bug is a bug and would also seem to present
an opportunity for improving Emacs's docs.






  reply	other threads:[~2015-03-12 14:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12  0:57 bug#20092: 24.4.91; False matches with incremental search in Info N. Jackson
2015-03-12  3:31 ` N. Jackson
2015-03-12 14:29   ` N. Jackson [this message]
2015-03-12 19:16     ` Stefan Monnier
2015-03-12 19:45       ` Juri Linkov
2015-03-13  1:12         ` Stefan Monnier
2020-08-25  9:40         ` Lars Ingebrigtsen
2020-08-25 18:32           ` Juri Linkov
2021-05-10 11:26             ` Lars Ingebrigtsen

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=87bnjy9tn2.fsf@moondust.localdomain \
    --to=nljlistbox2@gmail.com \
    --cc=20092@debbugs.gnu.org \
    /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).