From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: Re: are super-hidden technical blocks required? Date: Tue, 31 Jul 2012 11:48:51 +0900 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:40041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw2Vx-0001Y6-7f for emacs-orgmode@gnu.org; Mon, 30 Jul 2012 22:48:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sw2Vw-00074s-7L for emacs-orgmode@gnu.org; Mon, 30 Jul 2012 22:48:53 -0400 Received: from mail-vb0-f41.google.com ([209.85.212.41]:44934) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw2Vw-00074d-1n for emacs-orgmode@gnu.org; Mon, 30 Jul 2012 22:48:52 -0400 Received: by vbkv13 with SMTP id v13so5987960vbk.0 for ; Mon, 30 Jul 2012 19:48:51 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org Mode Mailing List 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