From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#60399: 30.0.50; Usage of `isearch-open-invisible-temporary' is not documented Date: Tue, 03 Jan 2023 09:14:20 -0500 Message-ID: References: <87tu1ev7uu.fsf@localhost> <865yduf73m.fsf@mail.linkov.net> <87mt73afow.fsf@localhost> <83zgb239rv.fsf@gnu.org> <87edse8vu1.fsf@localhost> <83wn6634gb.fsf@gnu.org> <87bkni8lk3.fsf@localhost> <87mt70kn3d.fsf@localhost> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15271"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 60399-done@debbugs.gnu.org, Eli Zaretskii , 60399@debbugs.gnu.org, juri@linkov.net To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jan 03 15:15:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pCi4a-0003lx-JG for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 Jan 2023 15:15:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pCi4H-00043z-Mz; Tue, 03 Jan 2023 09:15:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pCi4F-00043X-14 for bug-gnu-emacs@gnu.org; Tue, 03 Jan 2023 09:15:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pCi4E-00056A-NR for bug-gnu-emacs@gnu.org; Tue, 03 Jan 2023 09:15:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pCi4E-0006pg-JC for bug-gnu-emacs@gnu.org; Tue, 03 Jan 2023 09:15:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 Jan 2023 14:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60399 X-GNU-PR-Package: emacs Original-Received: via spool by 60399-done@debbugs.gnu.org id=D60399.167275528026203 (code D ref 60399); Tue, 03 Jan 2023 14:15:02 +0000 Original-Received: (at 60399-done) by debbugs.gnu.org; 3 Jan 2023 14:14:40 +0000 Original-Received: from localhost ([127.0.0.1]:45003 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pCi3r-0006oY-LI for submit@debbugs.gnu.org; Tue, 03 Jan 2023 09:14:39 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54675) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pCi3n-0006oF-9M; Tue, 03 Jan 2023 09:14:38 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C65AB4410F3; Tue, 3 Jan 2023 09:14:28 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B3D644400EA; Tue, 3 Jan 2023 09:14:26 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1672755266; bh=Ggz3SB2yranz7uKORCVLJl1ACVQu8/dCfQ7565feOgo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hdC4RRXtO0n8eYLNDbId+sgpQJejjElVTsVnqm+ymjNchuoszlGkv/Eq2AdeSeysY fqB6hv6B/m5L3Yh3K+PHiLyO5BI5JHOxO4X+VfrT+NwuEHGzVIJUmONrCcanpdDnlW +VsuQvAMrAyCPLEqNjVb5BqQ3dfYx8lcPJdfqgp6S4d6JHlkvr51r/H7xmtqXEkouW 7yCG8WH1Hc0qv0U29Xm3XG9RhuNVJPVGtXE/KT99E7aHDH6eM3tx9whOPwk5KpJJbp 3ZYNkNAt4HMTpFELwMt77JXjiEpwQAIrl4TjcP9tHDvEvlfo9wLmC/6ZFLNXcOvkvJ XRPk79BrOfoEw== Original-Received: from pastel (unknown [45.72.200.228]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 865BC12043B; Tue, 3 Jan 2023 09:14:26 -0500 (EST) In-Reply-To: <87mt70kn3d.fsf@localhost> (Ihor Radchenko's message of "Tue, 03 Jan 2023 09:02:14 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252405 Archived-At: >> But it's very natural that the caller of that >> `isearch-open-invisible-temporary` may still want to know the boundaries >> of this overlay after its content is made visible, so as to know when to >> make it invisible again. > > I am not sure why isearch should decide this instead of letting > `isearch-open-invisible-temporary' decide what to close. The question is not just what to close but *when*. Isearch need to tell your code when it thinks you can close. It's natural to use the overlay's boundaries to decide when to do that, and it's natural to use that overlay as "the info about what to close" when i calls you back. I'm not claiming it's perfect or ideal. It's just a fairly natural choice. Note that in `reveal.el` I use a similar API but with a twist: after calling `reveal-toggle-invisible`, `reveal.el` checks whether the points we're interested in have been made visible and if not, we take the (new) overlays and repeat. This way, to get the behavior you say you want for Org (which we get in `outline-mode` with `reveal-mode`) we just arrange for `reveal-toggle-invisible` to show the headings "one level down" (and re-hide everything else): if that's not enough, `reveal.el` then calls `reveal-toggle-invisible` inside one of the subheadings until we're at the actual leaf. This addresses a major shortcoming of the `isearch-open-invisible-temporary' which is that the function is not told which part of the overlay needs to be opened. The best the function can do is presume that `point` is the thing of interest, but it's not specified anywhere (and in the case of `reveal.el` it's not sufficient because we may have several points to reveal at the same time). >> `reveal-toggle-invisible` works basically the same way as >> `isearch-open-invisible-temporary` and in >> `outline-reveal-toggle-invisible` I had the same problem as you do, >> which I solved with: >> >> (let ((o1 (copy-overlay o))) >> (overlay-put o 'invisible nil) ;Show (most of) the text. > > This is a nice trick, which is unfortunately not very useful in my > situation. Some text should still remain invisible in Org even when > opening is requested. Your code reveals everything unconditionally. There's a misunderstanding here: `outline-reveal-toggle-invisible` reveals only the immediate children. All it reveals is basically: (outline-show-entry) (outline-show-children) -- Stefan