Re: [O] are super-hidden technical blocks required?

[Torsten Wagner]

Hi,

I was aware that some people would prefer a more transparent way.
I think a technical property block accessible for third party sync
tools would make it much easier for the developers of those tools.
On the other hand I understand that people want to know what is stored
along within there org-files.

One Idea I had and which was mentioned by Rasmus already too, would be
to use the same property block but being able to hide certain
properties

#+ HIDE_PROP: ID, UUID, ODF_PROP, MOBILE_ORG_PROP

I guess many people use only one or the other third party tool and
hence once set-up correctly in there files, its rather easy to mask
them invisible or visible depending on personal preferences and needs.
This approach makes people also actively aware of those properties and
does not try to hide them.

Maybe for the upcoming future if programs would like to introduce
rather many properties the list could be sensitive to wildcards?!
so #+ HIDE_PROP: ODF_*
would hide all properties introduced for ODF in- and export.

even a pure technical block could be realized by this if there is a
rule to start properties of sole technical purpose by a certain
key-character e.g. a underline (if this is legal as property name, not
sure about). Then _* would hide all technical properties. _ODF_* hides
all technical properties for ODF _OM_* does the same for orgmobile,
etc.  Developers could decide whether a property is more of technical
nature or if user should be more aware of it (and possibly change it).
Using not only wildcards but real regular expression (which might not
be to difficult in elisp) would make this even more flexible.

To indicate that a property block contains hidden technical properties
I guess, as usual in org-mode a  line of "..." could indicate this.
E.g.,
#+ HIDE_PROP: _*
* Test
:PROPERTIES:
:name: Max Muster
:address: Muster-Street 1,
:tel: 11223344
...
:END:

#+ HIDE_PROP:
* Test
:PROPERTIES:
:name: Max Muster
:address: Muster-Street 1,
:tel: 11223344
:_UUID: 123j2k2j32kj332k1j2h1ghj1g321
:_OM_COLOUR: red
:_OM_image: ./max_muster.jpg
:_SYNC_TS_UNIX: 1342483647
:_OR_CODE: ./max_muster_QR.png
:END:

I guess this solution would fit to everyone, people who like to know
what is stored within there org-files and people who want a clutter
free org-file for easy reading (and sure people can easily switch
between both approaches). Finally, developers would have a rather easy
and out-of-the-way possibility to save as much information within the
org-file as needed to e.g. enable 2-way syncs with other programs.
After all, everything still keeps plain text.

Any thoughts?

Torsten