John Mathena <jmmath...@gmail.com> writes: Confirmed.
> It seems like the visibility property on a parent heading overrides > the visibility property on a child heading - is this expected? e.g. > when I have the raw text: > > * Foo > :PROPERTIES: > :VISIBILITY: content > :END: > ** Bar > :PROPERTIES: > :VISIBILITY: folded > :END: > *** Baz > > ... I would expect (and would like) to see > > * Foo... > * Bar... > > that is, where Foo shows only the content below it, and Bar has all of > its children folded. Instead, I get > > * Foo... > * Bar... > * Baz... The behaviour you observe is because org-cycle-set-visibility-according-to-property explicitly ignores all the VISIBILITY properties in all the descendent headings of a heading with VISIBILITY property. i.e. VISIBILITY property of Bar is ignored when its ancestor Foo has VISIBILITY property. This behaviour is not documented in the manual: >> Furthermore, any entries with a ‘VISIBILITY’ property (see *note >> Properties and Columns::) get their visibility adapted accordingly. >> Allowed values for this property are ‘folded’, ‘children’, ‘content’, >> and ‘all’. I would say that the existing behaviour is a confusing and might be considered as a bug. However, it may not always be straightforward how to deal with different combinations of VISIBILITY setting for ancestor/descendent headings. Consider the following example: * Foo :PROPERTIES: :VISIBILITY: folded :END: ** Bar :PROPERTIES: :VISIBILITY: content :END: *** Baz Foo is supposed to be folded, but it is unclear how to process Bar. Should Bar's contents be visible? Should it be folded? Best, Ihor
