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
