From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: Fwd: are super-hidden technical blocks required? Date: Tue, 31 Jul 2012 11:04:18 +0900 Message-ID: References: <87ipd5iu9v.fsf@altern.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([208.118.235.92]:56880) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw1oq-00039W-VM for emacs-orgmode@gnu.org; Mon, 30 Jul 2012 22:04:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Sw1op-0000di-Lk for emacs-orgmode@gnu.org; Mon, 30 Jul 2012 22:04:20 -0400 Received: from mail-vc0-f169.google.com ([209.85.220.169]:40440) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Sw1op-0000dd-Gw for emacs-orgmode@gnu.org; Mon, 30 Jul 2012 22:04:19 -0400 Received: by vcbfl10 with SMTP id fl10so6012959vcb.0 for ; Mon, 30 Jul 2012 19:04:19 -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 Sorry I forgot to CC the list. ---------- Forwarded message ---------- From: Torsten Wagner Date: 30 July 2012 17:42 Subject: Re: are super-hidden technical blocks required? To: Bastien Hi Bastien, I just think normal blocks or drawers are used by many org-user for very different reasons and many store personal data into it. After all, we love the flexibility in org-mode right :) However, something which is saved in a org-mode file by another application might not be intended to be read (nor modified) by users directly. Hence having a mix of user data and non-user data in the same drawer or property seems to me kind of annoying for the user and maybe even dangerous, since you might brake something accidentely. Thus, I was thinking of a block specially reserved for non-user interaction. Completely hidden in all kind of views and maybe only visible for debugging or expert-usage. Examples would be the ID properties used by MobileOrg or UUID recently used by org-caldav.el. Basically, all and everything which comes from a automatic import/export/two-way sync and which is not intend to be changed by the user directly. Guess there might be useful for stuff from odf-import/export too. Other programs might have properties (e.g. title color, notify sound, etc.) which have no equivalent in org-mode but it would be nice to save them for a two-way sync. As far as I understood two-way syncs with other programs are still tricky because there is no standard way how to save information necessary for the other side of the sync-chain. My idea was something like * Test :DATA-PROPERTIES: :UUID: :CALENDAR-NAME: :SERVER_ADDRESS: :TIMESTAMP_SERVER: :HASH-TAG: :PROGRAM-FOO-PROPERTY: :END: which should be simply * Test in all normal org-mode views (or use a very minimalistic out of the way indicator ?!) not sure how well this would work out and maybe some people do not like it since it hiding stuff. Others might like it because it removes certain cluttering of (not as useful) information from the normal views. Just an idea Torsten On 30 July 2012 16:26, Bastien wrote: > Hi Torsten, > > I don't think this is about plain text vs =C4=85 la XML (because XML and > friends are plain text too) but about whether we should allow a new > type of block to keep non-human-readable stuff out of the way. > > One thing I don't get is how these blocks would be more hidden than > normal blocks or drawers. > > Another thing I'm not sure about is what kind of technical stuff > you have in mind. I see what you mean for UUID, but note that this > is not a problem of the :ID: property itself (which can hold a human > readable value), but of the value of this property when using UUIDs. > > Speculating about Org possibilities is one of the fun here, so I > would not mind reading a more precise example. > > But in general, as one can more or less guess, I'm more of a less > person. :) > > -- > Bastien