Org-mode mailing list
 help / color / mirror / Atom feed
* #+include from same file when exporting
@ 2020-09-16  1:14 edgar
  2020-10-13 19:51 ` Nicolas Goaziou
  0 siblings, 1 reply; 2+ messages in thread
From: edgar @ 2020-09-16  1:14 UTC (permalink / raw)
  To: emacs-orgmode

Hello, dear list!

My comment for today is that I have something like this:

this-file.org
..............................
* Fancy header 1

#+NAME: blk1
#+begin_src python
   import numpy as np
#+end_src

** Fancy subheader 2

Res 1
#+include: "this-file.org::blk1"

Res 2
#+include: "this-file.org::blk1" src python

Res 3
#+include: "./this-file.org::blk1" src python
.............................. end

When I export /Fancy subheader 2/ as text, I get

this-file.txt
..............................
			  ━━━━━━━━━━━━━━━━━━━
			   FANCY SUBHEADER 2
			  ━━━━━━━━━━━━━━━━━━━


Table of Contents
─────────────────




Res 1
┌────
│ import numpy as np
└────

Res 2
┌────
│ * Fancy header 1
│
│ #+NAME: blk1
│ #+begin_src python
│   import numpy as np
│ #+end_src
│
│ ** Fancy subheader 2
│
│ Res 1
│ #+include: "this-file.org::blk1"
│
│ Res 2
│ #+include: "this-file.org::blk1" src python
│
│ Res 3
│ #+include: "./this-file.org::blk1" src python
└────

Res 3
┌────
│ * Fancy header 1
│
│ #+NAME: blk1
│ #+begin_src python
│   import numpy as np
│ #+end_src
│
│ ** Fancy subheader 2
│
│ Res 1
│ #+include: "this-file.org::blk1"
│
│ Res 2
│ #+include: "this-file.org::blk1" src python
│
│ Res 3
│ #+include: "./this-file.org::blk1" src python
└────
.............................. end

I think that all of them should just export the python block, right?

Also, I think that it would be very useful to have something like this:

another-file.org
..............................
* Fancy header 1

#+NAME: blk1
#+begin_src python :exports none
   print(2)
#+end_src

#+RESULTS:
: 2

** Fancy subheader 2

Res 1
#+include: "this-file.org::blk1" src python :exports both
.............................. end

Which would allow to have the =#+include= override the =:exports= 
directive from the original block and get the results from the block. 
Right now, I can do

yaf.org
..............................
* Fancy header 1

#+NAME: blk1
#+begin_src python
   print(2)
#+end_src

** Fancy subheader 2

Res 1
#+begin_src python :noweb yes :exports both
   <<blk1>>
#+end_src

#+RESULTS:
: 2
.............................. end

to get the same result, but I thought that this could be a nice feature 
to add.


GNU Emacs 27.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.21, 
cairo version 1.17.3) of 2020-09-08

Org mode version 9.3.7 (release_9.3.7-25-g4f22fd @ 
/home/edgar/.emacs.d/org-mode/lisp/)

-------------------------------------------------
This free account was provided by VFEmail.net - report spam to abuse@vfemail.net
 
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: #+include from same file when exporting
  2020-09-16  1:14 #+include from same file when exporting edgar
@ 2020-10-13 19:51 ` Nicolas Goaziou
  0 siblings, 0 replies; 2+ messages in thread
From: Nicolas Goaziou @ 2020-10-13 19:51 UTC (permalink / raw)
  To: edgar; +Cc: emacs-orgmode

Hello,

edgar@openmail.cc writes:

> My comment for today is that I have something like this:
>
> this-file.org
> ..............................
> * Fancy header 1
>
> #+NAME: blk1
> #+begin_src python
>
>    import numpy as np #+end_src
>
> ** Fancy subheader 2
>
> Res 1
>
> #+include: "this-file.org::blk1"
>
> Res 2
>
> #+include: "this-file.org::blk1" src python
>
> Res 3
>
> #+include: "./this-file.org::blk1" src python
> .............................. end

[...]

> I think that all of them should just export the python block, right?

I don't think so.

  #+include: file src python

means that file is really a python file, whose contents are going to be
enclosed in a Python source code block. So Res 2 and Res 3 are not
meaningful in that case; you cannot apply link search syntax to non-Org
files.

> Also, I think that it would be very useful to have something like this:
>
> another-file.org
> ..............................
> * Fancy header 1
>
> #+NAME: blk1
> #+begin_src python :exports none
>
>    print(2) #+end_src
>
> #+RESULTS: : 2
>
> ** Fancy subheader 2
>
> Res 1
>
> #+include: "this-file.org::blk1" src python :exports both
> .............................. end
>
>
> Which would allow to have the =#+include= override the =:exports= 
> directive from the original block and get the results from the block. 

"Include" is an export-only directive, which is not the case
of :exports. They live in two different worlds, and I think it is a good
thing to keep them orthogonal.

You may be looking after Babel calls.

Regards,
-- 
Nicolas Goaziou


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-10-13 19:53 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-16  1:14 #+include from same file when exporting edgar
2020-10-13 19:51 ` Nicolas Goaziou

Org-mode mailing list

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://orgmode.org/list/0 list/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 list list/ https://orgmode.org/list \
		emacs-orgmode@gnu.org
	public-inbox-index list

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.yhetil.org/yhetil.emacs.orgmode
	nntp://news.gmane.io/gmane.emacs.orgmode


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git