From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carlos Pita Subject: Re: Feature Request: allow export yes/no for blocks that are valid babel inputs Date: Tue, 16 Apr 2019 18:13:49 -0300 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000078dcb00586ac3f22" Return-path: Received: from eggs.gnu.org ([209.51.188.92]:59678) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGVP1-0000MK-Rp for emacs-orgmode@gnu.org; Tue, 16 Apr 2019 17:14:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hGVP0-0006PK-MJ for emacs-orgmode@gnu.org; Tue, 16 Apr 2019 17:14:03 -0400 Received: from mail-yw1-xc2d.google.com ([2607:f8b0:4864:20::c2d]:34762) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hGVP0-0006Mj-96 for emacs-orgmode@gnu.org; Tue, 16 Apr 2019 17:14:02 -0400 Received: by mail-yw1-xc2d.google.com with SMTP id x129so7866454ywc.1 for ; Tue, 16 Apr 2019 14:14:01 -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" To: "Berry, Charles" Cc: emacs-orgmode --00000000000078dcb00586ac3f22 Content-Type: text/plain; charset="UTF-8" Hi Berry, sorry for the late reply, I was pretty busy lately. I didn't know about inline tasks, thanks for let me know. The idea is cool but I think that regarding the use case I'm suggesting, they are a more or less hackish workaround and not a proper solution. I'm saying this because: 1) They are kinda optional, they are not enabled by default. But this is not too important. 2) They are oriented towards tasks. Clearly, my use case is not about tasks but about more granularity in exporting. It's true that, as a side effect, you can wrap some additional syntactical constructions into selectively exportable chunks by considering them as tasks. Now, the concept of inline task could be generalized and, if the generalization is "general enough", maybe even enabled by default. But this is overkilling for my specific interest, specially if I had to implements something like that by myself. Instead, I could implement a more modest proposal (no Swift reference intended). Regards -- Carlos On Sun, Mar 24, 2019 at 1:31 PM Berry, Charles wrote: > AFAICS, the functionality you seek already exists, although it is not > heavily advertised. > > `C-c C-x t' will insert an inline task. Within such a `task' you can put > text, tables, src blocks and other objects. > > Setting option `inline:nil' will prevent export, but leave the content > visible to src blocks etc. > > Alternatively, you can tag inlinetasks as with headlines to control their > export. > > Browse the commentary in org-inlinetask.el for more details. > > HTH, > > Chuck > > > > On Mar 23, 2019, at 2:20 PM, Carlos Pita > wrote: > > > > Hi all, > > > > when using lists, tables and example blocks as inputs to babel src > > blocks sometimes the inputs are just... inputs. There is some > > inconsistency in the fact that src blocks can be selectively exported > > but not their inputs. Commenting these inputs out makes them invisible > > to the block referencing them (apparently this method worked a time > > ago but it's not working now). OTOH using the noexport tag introduces > > spurious sections that interrupt the flow of the document and might be > > hard to close afterwards (similar to the boilerplate introduced by > > beamer blocks). > > > > What do you think of adding an :export yes/no parameter to these > > blocks? Or to blocks in general. > > > > Best regards > > -- > > Carlos > > > > > > > --00000000000078dcb00586ac3f22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Berry,

sorry for the late= reply, I was pretty busy lately.

I didn't kno= w about inline tasks, thanks for let me know. The idea is cool but I think = that regarding the use case I'm suggesting, they are a more or less hac= kish workaround and not a proper solution. I'm saying this because:

1) They are kinda optional, they are not enabled by d= efault. But this is not too important.

2) They are= oriented towards tasks. Clearly, my use case is not about tasks but about = more granularity in exporting. It's true that, as a side effect, you ca= n wrap some additional syntactical constructions into selectively exportabl= e chunks by considering them as tasks.

Now, the co= ncept of inline task could be generalized and, if the generalization is &qu= ot;general enough", maybe even enabled by default. But this is overkil= ling for my specific interest, specially if I had to implements something l= ike that by myself. Instead, I could implement a more modest proposal (no S= wift reference intended).

Regards
--
Carlos


=
On Sun, Mar 24, 2019 at 1:31 PM Berry= , Charles <ccberry@ucsd.edu> = wrote:
AFAICS, t= he functionality you seek already exists, although it is not heavily advert= ised.

`C-c C-x t' will insert an inline task. Within such a `task' you ca= n put text, tables, src blocks and other objects.

Setting option `inline:nil' will prevent export, but leave the content = visible to src blocks etc.

Alternatively, you can tag inlinetasks as with headlines to control their e= xport.

Browse the commentary in org-inlinetask.el for more details.

HTH,

Chuck


> On Mar 23, 2019, at 2:20 PM, Carlos Pita <carlosjosepita@gmail.com> wrote= :
>
> Hi all,
>
> when using lists, tables and example blocks as inputs to babel src
> blocks sometimes the inputs are just... inputs. There is some
> inconsistency in the fact that src blocks can be selectively exported<= br> > but not their inputs. Commenting these inputs out makes them invisible=
> to the block referencing them (apparently this method worked a time > ago but it's not working now). OTOH using the noexport tag introdu= ces
> spurious sections that interrupt the flow of the document and might be=
> hard to close afterwards (similar to the boilerplate introduced by
> beamer blocks).
>
> What do you think of adding an :export yes/no parameter to these
> blocks? Or to blocks in general.
>
> Best regards
> --
> Carlos
>
>


--00000000000078dcb00586ac3f22--