Carlos Pita writes:
>> I think you misread the docstring for org-show-context-detail:
>
> Sorry, I don't concur here.
>
> This is in the docstring I'm interested in (org-occur):
I agree that org-occur could have a better docstring.
> It's not very relevant to my concern if things are first
Hi Ihor,
On Thu, Nov 18, 2021 at 7:28 AM Ihor Radchenko wrote:
>
> Carlos Pita writes:
>
> > I see no reason why a match inside b2 will hide b1 and b3 but not a
> > and c (I'm referring to the headings, not the contents).
>
> I think you misread the docstring for org-show-context-detail:
Carlos Pita writes:
> I see no reason why a match inside b2 will hide b1 and b3 but not a
> and c (I'm referring to the headings, not the contents).
I think you misread the docstring for org-show-context-detail:
>> Alist between context and visibility span when **revealing** a ;; <--
>>
As a concrete example:
* a
ca
* b
** ba
cba
** bb
cbb
** bc
cbc
* c
cc
Then C-c / / cbb:
* a...
* b...
** bb
cbb
...
* c...
This is also true going deeper into the hierarchy:
* a
ca
* b
** ba
cba
** bb
*** bba
cbba
*** bbb
cbbb
*** bbc
cbbc
** bc
cbc
* c
cc
Then C-c / / cbbb:
* a...
* b...
Hi Ihor,
> Can you elaborate? If the docstring is not clear enough, we can easily
> improve it.
Consider for example:
minimal show current headline; if point is not on headline, also
show entry
So if you have:
* a
* b
** b1
** b2
** b3
* c
I see no reason why a match inside b2 will
Carlos Pita writes:
> Hi all,
>
> I don't see any clear reason why org-occur should hide unmatching
> entries except at the top level, where it merely folds them. For files
> containing lots of top-level entries this requires tree demoting in
> order to hide irrelevant information, but this
Hi all,
I don't see any clear reason why org-occur should hide unmatching
entries except at the top level, where it merely folds them. For files
containing lots of top-level entries this requires tree demoting in
order to hide irrelevant information, but this imposes constraints on
the tree
