From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [BUG] Inconsistency in src block hiding Date: Sat, 28 Jan 2012 17:08:00 +0100 Message-ID: <871uqjresf.fsf@gmail.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> <87k44hn4uz.fsf@gmx.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([140.186.70.92]:41644) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrAqv-000408-T7 for emacs-orgmode@gnu.org; Sat, 28 Jan 2012 11:10:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RrAqt-0000KS-Sn for emacs-orgmode@gnu.org; Sat, 28 Jan 2012 11:10:09 -0500 Received: from mail-wi0-f169.google.com ([209.85.212.169]:33350) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RrAqt-0000Jk-Ih for emacs-orgmode@gnu.org; Sat, 28 Jan 2012 11:10:07 -0500 Received: by wibhj13 with SMTP id hj13so2767106wib.0 for ; Sat, 28 Jan 2012 08:10:06 -0800 (PST) In-Reply-To: <87k44hn4uz.fsf@gmx.com> (Eric Schulte's message of "Mon, 23 Jan 2012 20:41:48 -0700") 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: Eric Schulte Cc: Rick Frankel , emacs-orgmode@gnu.org Hello, Eric Schulte writes: > 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 While implementing a recent patch about drawers insertion, I realized my current view about drawers had a flaw. Indeed, while I had correctly put aside properties drawers, which are very different from regular drawers, I had overlooked special drawers like LOGBOOK and CLOCK. Those drawers are different from regular drawers, since they are attached to an headline (this is not the case of a RESULTS drawer), and as such should be classified in another category. Therefore, I suggest the following fixed behaviour with regards to export for drawers: - Properties drawers :: Still ignored in export, independently on "d" option or `org-export-with-drawers' value. Obviously, back-end can ignore this specification, but it should be followed by major ones. - Special drawers :: Not exported by default. Though, their export can be configured with a new "sd" option item (i.e. "sd:t") or `org-export-with-special-drawers' variable. This category only includes LOGBOOK[1] and CLOCK drawers at the moment. If their export is activated, the special `org-backend-format-drawer-function' (i.e. `org-e-latex-format-drawer-function') can allow to tweak their output. - Regular drawers :: Exported by default. "d:nil" turns that off. This category includes RESULTS drawers and every user created drawer. `org-backend-format-drawer-function' still can help tweaking their output. Thus, it can be used to filter out some types of drawers. With that model, drawers will be able to fill a niche by allowing to hide data in an Org buffer while still wanting to export it. As a reminder, currently with "d:nil", drawers are redundant with #+begin_comment blocks, and with "d:t" they are redundant with #+begin_example blocks. "d:'(some names)" is just a mix of comment and example blocks. Note that it has the same advantages as your suggestion. What do you think? Regards, [1] Or whatever the user specified in `org-log-into-drawer'. -- Nicolas Goaziou