From mboxrd@z Thu Jan 1 00:00:00 1970 From: Robert Horn Subject: Re: are super-hidden technical blocks required? Date: Tue, 31 Jul 2012 09:23:32 -0400 Message-ID: References: <20120730144259.GA1017@nausicaa.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([208.118.235.92]:51837) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwCQG-00040F-10 for emacs-orgmode@gnu.org; Tue, 31 Jul 2012 09:23:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SwCQA-0002ne-1c for emacs-orgmode@gnu.org; Tue, 31 Jul 2012 09:23:39 -0400 Received: from mailbackend.panix.com ([166.84.1.89]:60776) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SwCQ9-0002nW-US for emacs-orgmode@gnu.org; Tue, 31 Jul 2012 09:23:33 -0400 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: Jonathan Leech-Pepin , Ivy Foster Cc: Org Mode Mailing List Jonathan Leech-Pepin writes: > Hi, >>> This blocks could be hidden under all normal means unlike >>> really someone want to see them and hit a special >>> key-combo. >> >> Hmm, personally I'd rather have it visible but clearly >> labeled. Transparency is nearly always a good thing. >> > I agree. The real use needs more clarification. Things like ID are already well hidden as :PROPERTIES: until the user explicitly opens the drawer for viewing. I don't understand the need to hide those further, so a better explanation of why is needed. I could see a use for a "blob" property. Suppose I have a JPEG of someone's portrait that I want to incorporate into a contact's properties. Some mechanism to indicate: :PROPERTIES: :Portrait: blob-flag application/jpeg alternate-text="Joe's picture" <> :END: with a third level of lisp-function that will open the blob contents as ugly encoded text or with a decoding/viewing function instead of the text "<>". I could see this being useful for both textual items like S-exprs, XML, JSON, etc. and for binary things like JPEG, PDF, etc. It could be similar to the current embedding done for literate programming with a way to separate blob content from org content. Right now the link capabilities are available for blob-like uses, but links don't work if I need to move the org-mode files between machines, etc. R Horn rjhorn@alum.mit.edu