[Top][All Lists]

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

bug#14731: 24.3.50; doc string of `search-invisible'

From: Drew Adams
Subject: bug#14731: 24.3.50; doc string of `search-invisible'
Date: Thu, 27 Jun 2013 10:31:38 -0700 (PDT)

> > "If t incremental search can match hidden text."
> I don't see any reason why non-nil would be better.
> People using non-nil non-t values are on their own,

Huh?  Did you read the rest of the doc string, which mentions
`open'?  The first line of the doc string should stand on its own.

There are specifically three useful values: nil, t, and `open'.
t and `open' do not behave the same.  And those are the 3 values of
user option `search-invisible'.  `open' is hardly something hidden
from users - they are not "on their own" with `open'.

If you prefer, then say "If nil then incremental search does not
match hidden text."

That is also more correct, because it does not promise more than
is delivered.  `open' does NOT cause isearch to match text that is
hidden using a text property (`invisible').  `open' works only for
only certain kinds of hidden text (from specific kinds of overlays,
not from text properties).

Yes, you can hide behind the ambiguity of the words "CAN match",
but it is clearer to say that nil means isearch does not match
hidden text.

(BTW, this fact is undocumented: t does cause isearch to match such
hidden occurrences.  Unlike `open', t does not require that the text
be hidden using an overlay.)

reply via email to

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