[FR] Make org-occur highlights always visible, even upon folding (was: Bug or expected behavior? org-sparse-tree visibility toggling)

[Ihor Radchenko]

Cassio Koshikumo  writes:

> Hm. It makes sense that TAB is not affected... Somehow I hadn't really
> considered that.
>
> What I expected to happen (and now I realize it was not a justified
> expectation) was to have the visibility of the sparse-tree kept while
> tabbing. So I could expand a tree, then collapse it again, all the
> while keeping the sparse-tree "filter" applied. But I guess it doesn't
> make much sense.
>
> Well, I guess I could leave it as a suggestion for new functionality,
> but I don't even know if it's feasible.

It is not very hard to do, actually. See the attached patch.

However, I am not sure if it is something of interest for other Org
users.

If there is more support, I can convert the patch into proper new Org
feature, adding customization and necessary ORG-NEWS announcement.

>From d3e8d0a9fc235b025f005158cc51f21e5e2ec8ee Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Fri, 24 Mar 2023 13:10:37 +0100
Subject: [PATCH] org-highlight-new-match: Make highlights always visible

* lisp/org.el (org-highlight-new-match): Make highlights always
visible, even upon folding.
---
 lisp/org.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index 20e6ea6d9..1834eadbc 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -10762,10 +10762,15 @@ (defun org-occur-next-match ( n _reset)
 
 (defun org-highlight-new-match (beg end)
   "Highlight from BEG to END and mark the highlight is an occur headline."
-  (let ((ov (make-overlay beg end)))
+  (let ((ov (make-overlay beg end))
+(ov-line (make-overlay
+  (org-with-point-at beg (max (point-min) (1- (pos-bol
+  (org-with-point-at end (pos-eol)
 (overlay-put ov 'face 'secondary-selection)
 (overlay-put ov 'org-type 'org-occur)
-(push ov org-occur-highlights)))
+(overlay-put ov-line 'invisible 'org-occur)
+(push ov org-occur-highlights)
+(push ov-line org-occur-highlights)))
 
 (defun org-remove-occur-highlights ( _beg _end noremove)
   "Remove the occur highlights from the buffer.
-- 
2.39.1


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Bug or expected behavior? org-sparse-tree visibility toggling

[Cassio Koshikumo]

Hm. It makes sense that TAB is not affected... Somehow I hadn't really
considered that.

What I expected to happen (and now I realize it was not a justified
expectation) was to have the visibility of the sparse-tree kept while
tabbing. So I could expand a tree, then collapse it again, all the
while keeping the sparse-tree "filter" applied. But I guess it doesn't
make much sense.

Well, I guess I could leave it as a suggestion for new functionality,
but I don't even know if it's feasible.

Thanks!


On Sun, Feb 26, 2023 at 8:52 AM Ihor Radchenko  wrote:
>
> Cassio Koshikumo  writes:
>
> > Create an .org file with the following contents:
> >
> > * First Level
> > ...
> > Now, C-c / m (or M-x org-sparse-tree and select m) and Match: tag.
> >
> > The resulting sparse tree looks like this:
> >
> > * First Level
> > ** One :tag:
> > *** Child
> > ** Four :tag:
> >
> > So far, so good. Now, put point on heading One and press TAB. Child is 
> > hidden.
> >
> > The problem: press TAB again. Now Two and Three are also shown,
> > effectively breaking the sparse tree filtering. (Actually Five is
> > shown, too, it seems...)
>
>  is not affected by sparse tree.
> Sparse tree just reveals headings that match certain criteria and
> highlights them.
>
> May you describe what you expected to happen?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 



-- 
Cassio Koshikumo

Re: Bug or expected behavior? org-sparse-tree visibility toggling

[Ihor Radchenko]

Cassio Koshikumo  writes:

> Create an .org file with the following contents:
>
> * First Level
> ...
> Now, C-c / m (or M-x org-sparse-tree and select m) and Match: tag.
>
> The resulting sparse tree looks like this:
>
> * First Level
> ** One :tag:
> *** Child
> ** Four :tag:
>
> So far, so good. Now, put point on heading One and press TAB. Child is hidden.
>
> The problem: press TAB again. Now Two and Three are also shown,
> effectively breaking the sparse tree filtering. (Actually Five is
> shown, too, it seems...)

 is not affected by sparse tree.
Sparse tree just reveals headings that match certain criteria and
highlights them.

May you describe what you expected to happen?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Bug or expected behavior? org-sparse-tree visibility toggling

[Cassio Koshikumo]

I don't know if this can be considered a bug or if I'm trying to do
something not supported.

Create an .org file with the following contents:

* First Level
** One :tag:
*** Child
** Two
** Three
** Four :tag:
** Five

Now, C-c / m (or M-x org-sparse-tree and select m) and Match: tag.

The resulting sparse tree looks like this:

* First Level
** One :tag:
*** Child
** Four :tag:

So far, so good. Now, put point on heading One and press TAB. Child is hidden.

The problem: press TAB again. Now Two and Three are also shown,
effectively breaking the sparse tree filtering. (Actually Five is
shown, too, it seems...)

As far as I can tell, this only happens when the heading has a
subheading, like Child. But even when dealing with headings that DON'T
have a subheading, the ellipsis kinda breaks and ends up in the next
line, and successive TABs do nothing.

(In fact, I was trying different variations of the tree just now and
it seems the behavior is WILDLY inconsistent. If there's a blank line
between One and Child, then the first TABalready messes the tree up.
Don't know if further variations produce other results.)

So, can these behaviors be considered bugs? Or are sparse trees not
meant to have their visibility manipulated like this, and should be
considered a static, filtered view of the tree, with interactions
discouraged?

Thanks!

-- 
Cassio Koshikumo