From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Schulte Subject: Re: [BUG] Inconsistency in src block hiding Date: Mon, 23 Jan 2012 20:41:48 -0700 Message-ID: <87k44hn4uz.fsf@gmx.com> References: <8739djqfkv.fsf@gmail.com> <87fwhiwwr0.fsf@gmail.com> <87bos6pp1a.fsf@gmail.com> <8739dhnxjs.fsf@gmail.com> <87ipmcxboo.fsf@gmail.com> <87pqgjipu8.fsf@gmail.com> <87y5v6x3lv.fsf@gmail.com> <87fwh86533.fsf@gmail.com> <87ehwbdxk2.fsf@gnu.org> <874nx782wi.fsf@gmx.com> <87lip76p48.fsf@norang.ca> <87d3ai2p98.fsf@gmail.com> <8762ga6whl.fsf@norang.ca> <87pqehrnjv.fsf@gmx.com> <8739bc3ob5.fsf@gmail.com> <87ehuv4la3.fsf@gmx.com> <87ty3r4hop.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:44559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpXHI-0003zr-Eo for emacs-orgmode@gnu.org; Mon, 23 Jan 2012 22:42:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpXHG-000561-Qv for emacs-orgmode@gnu.org; Mon, 23 Jan 2012 22:42:36 -0500 Received: from mailout-us.gmx.com ([74.208.5.67]:39134) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1RpXHG-00055u-C1 for emacs-orgmode@gnu.org; Mon, 23 Jan 2012 22:42:34 -0500 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: Nicolas Goaziou Cc: Rick Frankel , emacs-orgmode@gnu.org Nicolas Goaziou writes: > Hello, > > Eric Schulte writes: > >> Thanks for taking the time to collect these changes into a patch, >> however I believe the changes you describe present /new/ behavior (e.g., >> new export semantics for drawers), rather than a bug repair. > > I'd rather say that its intent is to fix an old bug: incomplete > specifications of drawers. Also, I don't add export semantics for > drawers: I remove any, by default. > I apologize if I come across as argumentative, but I disagree with the statement above. The tag-line to the "Drawers" section in the manual is "Tucking stuff away" which I think is often how drawers are used. Changing the default drawer export behavior from "don't export" to "do export" would be surprising, would break many existing work flows, and would likely make drawers less useful. In general I think the Org-mode specification is best defined by how Org-mode is used and how it may be more easily and intuitively used in the future. Org-mode doesn't currently have a formal specification, and I think that is a good thing. Formal specification don't prevent bugs, they just move them from the code to the spec. Incidentally this is also why I consider the loss of result folding to be a regression because it breaks existing usage patterns. > > Again, drawers allow to fold any part of an Org buffer without adding > semantics to its contents. It's a more general solution than > keywords. But you already know that. > >> For the time being I am going to bring back results folding until an >> acceptable alternative can be agreed upon and implemented. > > There is already an acceptable alternative. I sincerely hope that > reverting this won't make it impossible to be implemented later. > There is no rule against reverting a revision :), so we could always do that if there is a consensus on list. To my mind a better path moving forward would be to change the behavior of the :RESULTS: drawer so that it is exported but *not* to change the default drawer export behavior. This way with a :wrap header argument the code block results could be hidden with tab but would still be exported. PRO: allows hiding code block results with tab, makes it clear where results begin and end, uses drawers for hiding which is what they are designed for, avoids the potential for hiding anything with a name CON: more syntactic weight around results, changes the existing default behavior, makes the "RESULTS" drawer a special type of drawer There is likely a better option but this is the best that comes to mind. Personally I am also content with the current behavior in which anything under a #+name: may be hidden. Cheers, > > > Regards, -- Eric Schulte http://cs.unm.edu/~eschulte/