Carlos Pita <carlosjosepi...@gmail.com> 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 hidden and
> then revealed, because that will just change my question to why
> top-levels are not hidden to begin with. Again:
>
> The tree will show the lines where the regexp matches, and any other
> context
> defined in ‘org-show-context-detail’, which see.
>
> The top-level headings in my example don't match the regexp and are
> not part of the context that org-show-context-detail should reveal
> with my current configuration. I cannot help concluding that this fact
> contradicts the documentation.
Currently, Org never ever hides headlines without parent and the top
section of the Org buffers.
Note that org-occur's docstring never explicitly states that all
non-matching lines will be hidden, just that matching lines will be
revealed and that the tree will be "compact". Though I understand your
confusion and I do agree that we should either clarify the docstring or
change org-occur to hide non-matching subtrees.
Changing org-occur is actually trivial (just one LOC), but this would be
a major change and can catch old Org users by surprise. I would prefer
to hear other's opinions before pushing such patch upsteam.
>> Consider agenda views. The relevant default value in
>
> I indeed considered the agenda, but I prefer using a sparse tree. I
> have a file with a large number of brief notes in top level headings
> and it's useful to see the expanded matching notes, the behaviour of
> org-occur is ideal in this regard, instead the agenda only shows the
> headings and even in follow mode it's more cumbersome than merely
> pressing M-g n/p directly in the target buffer.
FYI, there is org-agenda-entry-text-mode ("E" in agenda buffers).
Best,
Ihor
