Re: are super-hidden technical blocks required?

[Torsten Wagner <torsten.wagner@gmail.com>]

Hey,

during this discussions people already claimed that they would prefer
to know what is stored and I can understand this.
That was the reason for the proposal of a HIDDEN_PROP: line to mark
certain properties hidden.
The benefit of this approach, people are actively aware of what they
hide and they can hide whatever they want, even stuff which they might
under other working schemes. E.g., for a certain workflow they might
prefer to hide each and all properties.

I can see the point that the property drawer header can be annoying
too. Actually, when I used orgmobile for the first time I was not too
happy to see all this property drawers suddenly appearing in my files.

Even proposing it first, I would not suggest to introduce a second
kind of drawer anymore. Chances are great that people start mixing
informations between two different drawers and then stuff could get
ugly and messy. It also introduce much new syntax and bug-fixing,
problem-solving, and further improvements have to be done for two
almost identically cases.

Alternatively to a new kind of drawer, I would think of the
HIDDEN_PROP: line and an additional method which hides a drawer even
more if it only contains hidden property elements. That could be done,
for example, by the already mentioned custom face.

That is, a drawer is clearly visible if it contains properties intend
to be read/changed by the user (not marked invisible).
A drawer is less visible, if it contains only properties marked as hidden.

Hidden properties do not reveal by the normal way of opening a drawer.
However, there presence might be indicate by a "..." line at the end.
A special key-combo reveals them (e.g. for debugging, or as some kind
of expert-mode).

That would really give the largest amount of flexibility, is backward
compatible, does not introduce to much new syntax ("just" a new header
parameter) and people can easily change what should be visible and
invisible by changing one single line.

BTW. Timestamps of the last changes are really a good example for a
hidden property. I was thinking already of a hashtag created by the
title and body of a node. That could be compared by synctools with the
present hash and thus, local changes could be identified.

If I just would now more about elisp ;)

Greetings

Torsten