* Feature Request: allow export yes/no for blocks that are valid babel inputs
@ 2019-03-23 21:20 Carlos Pita
2019-03-23 21:30 ` Carlos Pita
2019-03-24 16:30 ` Berry, Charles
0 siblings, 2 replies; 7+ messages in thread
From: Carlos Pita @ 2019-03-23 21:20 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature Request: allow export yes/no for blocks that are valid babel inputs
2019-03-23 21:20 Feature Request: allow export yes/no for blocks that are valid babel inputs Carlos Pita
@ 2019-03-23 21:30 ` Carlos Pita
2019-03-23 21:35 ` Carlos Pita
2019-03-24 16:30 ` Berry, Charles
1 sibling, 1 reply; 7+ messages in thread
From: Carlos Pita @ 2019-03-23 21:30 UTC (permalink / raw)
To: emacs-orgmode
Or maybe a keyword, similar to #+name. For instance:
#+export: no
#+name: mylist
- item 1
- item 2
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature Request: allow export yes/no for blocks that are valid babel inputs
2019-03-23 21:30 ` Carlos Pita
@ 2019-03-23 21:35 ` Carlos Pita
0 siblings, 0 replies; 7+ messages in thread
From: Carlos Pita @ 2019-03-23 21:35 UTC (permalink / raw)
To: emacs-orgmode
Or maybe the other way around:
#+noexport: mylist mytable ...
Then there is the question of what to do with src blocks, which have
their own, more complex, export control mechanism. What if both
#+noexport and :exports were set with non consistent values? Should
one forbid that possibility? Or simply make :exports win?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature Request: allow export yes/no for blocks that are valid babel inputs
2019-03-23 21:20 Feature Request: allow export yes/no for blocks that are valid babel inputs Carlos Pita
2019-03-23 21:30 ` Carlos Pita
@ 2019-03-24 16:30 ` Berry, Charles
2019-04-16 21:13 ` Carlos Pita
1 sibling, 1 reply; 7+ messages in thread
From: Berry, Charles @ 2019-03-24 16:30 UTC (permalink / raw)
To: Carlos Pita; +Cc: emacs-orgmode
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 <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
> 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
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature Request: allow export yes/no for blocks that are valid babel inputs
2019-03-24 16:30 ` Berry, Charles
@ 2019-04-16 21:13 ` Carlos Pita
2019-04-17 5:42 ` Fraga, Eric
0 siblings, 1 reply; 7+ messages in thread
From: Carlos Pita @ 2019-04-16 21:13 UTC (permalink / raw)
To: Berry, Charles; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 2437 bytes --]
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 <ccberry@ucsd.edu> 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 <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
> > 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
> >
> >
>
>
>
[-- Attachment #2: Type: text/html, Size: 3203 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature Request: allow export yes/no for blocks that are valid babel inputs
2019-04-16 21:13 ` Carlos Pita
@ 2019-04-17 5:42 ` Fraga, Eric
2019-04-17 16:16 ` Berry, Charles
0 siblings, 1 reply; 7+ messages in thread
From: Fraga, Eric @ 2019-04-17 5:42 UTC (permalink / raw)
To: Carlos Pita; +Cc: emacs-orgmode, Berry, Charles
I missed your original query. Have you considered using drawers? I use
these instead of inline tasks for "inputs" of the type you
describe. You can control their export using the d: option.
--
Eric S Fraga via Emacs 27.0.50, Org release_9.2.3-327-g3375f0
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Feature Request: allow export yes/no for blocks that are valid babel inputs
2019-04-17 5:42 ` Fraga, Eric
@ 2019-04-17 16:16 ` Berry, Charles
0 siblings, 0 replies; 7+ messages in thread
From: Berry, Charles @ 2019-04-17 16:16 UTC (permalink / raw)
To: Fraga, Eric; +Cc: Carlos Pita, emacs-orgmode
You are right, Eric.
This is a better option - especially as `org-export-with-drawers' gives granular control over what is exported.
Chuck
> On Apr 16, 2019, at 10:42 PM, Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
>
> I missed your original query. Have you considered using drawers? I use
> these instead of inline tasks for "inputs" of the type you
> describe. You can control their export using the d: option.
>
> --
> Eric S Fraga via Emacs 27.0.50, Org release_9.2.3-327-g3375f0
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-04-17 16:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-23 21:20 Feature Request: allow export yes/no for blocks that are valid babel inputs Carlos Pita
2019-03-23 21:30 ` Carlos Pita
2019-03-23 21:35 ` Carlos Pita
2019-03-24 16:30 ` Berry, Charles
2019-04-16 21:13 ` Carlos Pita
2019-04-17 5:42 ` Fraga, Eric
2019-04-17 16:16 ` Berry, Charles
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).