From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: how to control isearch for invisible text Date: Sat, 12 Aug 2006 10:56:55 -0700 Message-ID: References: <85slk16fib.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1155405448 17249 80.91.229.2 (12 Aug 2006 17:57:28 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 12 Aug 2006 17:57:28 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 12 19:57:27 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 1GBxji-0000Wo-U6 for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2006 19:57:27 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GBxji-0005op-1i for ged-emacs-devel@m.gmane.org; Sat, 12 Aug 2006 13:57:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GBxjX-0005oY-Np for emacs-devel@gnu.org; Sat, 12 Aug 2006 13:57:15 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GBxjX-0005oM-5C for emacs-devel@gnu.org; Sat, 12 Aug 2006 13:57:15 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GBxjW-0005oE-UN for emacs-devel@gnu.org; Sat, 12 Aug 2006 13:57:14 -0400 Original-Received: from [141.146.126.228] (helo=agminet01.oracle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.52) id 1GBxow-0001Hs-0g for emacs-devel@gnu.org; Sat, 12 Aug 2006 14:02:50 -0400 Original-Received: from rgmgw1.us.oracle.com (rgmgw1.us.oracle.com [138.1.186.110]) by agminet01.oracle.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k7CHvBKV020898 for ; Sat, 12 Aug 2006 12:57:11 -0500 Original-Received: from dradamslap (dhcp-amer-csvpn-gw1-141-144-65-8.vpn.oracle.com [141.144.65.8]) by rgmgw1.us.oracle.com (Switch-3.1.7/Switch-3.1.7) with SMTP id k7CHvALM029810 for ; Sat, 12 Aug 2006 11:57:11 -0600 Original-To: "Emacs-Devel" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <85slk16fib.fsf@lola.goethe.zz> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE 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:58329 Archived-At: > So, now, how about: > > - documenting `isearch-invisible' in the Emacs manual? It is `search-invisible'. Oops; sorry. 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? 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. > - 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(!). 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? 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. > - 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, for various reasons. Query-replace is general, just like isearch. 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. > 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. 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?