From mboxrd@z Thu Jan 1 00:00:00 1970 From: Torsten Wagner Subject: Re: are super-hidden technical blocks required? Date: Mon, 6 Aug 2012 11:46:19 +0900 Message-ID: References: <20120730144259.GA1017@nausicaa.localdomain> <873941bsvs.fsf@gnu.org> <501ED1B7.5070808@alum.mit.edu> <87lihtasl3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from eggs.gnu.org ([208.118.235.92]:42398) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyDKn-0007Db-EY for emacs-orgmode@gnu.org; Sun, 05 Aug 2012 22:46:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SyDKm-0008EJ-Dq for emacs-orgmode@gnu.org; Sun, 05 Aug 2012 22:46:21 -0400 Received: from mail-yx0-f169.google.com ([209.85.213.169]:64346) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyDKm-0008EE-9d for emacs-orgmode@gnu.org; Sun, 05 Aug 2012 22:46:20 -0400 Received: by yenr5 with SMTP id r5so2306402yen.0 for ; Sun, 05 Aug 2012 19:46: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: Ilya Shlyakhter Cc: emacs-orgmode@gnu.org, Nicolas Goaziou 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