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 21:21:02 +0200 Message-ID: <854pwh69r5.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 1155410494 29876 80.91.229.2 (12 Aug 2006 19:21:34 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 Aug 2006 19:21:34 +0000 (UTC) Cc: Emacs-Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 12 21:21:33 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 1GBz35-0005O5-ND for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2006 21:21:32 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GBz35-000184-2A for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2006 15:21:31 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GBz2r-00015Q-54 for emacs-devel@gnu.org; Sat, 12 Aug 2006 15:21:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GBz2p-00012G-IO for emacs-devel@gnu.org; Sat, 12 Aug 2006 15:21:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GBz2p-00011u-Cf for emacs-devel@gnu.org; Sat, 12 Aug 2006 15:21:15 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GBz8F-0007oq-L3 for emacs-devel@gnu.org; Sat, 12 Aug 2006 15:26:51 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1GBz2o-0007sn-DF; Sat, 12 Aug 2006 15:21:15 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id A06E51C4D3AD; Sat, 12 Aug 2006 21:21:02 +0200 (CEST) Original-To: "Drew Adams" In-Reply-To: (Drew Adams's message of "Sat, 12 Aug 2006 10:56:55 -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:58331 Archived-At: "Drew Adams" writes: > 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. > > Then why is it a defcustom? Why can you customize it? Not much of a reason I see there. > I don't think it's special, or I wouldn't, as a user, have asked for > such a feature. I don't see why this shouldn't be useful for > users. When I'm searching, and there is some invisible text (which I > may or may not know), I'd like to be able to toggle isearch, to make > it (in)sensitive to that text. > > > - and the Elisp manual? > > Not sure whether it is important enough for that. > > I think it's especially important for the Emacs manual. I don't, and I explained why. > > - creating a toggle for it? > > Why? It is not a user-level feature. > > It's a user option - customizable. And so it should be, IMO. That's > why I was asking for such an option - as a user. I want to > interactively control whether isearch hits hidden text. One use is > to find whether something particular is perhaps present but > hidden(!). But that depends on the mode in question. > Providing a toggle would be the task of any mode that makes > stuff invisible and that would require to have it accessible. > > Why would each mode do that? Because invisibility does not serve a unique purpose. > Why not have a general toggle for isearch - the same binding for all > modes? If I have a mode that hides dired details, that mode will > provide a toggle to show/hide the details, but it shouldn't have to > also provide a toggle for isearch sensitivity to hidden text. If > each mode does that, then users will not have a single, consistent > binding to rely on - and the toggle should be available while > isearching. To me, this is no different from toggling > case-sensitivity or regexp sensitivity. To me it is. Case is not something a mode applies to a buffer, nor are regexps. > > - 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. > > I think the use case is basically the same, for isearch, occur, and > query-replace. I can imagine a mode that might temporarily or > selectively hide things in an *Occur* buffer, Who is talking about the occur buffer? We are talking about the source buffer. The occur buffer would not copy overlays, anyway. > for various reasons. Query-replace is general, just like isearch. I said it sounded reasonable for query-replace. > I can imagine that one might be able to get into trouble using > query-replace with invisible hits, but I also think it could be > useful. Invisible hits are made visible when searching: no trouble here. > > 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. > > Ah, I guess you mean that the parallel use case would exist for text > without overlays, but it would be difficult or impossible to > implement. No, the parallel use case does not exist. Text with invisible property is intended to never be a visible part of the buffer. Overlays, in contrast, can be removed and put back without a buffer change. > Fiddling with invisibility-spec would affect all invisible regions, > not just the one at point. > > Not sure I understand what you mean, there. Is that part of the > explanation of the implementation difficulty? There is no implementation difficulty. It is not useful to search for text that is not part of the visible buffer and can't become so without changing its properties. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum