From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: are super-hidden technical blocks required? Date: Mon, 30 Jul 2012 11:26:10 +0900 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:51548) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvfgS-0004mh-0I for emacs-orgmode@gnu.org; Sun, 29 Jul 2012 22:26:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SvfgR-0006MD-2S for emacs-orgmode@gnu.org; Sun, 29 Jul 2012 22:26:11 -0400 Received: from mail-vb0-f41.google.com ([209.85.212.41]:55486) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SvfgQ-0006LF-SJ for emacs-orgmode@gnu.org; Sun, 29 Jul 2012 22:26:10 -0400 Received: by vbkv13 with SMTP id v13so4714885vbk.0 for ; Sun, 29 Jul 2012 19:26:10 -0700 (PDT) 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 notice that with all this upcoming syncing and interaction with third party programs as well as with programming languages org-mode starts to require more and more information which are actually not intend to be read in plain text. E.g. a UUID-number for each task to enable two-way syncs with calendars. Following the mailing list, I notice that it gets more and more difficult for the devs to keep track of how to handle the text parsing and each fix in the parsers need to be carefully checked against a steadily increasing amount of cases to avoid the introduction of new problems. First I was wondering if it would be time to switch org-mode from text to some sort of XML. The advantages would be a much much easier way to parse data and it would make many many things for the devs much easier. However, switching org-mode to some sort of XML would be against one of its key-features... being plain text. There are property-blocks and drawers to "hide" stuff, but at the moment they contain a mixed set of data relevant and non-relevant for a user. Would it help to introduce a technical-property block which only contains information intend to be used by other programs and parsers? This blocks could be hidden under all normal means unlike really someone want to see them and hit a special key-combo. That might be a way to keep the format clean and plain text but get some of the features known e.g. from XML. I know this might be tricky esp. copy and paste operations need to take care that those blocks get correctly moved. What do you think? Torsten