From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: nljlistbox2@gmail.com (N. Jackson) Newsgroups: gmane.emacs.bugs Subject: bug#20092: 24.4.91; False matches with incremental search in Info Date: Thu, 12 Mar 2015 11:29:05 -0300 Message-ID: <87bnjy9tn2.fsf@moondust.localdomain> References: <87egov3udi.fsf@moondust.localdomain> <87zj7ix55f.fsf@moondust.localdomain> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1426170657 21385 80.91.229.3 (12 Mar 2015 14:30:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 Mar 2015 14:30:57 +0000 (UTC) To: 20092@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 12 15:30:45 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YW480-0004Rv-Ty for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Mar 2015 15:30:25 +0100 Original-Received: from localhost ([::1]:60303 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YW47w-0006tx-Qz for geb-bug-gnu-emacs@m.gmane.org; Thu, 12 Mar 2015 10:30:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YW47s-0006te-5r for bug-gnu-emacs@gnu.org; Thu, 12 Mar 2015 10:30:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YW47l-00078g-0V for bug-gnu-emacs@gnu.org; Thu, 12 Mar 2015 10:30:16 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45482) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YW47k-00078K-PC for bug-gnu-emacs@gnu.org; Thu, 12 Mar 2015 10:30:08 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YW47i-0007tL-7u for bug-gnu-emacs@gnu.org; Thu, 12 Mar 2015 10:30:06 -0400 X-Loop: help-debbugs@gnu.org Resent-From: nljlistbox2@gmail.com (N. Jackson) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Mar 2015 14:30:05 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20092 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20092-submit@debbugs.gnu.org id=B20092.142617056030244 (code B ref 20092); Thu, 12 Mar 2015 14:30:05 +0000 Original-Received: (at 20092) by debbugs.gnu.org; 12 Mar 2015 14:29:20 +0000 Original-Received: from localhost ([127.0.0.1]:44050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YW46x-0007rj-II for submit@debbugs.gnu.org; Thu, 12 Mar 2015 10:29:20 -0400 Original-Received: from mail-ig0-f181.google.com ([209.85.213.181]:46772) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YW46v-0007rW-Ee for 20092@debbugs.gnu.org; Thu, 12 Mar 2015 10:29:18 -0400 Original-Received: by igbhl2 with SMTP id hl2so17006196igb.5 for <20092@debbugs.gnu.org>; Thu, 12 Mar 2015 07:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:references:date:in-reply-to:message-id:user-agent :mime-version:content-type:content-transfer-encoding; bh=1iwOyy9+G+hOLAX9l017Zzp0CI4d45japcnLIoHVkdY=; b=bnls2B86fpHj7aBna8ZKu2cDG/SjFKMdJZFx5xNeggk4uQnHsHrA3vxopmW4PXN8uT Zi35b96lT9W0+RBzAgpW0nwax8TlQeAaRmUr+CCJ0485S9mAGJHtdtYTzTdoTOCgBYIr zn7rpeGuxqNV+SlD0fJNX72b3R11xOaLl1VH+m41ykiiao6iiUbDs0SWigsj40Wy1Vg9 oqEQATKO64pgQ2eKdVU9DyB2WGQvRr7MtRJNotky+j/Pjd2kbLmYBR9XtHPk47vLpzFh 3jF/LUcoQbaONp2TljShbHCa5jU4jP5d3cGdA09RqIHGgQrCCkIslwlh2wdCOE6+Kgjl Z22A== X-Received: by 10.107.135.212 with SMTP id r81mr50061326ioi.38.1426170551896; Thu, 12 Mar 2015 07:29:11 -0700 (PDT) Original-Received: from moondust.localdomain.nodomain.none (T86CF.WPA.Dal.Ca. [134.190.134.207]) by mx.google.com with ESMTPSA id j87sm4492604iod.21.2015.03.12.07.29.09 for <20092@debbugs.gnu.org> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Mar 2015 07:29:10 -0700 (PDT) In-Reply-To: <87zj7ix55f.fsf@moondust.localdomain> (N. Jackson's message of "Thu, 12 Mar 2015 00:31:56 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.91 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:100406 Archived-At: 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 =E2=80=98search-invisible=E2=80=99 determines how =E2=80=98= query-replace=E2=80=99 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 =E2=80=98M-s i=E2=80=99.= To change the default for future searches, customize the option =E2=80=98search-invis= ible=E2=80=99. (This option also affects how =E2=80=98query-replace=E2=80=99 and relat= ed functions treat hidden text, *note Query Replace.) You can also automatically make text visible as you navigate in it by using Reveal mode (=E2=80=98M-x reveal-mode=E2=80=99), 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 proper= ty `isearch-open-invisible', then incremental search will show the content= s. \(This applies when using `outline.el' and `hideshow.el'.) To temporarily change the value for an active incremental search, use \\\\[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.