Hello,
Samuel Wales <samolog...@gmail.com> writes:
> thanks for clarifying. that seems to eliminate all possibility of
> specifying canonical visibility using org show variables.
Indeed.
> thus, this is a feature that is strangely missing in org, as opposed
> to a bug.
I agree. Also, I find the configuration in this area overly complicated.
> canonical visibility roughly means a visibility state that can be
> created at any time using org-cycle and arrow keys.
>
> for example, if only the first child is showing, then it is not
> canonical visibility. the only things that should NOT show are
> entirely folded headers, blocks, etc.
>
> this is the only kind of visibility that i ever use unless i am doing
> a sparse tree, which is extremely rare.
I think we could simplify the show context configuration and, at the
same time, provide a way to show "canonical visibility".
For example, we can merge `org-show-hierarchy-above',
`org-show-following-heading', `org-show-siblings' and
`org-show-entry-below' into a single variable,
`org-show-context-detail', where each context is associated to a level,
e.g., for current default configuration,
((default . 2)
(occur-tree . 1)
(tags-tree . 1)
(isearch . 3)
(bookmark-jump . 3))
where
1. means only the minimal location is shown, i.e., top level
headline + headline, and section (no child) if match is not on
a headline.
2. means context 1 + hierarchy above
3. means context 2 + siblings
4. means canonical view, i.e, show full hierarchy above and siblings,
and, if match is within a section, show also section and all
children.
We lose a bit of control, but I think left out combinations are not very
interesting. But I may be wrong.
WDYT?
Regards,
--
Nicolas Goaziou
