From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: how to control isearch for invisible text Date: Sat, 12 Aug 2006 19:16:44 +0200 Message-ID: <85slk16fib.fsf@lola.goethe.zz> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1155403042 11380 80.91.229.2 (12 Aug 2006 17:17:22 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 Aug 2006 17:17:22 +0000 (UTC) Cc: Emacs-Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 12 19:17:21 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GBx6p-0002hn-Dz for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2006 19:17:15 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GBx6o-0008Oa-LV for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2006 13:17:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GBx6X-0008LM-Sx for emacs-devel@gnu.org; Sat, 12 Aug 2006 13:16:57 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GBx6W-0008Jj-Mr for emacs-devel@gnu.org; Sat, 12 Aug 2006 13:16:57 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GBx6W-0008JX-Gd for emacs-devel@gnu.org; Sat, 12 Aug 2006 13:16:56 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GBxBv-0006Hc-KN for emacs-devel@gnu.org; Sat, 12 Aug 2006 13:22:31 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GBx6V-000282-VJ; Sat, 12 Aug 2006 13:16:56 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 984DA1C4D3AD; Sat, 12 Aug 2006 19:16:44 +0200 (CEST) Original-To: "Drew Adams" In-Reply-To: (Drew Adams's message of "Sat, 12 Aug 2006 10:09:44 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58325 Archived-At: "Drew Adams" writes: > > It seems like there should be some way to control whether > > isearch matches text that is invisible or ignores it. > > > If there is no option..., then how about adding one? > > And adding an isearch keymap binding for toggling the > > option while searching. > > > It would be a plus if the same option could act > > similarly for query-replace and occur. For query-replace, > > perhaps the same toggle binding could be used. > > M-x apropos-documentation RET isearch.*invisible RET > > Thanks. > > So, now, how about: > > - documenting `isearch-invisible' in the Emacs manual? It is `search-invisible'. 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. > - and the Elisp manual? Not sure whether it is important enough for that. > - creating a toggle for it? Why? It is not a user-level feature. Providing a toggle would be the task of any mode that makes stuff invisible and that would require to have it accessible. > - 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. > 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. Fiddling with invisibility-spec would affect all invisible regions, not just the one at point. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum