[O] What Happened to org-export-html-extension?
I am trying to publish a project where the files have a custom extension using the new exporter: (org-ianbarton :base-directory ~/Documents/emacs/web_sites/ianbarton/org/_posts :base-extension org :publishing-directory ~/Documents/emacs/web_sites/ianbarton/pelican/blog/content :recursive t :publishing-function org-html-publish-to-html :headline-levels 4 ; Just the default for this project. :auto-preamble t :auto-index f :html-extension yml :auto-preamble t :body-only t ) However, all files are published with an .html extension. My Emacs customize interface claims that org-export-html-extension doesn't exist. Grepping the source for org-export-html-extension doesn't find anything. So has the variable been renamed to something else? Ian.
Re: [O] What Happened to org-export-html-extension?
Hello Ian, On Sun, Mar 31, 2013 at 10:43:21AM +0100, Ian Barton wrote: However, all files are published with an .html extension. My Emacs customize interface claims that org-export-html-extension doesn't exist. Grepping the source for org-export-html-extension doesn't find anything. So has the variable been renamed to something else? All variables and functions called org-export or org-e- have been renamed to org-backend-oldname. So org-export-html-extension is now, org-html-extension. Hope this helps, -- Suvayu Open source is the future. It sets us free.
Re: [O] [PATCH] Process hlines in imported tables
On Sat, Mar 30, 2013 at 06:43:30PM -0600, Eric Schulte wrote: Rick Frankel r...@rickster.com writes: *Note* =wrap= and =raw= give same results #+begin_src perl :results raw q[|c1|c2| |- |a|1| |b|2|]; #+end_src #+results: | | c1 | c2 | | | - || | | a | 1 | | | b | 2 | This is a problem in the results returned by ob-perl, not in the results insertion mechanism. Given what is actually being returned by that code block the results make sense. #+name: perl-example #+begin_src perl :results raw q[|c1|c2| |- |a|1| |b|2|]; #+end_src If we add verbatim (which inhibits interpretation as a value, which can often result in a list or table result), then we get what I assume you expect. #+name: perl-example #+begin_src perl :results verbatim raw q[|c1|c2| |- |a|1| |b|2|]; #+end_src #+RESULTS: perl-example | c1 | c2 | |+| | a | 1 | | b | 2 | Missed verbatim. Thanks for the pointer, it works, but i think that perl is double-processing returned values. If we do the same things in elisp i get (my) expected results: #+begin_src elisp :results raw |c1|c2| |- |a|1| |b|2|; #+end_src #+results: | c1 | c2 | |+| | a | 1 | | b | 2 | *NOTE* this will not properly clean-up the results, but keep inserting more copies. #+begin_src elisp :results raw verbatim |c1|c2| |- |a|1| |b|2|; #+end_src #+results: |c1|c2| |- |a|1| |b|2| #+begin_src perl :results raw output print q[|c1|c2| |- |a|1| |b|2| ]; Yes, this was included to show the inconsistency between value and output returns. BTW, raw output and raw output verbatim generate the same results. Footnotes: [1] http://orgmode.org/worg/org-contrib/babel/header-args.html I will take a look and see if i come up with anything else. In general, what I have found with babel processing is that there is major inconsistency between the results processing in different languages. Somehow, I would think that the same output (modulo sytnactic diferences) should generate the same results regardless of language. rick
[O] [Feature request] Could Org-mode set 'outline-promotion-headings'?
Hi List, 'outline-promotion-headings' is a variable defined in Carsten Dominik's 'outline-magic.el' library (and is thus part of my 'outshine.el' which merges 'outline-magic'). When I wrote 'navi-mode.el' (see https://github.com/tj64/navi and http://orgmode.org/worg/org-tutorials/index.html) I tried to make it dependent mostly on this variable, so I guess I could make navi-mode work with Org-mode files too (not only with buffers where outline-minor-mode is acitvated with outshine extensions) if Org-mode would set this variable: , | outline-promotion-headings is a variable defined in `outshine.el'. | Its value is shown below. | | Automatically becomes buffer-local when set. | | Documentation: | A sorted list of headings used for promotion/demotion commands. | Set this to a list of headings as they are matched by `outline-regexp', | top-level heading first. If a mode or document needs several sets of | outline headings (for example numbered and unnumbered sections), list | them set by set, separated by a nil element. See the example for | `texinfo-mode' in the file commentary. | | For more information check the manuals. | | | | Value: | ((;; * . 1) | (;; ** . 2) | (;; *** . 3) | (;; . 4) | (;; * . 5) | (;; ** . 6) | (;; *** . 7) | (;; . 8)) | | Local in buffer `xyz.el'; global value is nil ` I case of Org-mode, there would of course be no ';;' in the values, i.e. just ,--- | (* . 1) `--- instead of ,-- | (;; * . 1) `-- -- cheers, Thorsten
Re: [O] [PATCH] Process hlines in imported tables
Rick Frankel r...@rickster.com writes: On Sat, Mar 30, 2013 at 06:43:30PM -0600, Eric Schulte wrote: Rick Frankel r...@rickster.com writes: *Note* =wrap= and =raw= give same results #+begin_src perl :results raw q[|c1|c2| |- |a|1| |b|2|]; #+end_src #+results: | | c1 | c2 | | | - || | | a | 1 | | | b | 2 | This is a problem in the results returned by ob-perl, not in the results insertion mechanism. Given what is actually being returned by that code block the results make sense. #+name: perl-example #+begin_src perl :results raw q[|c1|c2| |- |a|1| |b|2|]; #+end_src If we add verbatim (which inhibits interpretation as a value, which can often result in a list or table result), then we get what I assume you expect. #+name: perl-example #+begin_src perl :results verbatim raw q[|c1|c2| |- |a|1| |b|2|]; #+end_src #+RESULTS: perl-example | c1 | c2 | |+| | a | 1 | | b | 2 | Missed verbatim. Thanks for the pointer, it works, but i think that perl is double-processing returned values. If we do the same things in elisp i get (my) expected results: Yes, because Emacs Lisp is the language of Emacs, it's results aren't interpreted as are the results of every other language. This was an intentional design decision, and it gives extra flexibility when working with Emacs Lisp. #+begin_src elisp :results raw |c1|c2| |- |a|1| |b|2|; #+end_src #+results: | c1 | c2 | |+| | a | 1 | | b | 2 | *NOTE* this will not properly clean-up the results, but keep inserting more copies. Yes, this is why :results drawer exists. #+begin_src elisp :results raw verbatim |c1|c2| |- |a|1| |b|2|; #+end_src #+results: |c1|c2| |- |a|1| |b|2| #+begin_src perl :results raw output print q[|c1|c2| |- |a|1| |b|2| ]; Yes, this was included to show the inconsistency between value and output returns. BTW, raw output and raw output verbatim generate the same results. Yes, output collects the code block result from STDOUT. The strings collected from STDOUT are not treated as values, but rather as raw strings. This should be true across every language. Footnotes: [1] http://orgmode.org/worg/org-contrib/babel/header-args.html I will take a look and see if i come up with anything else. Please do, I think this page could become a great resource. In general, what I have found with babel processing is that there is major inconsistency between the results processing in different languages. It is certainly true that Emacs Lisp is treated differently than all other languages. There are also significant differences between languages, e.g., session evaluation doesn't make sense for some languages, and for other languages session evaluation is the only type of evaluation that does make sense. In addition to that, with over 40 supported languages [1], There undoubtedly are cases where we are doing a bad job of ensuring inter-languages consistency. If you can find concise examples which use demonstrate significant inconsistencies between languages, then we should be able to resolve those on a case by case basis. In general I think ob-sh is probably the most widely used code block language, and can be treated as the gold standard against which other languages should be compared. Somehow, I would think that the same output (modulo sytnactic diferences) should generate the same results regardless of language. I agree, modulo what I said about emacs-lisp. Please submit specific reproducible examples and we can get to work fixing them. Thanks, rick Footnotes: [1] Specifically, from the current master branch. ob-asymptote.el ob-awk.el ob-calc.el ob-C.el ob-clojure.el ob-css.el ob-ditaa.el ob-dot.el ob-emacs-lisp.el ob-fortran.el ob-gnuplot.el ob-haskell.el ob-io.el ob-java.el ob-js.el ob-keys.el ob-latex.el ob-ledger.el ob-lilypond.el ob-lisp.el ob-makefile.el ob-matlab.el ob-maxima.el ob-mscgen.el ob-ocaml.el ob-octave.el ob-org.el ob-perl.el ob-picolisp.el ob-plantuml.el ob-python.el ob-R.el ob-ruby.el ob-sass.el ob-scala.el ob-scheme.el ob-screen.el ob-sh.el ob-shen.el ob-sql.el ob-sqlite.el ob-tangle.el -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] What Happened to org-export-html-extension?
On 31/03/13 11:01, Suvayu Ali wrote: Hello Ian, On Sun, Mar 31, 2013 at 10:43:21AM +0100, Ian Barton wrote: However, all files are published with an .html extension. My Emacs customize interface claims that org-export-html-extension doesn't exist. Grepping the source for org-export-html-extension doesn't find anything. So has the variable been renamed to something else? All variables and functions called org-export or org-e- have been renamed to org-backend-oldname. So org-export-html-extension is now, org-html-extension. Hope this helps, Thanks, it does and it doesn't. I have set the variable, but still get files with a .html extension. I can reproduce the problem with the following minimal emacs: (add-to-list 'load-path ~/.emacs.d/src/lisp) (require 'org) (require 'ox-html) (setq org-publish-project-alist '( ;; ... add all the components here (see below)... (org-ianbarton :base-directory ~/Documents/emacs/web_sites/ianbarton/org/_posts :base-extension org :publishing-directory ~/Documents/emacs/web_sites/ianbarton/pelican/blog/content :recursive t :publishing-function org-html-publish-to-html :headline-levels 4 ; Just the default for this project. :auto-preamble t :auto-index f :org-html-extension yml :auto-preamble t :body-only t ) (org-static-ian :base-directory ~/Documents/emacs/web_sites/ianbarton/org/_posts :base-extension css\\|js\\|png\\|jpg\\|gif\\|pdf\\|mp3\\|ogg\\|swf\\|php :publishing-directory ~/Documents/emacs/web_sites/ianbarton/pelican/blog/content :recursive t :publishing-function org-ox-publish-attachment) (ianbarton :components (org-ianbarton org-static-ian)) ))
Re: [O] Creating Gantt charts by Exporting to TaskJuggler 3.3.0
Hi Guys, long time ago, but I tried again to go into taskjuggling with org-mode. I still feel the lack of the support for all tj properties a major drawback. @Christian: Did you work on something like the prefix proposal below? This would be real cool as we could then just use any property we would like. Thanks and best regards, Matt Am 14.09.2012 18:06, schrieb Buddy Butterfly: Hi Yann, thanks a lot for your effort. This really sound very interesting. And I am willed to report further issues to you. I will try to nail them down more precisely. The biggest change I would do is to make the properties more generic. Something like prefixing all properties with a special prefix (configurable) like tj_ and just pass them all over to tj. This would allow the user to use all properties that are, were and will be available for tj versions and not having the exporter document we support this and that property in this and that version of tj Best regards, Matt Am 14.09.2012 17:55, schrieb Yann Hodique: Buddy == Buddy Butterfly buddy.butter...@web.de writes: Am 14.09.2012 17:09, schrieb: Hi, Seb, almost one month ago Yann Hodique proposed 10 patches for the taskjuggler exporter, please see: http://article.gmane.org/gmane.emacs.orgmode/58851 Bastien has a branch with these patches, but he'll apply them when he will have received the FSF papers signed. I hope soon :-) But I'm pretty sure you can apply them to your file. cheers, Giovanni Hi Giovanni, thanks for info. I will give this a try when I'll find the time. At the moment, because of the scrambled handling of task_ids it is not really usable. Let's see what he fixed in it. Hi, actually, those patches have been merged in master already (now that the paperwork is in order :)) That said, I don't think it'll fix anything regarding task_id handling. I started using TJ with versions 3.x, so I'm not sure what problem you're talking about exactly. At the moment I'm kinda contemplating doing a major rewrite of the TJ exporter to use the org-export framework, which would make it easier to introduce things like task references through org links, and so on. If I can fix a thing or two in the process, I'd be happy to. So, if you have specific limitations in mind, feel free to elaborate. Cheers, Yann.
Re: [O] [Feature request] Could Org-mode set 'outline-promotion-headings'?
On Sun, Mar 31, 2013 at 9:01 AM, Thorsten Jolitz tjol...@gmail.com wrote: 'outline-promotion-headings' is a variable defined in Carsten Dominik's 'outline-magic.el' library (and is thus part of my 'outshine.el' which merges 'outline-magic'). When I wrote 'navi-mode.el' (see https://github.com/tj64/navi and http://orgmode.org/worg/org-tutorials/index.html) I tried to make it dependent mostly on this variable, so I guess I could make navi-mode work with Org-mode files too (not only with buffers where outline-minor-mode is acitvated with outshine extensions) if Org-mode would set this variable: Can't you set it in a hook? I'd guess org-mode-hook would be about right. Nick
Re: [O] What Happened to org-export-html-extension?
Hi, org-html-publish-to-html is defined in ox-html.el and looks like this (sans doc): (defun org-html-publish-to-html (plist filename pub-dir) (org-publish-org-to 'html filename .html plist pub-dir)) You could define your own publishing function, e.g. (defun my-org-html-publish-to-html (plist filename pub-dir) (org-publish-org-to 'html filename .yml plist pub-dir)) and refer to that in your org-publish-project-alist. org-html-extension is used in org-html-export-to-html which calls org-export-to-file, which is the same function org-publish-org-to calls (so org-html-extension is bypassed). There's also the export option :html-extension but it doesn't look like it's used to name published files. Regards, Sean
Re: [O] [Feature request] Could Org-mode set 'outline-promotion-headings'?
Nick Dokos ndo...@gmail.com writes: On Sun, Mar 31, 2013 at 9:01 AM, Thorsten Jolitz tjol...@gmail.com wrote: 'outline-promotion-headings' is a variable defined in Carsten Dominik's 'outline-magic.el' library (and is thus part of my 'outshine.el' which merges 'outline-magic'). When I wrote 'navi-mode.el' (see https://github.com/tj64/navi and http://orgmode.org/worg/org-tutorials/index.html) I tried to make it dependent mostly on this variable, so I guess I could make navi-mode work with Org-mode files too (not only with buffers where outline-minor-mode is acitvated with outshine extensions) if Org-mode would set this variable: Can't you set it in a hook? I'd guess org-mode-hook would be about right. yes, I can do that in navi-mode itself, thanks for the tip. -- cheers, Thorsten
[O] Local footnotes - inline
G'day, Some time back there was mention of converting Local footnoted (defined at end of outline node) to inline footnotes and vice-versa. Is there a way to do this? Or has anyone defined private functions to do it? Local footnotes are easier to read, but inline notes a easier to cut and paste. Thanks for any help, Alan -- Alan L Tyree http://www2.austlii.edu.au/~alan Tel: 04 2748 6206 sip:172...@iptel.org
Re: [O] tests with travis-ci
On Fri, Mar 22, 2013 at 10:40 AM, Yagnesh Raghava Yakkala h...@yagnesh.org wrote: On Mar 22 2013, Yann Hodique yann.hodi...@gmail.com wrote: If so, it might be worth waiting for me to fix it (I'm afraid it's not there simply because I didn't need it :)). It would be sad to limit yourself just because of that. Assuming ert-x.el can be backported easily, I'll try and work on it in the coming days. That would be useful. It should now be ok, with virtualenv-emacs 0.1.5 (that grabs an ert-x.el from marmalade). Cheers, Yann.
Re: [O] What Happened to org-export-html-extension?
org-html-publish-to-html is defined in ox-html.el and looks like this (sans doc): (defun org-html-publish-to-html (plist filename pub-dir) (org-publish-org-to 'html filename .html plist pub-dir)) You could define your own publishing function, e.g. (defun my-org-html-publish-to-html (plist filename pub-dir) (org-publish-org-to 'html filename .yml plist pub-dir)) and refer to that in your org-publish-project-alist. org-html-extension is used in org-html-export-to-html which calls org-export-to-file, which is the same function org-publish-org-to calls (so org-html-extension is bypassed). There's also the export option :html-extension but it doesn't look like it's used to name published files. Thanks for the clear explanation. Using my own function works, but this does seem to be a regression. Defining your own extension is useful e.g. if you want to emit .php files. Ian.
[O] Outdated comment in ox.el
Hi Nicolas and others, I think I found an outdated statement on backend variable names in the commentary section in ox.el. I have attached a patch correcting it. Needless to say, ignore this if I'm mistaken. Cheers, -- Suvayu Open source is the future. It sets us free. From ef8a9c484f21f8a432c418b550e3b8a9f7cb95cc Mon Sep 17 00:00:00 2001 From: Suvayu Ali fatkasuvayu+li...@gmail.com Date: Sun, 31 Mar 2013 21:33:48 +0200 Subject: [PATCH] Fix commentary in ox.el --- lisp/ox.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/ox.el b/lisp/ox.el index ff6407b..fc526f0 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -62,7 +62,7 @@ ;; process. ;; ;; Any back-end can define its own variables. Among them, those -;; customizable should belong to the `org-export-BACKEND' group. +;; customizable should belong to the `org-BACKEND' group. ;; ;; Tools for common tasks across back-ends are implemented in the ;; following part of then file. -- 1.8.1.4
Re: [O] Fwd: Fwd: run python from org, draft
On Fri, Mar 29, 2013 at 4:58 PM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: Am 29.03.2013 21:10, schrieb Gary Oberbrunner: On Fri, Mar 29, 2013 at 11:29 AM, Andreas Röhler andreas.roeh...@easy-emacs.de wrote: IMO org-babel should be able to run source code as is. If an org-mode specific modification is required at such a trivial form, what to expect wrt complex environments? BTW this fails also: #+begin_src python print Hello, world! #+end_src python #+RESULTS: : None As the worg doc says, if you want to capture stdout rather than a value, you need :results output. The default is :results value (which in session mode is the last expression executed, and in non-session mode is whatever you return().) I agree it is a little odd, but given how python works it's not clear to me how to improve it. Hi Gary, if someone wants the value of the last expression returned, it's much simpler to write Python/native language, than cryptic, lately documented org-mode flags. That's a kind of re-inventing a programming-language, also redundant. Specifically, in non-session mode, the python interpreter is run as a separate process and fed the input (with some stuff around it). There is no way for python to get the last value in non-interactive mode, No? Any program may output any of it's values. so instead ob-python wraps your code in a function, then calls it, and writes the return value of that function to the temp file. Conversely in session mode, each block is talking to the same interactive python interpreter, just what you get if you type 'python' at the shell. So using return() there doesn't make any sense, and wouldn't work. The use of return doesn't depend from interactive mode. It's related to a function. Seen from org-user, IMO any back-ends interactive mode or not is not of interest. :session mimics and/or probably uses it, but it would also possible to implement it as a file, loading previous values from a storage. I don't see any way to make them both behave the same way. Probably most useful at this list is to define which feature/behavior is most convenient. Why people use this mode, what they want to do. I think the very most useful thing would be for you to code up what you're thinking of, and show it here. -- Gary
Re: [O] Outdated comment in ox.el
Hello, Suvayu Ali fatkasuvayu+li...@gmail.com writes: I think I found an outdated statement on backend variable names in the commentary section in ox.el. I have attached a patch correcting it. Needless to say, ignore this if I'm mistaken. The statement is correct. The hierarchy is, for example: Org Org Export Org Export Html Regards, -- Nicolas Goaziou
Re: [O] RFC: inheritance of export attributes
Hi Nicolas, 2013ko martxoak 21an, Nicolas Goaziou-ek idatzi zuen: Aaron Ecay aarone...@gmail.com writes: I have noticed a difficulty with :results table drawer babel blocks. It isn’t possible to put ATTR_LATEX keywords on the table in that case. If they are placed outside of the drawer, they apply to the drawer and not the table. If they are placed inside it, they will be deleted when the block is reevaluated. What about evaluating it, inserting the attr_latex keyword, and then disabling evaluation for that block? This isn’t a solution, generally speaking. I may be working on a graph in R; I know that I want it to be inserted in the LaTeX output with width 6in, even as I go through several iterations of changing the graph. So, each time I do, either I have to manually re-enter the width, or be resigned to the LaTeX export being “broken” until I am done. (and the same goes for a table, of course) I understand the interest for the problem at hand, but, generally speaking, I tend to think it could lead to confusion. Attributes inheritance is but a hack used to parametrize inline images, until we agree on a proper link syntax including its own attributes. Well, this is one specific current use. But the fact that it is a hack doesn’t mean the inheritance approach is inherently hackish. Another way to solve the problem would be to let Babel generate attributes from source code with a specific keyword, e.g.: #+begin_src :results table :attr-latex :align lll ... #+end_src This would lead to long begin_src lines, especially if one wants to export to multiple backends. I think it is much more pleasant to be able to edit several lines: #+ATTR_LaTeX: foo #+ATTR_HTML: bar rather than packing them all into one begin_src line. (But I think I could live with this as a solution, if I had to.) What if attribute inheritance was only implemented for RESULTS drawers? I guess that would look more like a “hack,” but it would avoid interfering with other areas where attribute inheritance might cause confusion. Thanks, -- Aaron Ecay
Re: [O] Item task_id not being used in taskjuggler export
On Sun, Mar 31, 2013 at 7:04 PM, John Hendy jw.he...@gmail.com wrote:
I seem to be having trouble getting custom task_id values used for my
taskjuggler file. From ox-taskjuggler.el:
#+begin_quote
(defun org-taskjuggler--build-task (task info)
Return a task declaration.
TASK is a headline. INFO is a plist used as a communication
channel.
All valid attributes from TASK are inserted. If TASK defines
a property \task_id\ it will be used as the id for this task.
Otherwise it will use the ID property. If neither is defined
a unique id will be associated to it.
[snip]
#+end_quote
However, my headlines are still using the Org-assigned values for this...
#+begin_org
* Project :taskjuggler_project:
SCHEDULED: 2013-03-01 Fri
** Technical :T:
:PROPERTIES:
:task_id: T
:END:
*** Sub task
:PROPERTIES:
:task_id: T1
:END:
#+end_org
This gets exported as:
#+begin_tjp
task technical Technical {
purge allocate
allocate jwhendy
task sub Sub task {
milestone
}
}
#+end_tjp
Variations:
- I also tried using =:task_id: T= to see if it needed to be in quotes
- Tried changing my drawer name to TASK_ID to check for case-sensitivity
The results of both were the same. Is this something on my end or a
but in ox-taskjuggler.el?
Thanks,
John
As a followup, within a section, the :depends: attribute is being
correctly resolved, even though naming is incorrect. I've taken to
giving each area a single letter task_id, such as:
#+begin_org
* Project
** Technical
:PROPERTIES:
:TASK_ID: T
:END:
*** Sub task
:PROPERTIES:
:task_id: T1
:END:
*** Sub task2
*** Sub task
:PROPERTIES:
:task_id: T2
:depends: T1
:END:
#+end_org
That's resolving deps correctly, but not naming correctly:
#+begin_tjp
task sub Sub task {
milestone
}
task sub_task2 Sub task2 {
depends !sub
milestone
#+end_tjp
The problem with this is when depending on something outside of that
particular subtask; the TJ syntax is to use =!= as the equivalent to a
period with respect to directories. So to refer to a task in another
bucket, you need to do something like =:depends: !!M.M1= to refer to
the Milestone bucket (task_id = M), subtask M1 task.
This isn't working with Org taskjuggler export. Not being able to name
task is a huge inconvenience, as one has to use Org's unique-id naming
function, which I'd prefer not to do. It's easier (at least for me) to
just unfold all the property drawers and refer to things by their two
character id. I also tagged each top headline with it's letter bucket
:T: so that I can just count the item order in the list for it's
resulting subtask id (e.g. T2).
Best regards,
John
Re: [O] LaTeX export figure width, when figure comes from python?
[I can never get the reply-all thing down on this list! See below.]
On Sun, Mar 31, 2013 at 7:02 PM, John Hendy jw.he...@gmail.com wrote:
On Sun, Mar 31, 2013 at 11:03 AM, Gary Oberbrunner
ga...@oberbrunner.com wrote:
On Fri, Mar 29, 2013 at 4:53 PM, John Hendy jw.he...@gmail.com wrote:
On Fri, Mar 29, 2013 at 3:16 PM, Gary Oberbrunner
ga...@oberbrunner.com
wrote:
Now that python mode is working nicely, I'm generating lots of
graphics.
#+BEGIN_SRC python :session MYpython :exports results :results file
#... bunch of matplotlib stuff that produces /tmp/myfig.pdf
'/tmp/myfig.pdf'
#+END_SRC
This works, and the LaTeX exporter includes /tmp/mfig.pdf:
\includegraphics[width=.9\linewidth]{c:/tmp/myfig.pdf}
My question is, is there any way to remove the width specifier? If
the
figure were coming straight from org-mode source text, I could use
#+ATTR_LaTeX (well actually maybe not, because there's no way to
*remove*
the width, but at least I could set it as desired.) But in the
situation
above, where the filename is coming from the exporter running the code
block, there's no place for me to put the ATTR_LaTeX that works.
Any ideas, exporter gurus?
Does this post help at all?
- http://lists.gnu.org/archive/html/emacs-orgmode/2012-08/msg01225.html
This would be if your compilation of that block is spitting out a
#+results block. Is that the case?
Also, per a recent use of that same concept, I got updated advice to
use :wrap since the above wasn't working for me anymore:
- http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01599.html
So, basically if you're generating plots, you can just print the
Org-mode include file syntax ([[filename.ext]]) into a results block
and should also be able to pass it the #+attr_latex stuff as well.
Something like:
print(#+attr_latex: :width Xcm \n
[[filename.ext]])
That almost works. This does:
#+name: fields_chart(labels=fields[,0], vals=fields[,1])
#+BEGIN_SRC python :session UDpython :exports results :results raw
fname=do_hbar('/tmp/fields.pdf', (4,.9), vals, labels) # this creates
the
actual plot in /tmp/fields.pdf
#+ATTR_LaTeX: :width 4in \n[[%s]]%fname
#+END_SRC
Notes:
* You have to use :results raw rather than :results org. The latter
prepends a comma to the #+ATTR_LaTeX line, making it unusable. (Not sure
if
that's a bug, or expected.)
I wonder if that's similar to the question I asked as a followup to
the link I sent you to:
- https://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01583.html
* In session mode, you can't use :results output because the python
interpreter prompts also are output. But returning the string as above
works fine.
Did you try :wrap as well? I was having issues with :results org as
well and found out that the prior recommendation to use this was
updated to :wrap org instead...
I didn't try :wrap, but I did try :results wrap (which is what that post
suggested) which did nothing different as far as I could tell.
Out of curiosity... is the %s syntax related to python
(unfamiliar)... just noticed how you did that and wondered if that was
via Org/emacs/babel or via python.
That's python syntax.
Glad you found something that worked!
John
But now my graphics come out the right size! Thanks!
--
Gary
--
Gary
[O] Item task_id not being used in taskjuggler export
I seem to be having trouble getting custom task_id values used for my
taskjuggler file. From ox-taskjuggler.el:
#+begin_quote
(defun org-taskjuggler--build-task (task info)
Return a task declaration.
TASK is a headline. INFO is a plist used as a communication
channel.
All valid attributes from TASK are inserted. If TASK defines
a property \task_id\ it will be used as the id for this task.
Otherwise it will use the ID property. If neither is defined
a unique id will be associated to it.
[snip]
#+end_quote
However, my headlines are still using the Org-assigned values for this...
#+begin_org
* Project :taskjuggler_project:
SCHEDULED: 2013-03-01 Fri
** Technical :T:
:PROPERTIES:
:task_id: T
:END:
*** Sub task
:PROPERTIES:
:task_id: T1
:END:
#+end_org
This gets exported as:
#+begin_tjp
task technical Technical {
purge allocate
allocate jwhendy
task sub Sub task {
milestone
}
}
#+end_tjp
Variations:
- I also tried using =:task_id: T= to see if it needed to be in quotes
- Tried changing my drawer name to TASK_ID to check for case-sensitivity
The results of both were the same. Is this something on my end or a
but in ox-taskjuggler.el?
Thanks,
John
Re: [O] Item task_id not being used in taskjuggler export
On Sun, Mar 31, 2013 at 7:16 PM, John Hendy jw.he...@gmail.com wrote:
On Sun, Mar 31, 2013 at 7:04 PM, John Hendy jw.he...@gmail.com wrote:
I seem to be having trouble getting custom task_id values used for my
taskjuggler file. From ox-taskjuggler.el:
#+begin_quote
(defun org-taskjuggler--build-task (task info)
Return a task declaration.
TASK is a headline. INFO is a plist used as a communication
channel.
All valid attributes from TASK are inserted. If TASK defines
a property \task_id\ it will be used as the id for this task.
Otherwise it will use the ID property. If neither is defined
a unique id will be associated to it.
[snip]
#+end_quote
However, my headlines are still using the Org-assigned values for this...
#+begin_org
* Project :taskjuggler_project:
SCHEDULED: 2013-03-01 Fri
** Technical :T:
:PROPERTIES:
:task_id: T
:END:
*** Sub task
:PROPERTIES:
:task_id: T1
:END:
#+end_org
This gets exported as:
#+begin_tjp
task technical Technical {
purge allocate
allocate jwhendy
task sub Sub task {
milestone
}
}
#+end_tjp
Variations:
- I also tried using =:task_id: T= to see if it needed to be in quotes
- Tried changing my drawer name to TASK_ID to check for case-sensitivity
The results of both were the same. Is this something on my end or a
but in ox-taskjuggler.el?
Thanks,
John
As a followup, within a section, the :depends: attribute is being
correctly resolved, even though naming is incorrect. I've taken to
giving each area a single letter task_id, such as:
#+begin_org
* Project
** Technical
:PROPERTIES:
:TASK_ID: T
:END:
*** Sub task
:PROPERTIES:
:task_id: T1
:END:
*** Sub task2
*** Sub task
:PROPERTIES:
:task_id: T2
:depends: T1
:END:
#+end_org
That's resolving deps correctly, but not naming correctly:
#+begin_tjp
task sub Sub task {
milestone
}
task sub_task2 Sub task2 {
depends !sub
milestone
#+end_tjp
The problem with this is when depending on something outside of that
particular subtask; the TJ syntax is to use =!= as the equivalent to a
period with respect to directories. So to refer to a task in another
bucket, you need to do something like =:depends: !!M.M1= to refer to
the Milestone bucket (task_id = M), subtask M1 task.
This isn't working with Org taskjuggler export. Not being able to name
task is a huge inconvenience, as one has to use Org's unique-id naming
function, which I'd prefer not to do. It's easier (at least for me) to
just unfold all the property drawers and refer to things by their two
character id. I also tagged each top headline with it's letter bucket
:T: so that I can just count the item order in the list for it's
resulting subtask id (e.g. T2).
Best regards,
John
Last addendum. I think this is what's going on:
- ox-taskjuggler will use task_id var for dependencies, but not the
actual task_id
- thus, it's resolving my dependencies (within a sub-task bucket), but
not using the actual names
Here's how unique-ids are assigned:
#+begin_src ox-taskjuggler.el
(defun org-taskjuggler-assign-task-ids (tasks info)
Assign a unique ID to each task in TASKS.
TASKS is a list of headlines. Return value is an alist between
headlines and their associated ID. IDs are hierarchical, which
means they only need to be unique among the task siblings.
(let* (alist
(build-id
(lambda (tasks local-ids)
(org-element-map tasks 'headline
(lambda (task)
(let ((id (org-taskjuggler--build-unique-id task local-ids)))
(push id local-ids)
(push (cons task id) alist)
(funcall build-id (org-element-contents task) nil)))
info nil 'headline
(funcall build-id tasks nil)
alist))
#+end_src
Nothing related to task_id. That's calling this, which just makes sure
the initially parsed list is actually unique, and does some syntax
tweaking to make sure things work for what taskjuggler expects for
task_id syntax:
#+begin_src ox-taskjuggler.el
(defun org-taskjuggler--build-unique-id (item unique-ids)
Return a unique id for a given task or a resource.
ITEM is an `headline' type element representing the task or
resource. Its id is derived from its name and made unique
against UNIQUE-IDS. If the (downcased) first token of the
headline is not unique try to add more (downcased) tokens of the
headline or finally add more underscore characters (\_\).
(let* ((parts (org-split-string (org-element-property :raw-value item)))
(id (org-taskjuggler--clean-id (downcase (pop parts)
;; Try to add more parts of the headline to make it unique.
(while (and (car parts) (member id unique-ids))
(setq id (concat id _
(org-taskjuggler--clean-id (downcase (pop parts))
;; If it's still not unique, add _.
(while (member id
[O] [RFC] new :post header argument for post-processing of code block results
Hi, I've been wanting to add the ability to post-process the results of a code block for some time, and some recent threads (e.g., [1] and [2]) could both have benefited from post-processing of code block output. The attached patch [3] adds a new :post header argument, which may be used to specify a code block reference to use to post-process the results of the current code block. The following example illustrates how this header argument could be used to add attr_latex lines to table code block results. #+Title: Proposed =post= Header Argument #+Author: Eric Schulte * a code block which does the post processing This code block adds latex width attributes to whatever =data= is passed to it. #+name: add-attr #+begin_src sh :var data= :results output drawer :var width=\textwidth echo #+attr_latex: width=$width echo $data #+end_src * two code blocks which use the post processing The following two code blocks demonstrate the use of the new =post= header argument, whcih we could add if it seems generally useful and not too confusing. This works by lexically binding the =*this*= variable to the results of the current code block, and then calling the =add-attr= code block to post-process these results. #+begin_src sh :results output wrap :post add-attr(width=5cm,data=(identity *this*)) cat EOF | 1 | 2 | | 3 | 4 | EOF #+end_src #+RESULTS: :RESULTS: #+attr_latex: width=5cm | 1 | 2 | | 3 | 4 | :END: This code block does the same thing as the previous one, but using different values and arguments. #+header: :post add-attr(width=0.5\\textwidth,data=(identity *this*)) #+begin_src sh :results output wrap cat EOF | 5 | 6 | | 7 | 8 | EOF #+end_src #+RESULTS: :RESULTS: #+attr_latex: width=0.5\textwidth | 5 | 6 | | 7 | 8 | :END: * another unrelated example Say we only care about the size of our results, then we could use the following. #+name: wc #+begin_src sh data= echo $data|wc #+end_src This code block checks the size of some Emacs Lisp data (in this case my =load-path= variable). #+begin_src emacs-lisp :post wc(data=(identity *this*)) load-path #+end_src #+RESULTS: : 160 1606783 Does this new header argument seem useful? Any suggestions for better syntax which don't add too much conceptual or code complexity? Thanks, Footnotes: [1] http://thread.gmane.org/gmane.emacs.orgmode/69339 [2] http://thread.gmane.org/gmane.emacs.orgmode/68700 [3] From f83f31d82c0c660c74a2af7114d4e23c9b37c095 Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Sun, 31 Mar 2013 19:02:11 -0600 Subject: [PATCH] :post header arg post-processes code block results * lisp/ob-core.el (org-babel-common-header-args-w-values): Add :post to the list of header arguments. (org-babel-execute-src-block): Post process results when the :post header argument has been supplied. --- lisp/ob-core.el | 6 ++ 1 file changed, 6 insertions(+) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 723aa9d..e1321eb 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -456,6 +456,7 @@ then run `org-babel-pop-to-session'. (noweb-ref . :any) (noweb-sep . :any) (padline . ((yes no))) +(post . :any) (results . ((file list vector table scalar verbatim) (raw html latex org code pp drawer) (replace silent none append prepend) @@ -625,6 +626,11 @@ block. (not (listp result))) (list (list result)) result)) (funcall cmd body params))) + ;; possibly perform post process provided its appropriate + (when (cdr (assoc :post params)) + (let ((*this* result)) + (setq result (org-babel-ref-resolve + (cdr (assoc :post params)) ;; if non-empty result and :file then write to :file (when (cdr (assoc :file params)) (when result -- 1.8.2 -- Eric Schulte http://cs.unm.edu/~eschulte
[O] [PATCH] Properly escape ~ for LaTeX export
* lisp/ox-latex.el:
(org-latex-plain-text): Properly escape ~ for LaTeX export
In LaTeX, \~ gives a tilde diacritic (as in ã). \textasciitilde{} is
the correct escape for a tilde.
---
lisp/ox-latex.el | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 8727adc..af7e11e 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2031,8 +2031,8 @@ TEXT is the string to transcode. INFO is a plist holding
contextual information.
(let ((specialp (plist-get info :with-special-strings))
(output text))
-;; Protect %, #, , $, ~, ^, _, { and }.
-(while (string-match \\([^\\]\\|^\\)\\([%$#{}~^_]\\) output)
+;; Protect %, #, , $, ^, _, { and }.
+(while (string-match \\([^\\]\\|^\\)\\([%$#{}^_]\\) output)
(setq output
(replace-match
(format \\%s (match-string 2 output)) nil t output 2)))
@@ -2043,6 +2043,10 @@ contextual information.
(replace-regexp-in-string
(format \\(?:[^\\]\\|^\\)\\(\\)\\(?:[^%s]\\|$\\) symbols)
$\\backslash$ output nil t 1)))
+;; Protect ~
+(while (string-match \\([^\\]\\|^\\)\\(~\\) output)
+ (setq output
+(replace-match \\textasciitilde{} nil t output 2)))
;; Activate smart quotes. Be sure to provide original TEXT string
;; since OUTPUT may have been modified.
(when (plist-get info :with-smart-quotes)
--
1.8.2
[O] [PATCH] Fix several byte-compile warnings in org-contrib files
* contrib/lisp/org-bibtex-extras.el: convert to using cl-lib functions (obe-bibtex-file), (obe-html-link-base): add a 'group argument to defcustoms (obe-citations): replace non-existent org-babel-clean-text-properties with org-no-properties * contrib/lisp/org-git-link.el: add an eval-and-compile to avoid undefined function warnings (org-git-show): use with-current-buffer instead of save-excursion+set-buffer --- contrib/lisp/org-bibtex-extras.el | 17 ++--- contrib/lisp/org-git-link.el | 14 +++--- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/contrib/lisp/org-bibtex-extras.el b/contrib/lisp/org-bibtex-extras.el index e3c0f49..57a15ed 100644 --- a/contrib/lisp/org-bibtex-extras.el +++ b/contrib/lisp/org-bibtex-extras.el @@ -60,15 +60,18 @@ ;;; Code: (require 'org-bibtex) +(require 'cl-lib) -(defcustom obe-bibtex-file nil File holding bibtex entries.) +(defcustom obe-bibtex-file nil File holding bibtex entries. + :group 'org-bibtex) (defcustom obe-html-link-base nil Base of citation links. For example, to point to your `obe-bibtex-file' use the following. (setq obe-html-link-base (format \file:%s\ obe-bibtex-file)) -) + + :group 'org-bibtex) (defvar obe-citations nil) (defun obe-citations () @@ -78,7 +81,7 @@ For example, to point to your `obe-bibtex-file' use the following. (find-file obe-bibtex-file) (goto-char (point-min)) (while (re-search-forward :CUSTOM_ID: \\(.+\\)$ nil t) - (push (org-babel-clean-text-properties (match-string 1)) + (push (org-no-properties (match-string 1)) obe-citations)) obe-citations))) @@ -117,18 +120,18 @@ For example, to point to your `obe-bibtex-file' use the following. (defun obe-meta-to-json (meta optional fields) Turn a list of META data from citations into a string of json. (let ((counter 1) nodes links) -(flet ((id (it) (position it nodes :test #'string= :key #'car)) +(flet ((id (it) (cl-position it nodes :test #'string= :key #'car)) (col (k) (mapcar (lambda (r) (cdr (assoc k r))) meta)) (add (lst) (dolist (el lst) (push (cons el counter) nodes)) (incf counter))) ;; build the nodes of the graph (add (col :title)) - (add (remove-if (lambda (author) (string-match others author)) - (remove-duplicates (apply #'append (col :authors)) + (add (cl-remove-if (lambda (author) (string-match others author)) + (cl-remove-duplicates (apply #'append (col :authors)) :test #'string=))) (dolist (field fields) - (add (remove-duplicates (col field) :test #'string=))) + (add (cl-remove-duplicates (col field) :test #'string=))) ;; build the links in the graph (dolist (citation meta) (let ((dest (id (cdr (assoc :title citation) diff --git a/contrib/lisp/org-git-link.el b/contrib/lisp/org-git-link.el index a4759c9..b5ca96f 100644 --- a/contrib/lisp/org-git-link.el +++ b/contrib/lisp/org-git-link.el @@ -131,11 +131,11 @@ relpath (concat (file-name-as-directory (second dirlist)) relpath (list (expand-file-name .git dir) relpath - -(if (featurep 'xemacs) -(defalias 'org-git-gitrepos-p 'org-git-find-gitdir) - (defalias 'org-git-gitrepos-p 'org-git-find-gitdir - Return non-nil if path is in git repository)) +(eval-and-compile + (if (featurep 'xemacs) + (defalias 'org-git-gitrepos-p 'org-git-find-gitdir) +(defalias 'org-git-gitrepos-p 'org-git-find-gitdir + Return non-nil if path is in git repository))) ;; splitting the link string @@ -196,8 +196,8 @@ (unless (zerop (call-process org-git-program nil buffer nil --no-pager (concat --git-dir= gitdir) show object)) -(error git error: %s (save-excursion (set-buffer buffer) -(buffer-string) +(error git error: %s (with-current-buffer buffer + (buffer-string) (defun org-git-blob-sha (gitdir object) Return sha of the referenced object -- 1.8.2
[O] [PATCH 0/3] synctex support for pdf export
This patch series is an attempt to add synctex support to org mode.
With synctex, you can click on a spot in a document in a PDF viewer,
and have emacs jump to the line of code that generated that part of
the pdf. (See http://emacswiki.org/emacs/AUCTeX for tips on getting
synctex set up with emacs). This is very useful when authoring
documents -- you can notice a typo in the pdf, and click directly on
it to fix the corresponding line in the tex file.
This allows the same functionality with org files -- click on a spot
in the generated PDF, and jump in emacs to the org source for that
spot. This functionality is currently controled by the variable
org-export-with-concordance (disabled by default). It also relies on
the latex process generating a synctex file -- use \synctex=1 in the
document header to enable that (you probably have to use pdflatex,
xelatex, or lualatex -- not plain latex + dvipdf).
I have not tested this code extensively, but it does work for me. I
don't know if it works for async export or not, since I haven't set up
a working environment for that.
There are currently limitations. The granularity of the jumping is
not great, because of the way the parser works. It will get you into
the paragraph corresponding to the PDF location, but no closer (with
pure latex, you will arrive at the exact line in the tex file). You
also have to run org-latex-patch-synctex manually, unless you use the
direct-to-pdf export option (C-c C-e l p). In regular latex, beamer
documents have somewhat degraded synctex granularity (in general, you
don't get to the exact source line, but only somewhere between
\begin{frame} and \end{frame}). This may be compounded by the bad
granularity of this patch -- I have not tested this combo very much.
It should be possible to support the other direction of
synchronization as well -- jumping from a location in the org file to
a location in the PDF document (most pdf viewers show a highlight of
some sort, to pick out the location requested). I haven't implemented
that yet, but it should be easy. I have also not implemented support
for multi-file org documents (with #+include). That is also in
principle possible, however it will be difficult (or at least tedious)
to implement in practice because it will require yet another round of
text properties to be applied at some point in the export process.
I'm releasing the code for comments on the implementation, which is
somewhat dense. Because of the way the parser/exporter works, in
order to track the line number from beginning to end I need to use 2
kinds of text properties. A change in the parser is also required, to
attach line numbers to objects. (Though the implementation is dense,
it was also not terribly difficult to code, once I understood the code
I was modifying. The clear structure of Nicolas's exporter/parser is
responsible for this fact, more than any cleverness of mine.)
Comments on the code are welcome. Testers are also welcome. In order
to test the code, you need to:
1) set up synctex to work with your emacs/pdf program
2) set org-export-with-concordance to t
3) make sure your latex program generates a .synctex.gz file
4) export your favorite org document to pdf (directly)
5) it should now work!
Thanks,
Aaron
Aaron Ecay (3):
Add :begin-line and :end-line to parser results
Introduce machinery to ox.el for concordance generation
Add synctex modification based on concordance
lisp/org-element.el | 120 +
lisp/ox-latex.el| 64 +++---
lisp/ox.el | 151 +---
3 files changed, 297 insertions(+), 38 deletions(-)
--
1.8.2
[O] [PATCH 3/3] Add synctex modification based on concordance
* lisp/ox-latex.el (org-latex-patch-synctex): New function (org-latex-export-to-pdf): Call it, if appropriate This teaches the latex backend how to patch synctex files. The patch will be done automatically if exporting directly to pdf. If not, the user must call the org-latex-patch-synctex function (because it relies on the synctex file, which will only be generated when pdflatex is run) Touch the file after modifying the synctex, to trigger the pdf viewer to re-read it. --- lisp/ox-latex.el | 64 +--- 1 file changed, 56 insertions(+), 8 deletions(-) diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el index 8727adc..43c5fde 100644 --- a/lisp/ox-latex.el +++ b/lisp/ox-latex.el @@ -115,6 +115,7 @@ (eval-when-compile (require 'cl)) (require 'ox) (require 'ox-publish) +(require 'dired) ; for dired-touch-program (defvar org-latex-default-packages-alist) (defvar org-latex-packages-alist) @@ -1150,6 +1151,43 @@ just outside of it. (funcall search-refs element)) )) +(defun org-latex-patch-synctex (optional subtreep) + (cond + ((not org-export-concordance) +(message No concordance, not patching.)) + ((not (file-exists-p + (org-export-output-file-name .synctex.gz subtreep))) +(message No synctex file found, not patching.)) + (t +(let* ((conc org-export-concordance) + (file-base (org-export-output-file-name . subtreep)) + (buf (find-file-noselect (concat file-base synctex.gz + (with-current-buffer buf + (let ((max-index 0) + the-index extra-path) + (goto-char (point-min)) + (while (re-search-forward ^Input:\\([0-9]+\\): nil t) + (setq max-index (max max-index (string-to-int (match-string 1) + (goto-char (point-min)) + (when (re-search-forward (concat ^Input:\\([0-9]+\\):\\(.*\\) + (regexp-quote file-base) tex$) + nil t) + (setq the-index (string-to-int (match-string 1))) + (setq extra-path (match-string 2)) + (goto-char (line-end-position)) + (insert (format \nInput:%s:%s%sorg (1+ max-index) extra-path file-base))) + (goto-char (point-min)) + (while (re-search-forward (format ^[vhxkgr$[)]\\(%s\\),\\([0-9]+\\): + the-index) + nil t) +(replace-match (int-to-string (1+ max-index)) nil t nil 1) + (replace-match +(int-to-string + (org-export--read-concordance conc (string-to-int (match-string 2 +nil t nil 2)) + (save-buffer))) + (kill-buffer buf) + ;;; Template @@ -2918,14 +2956,24 @@ Return PDF file's name. (let ((outfile (org-export-output-file-name .tex subtreep))) (org-export-async-start (lambda (f) (org-export-add-to-stack f 'latex)) - `(expand-file-name - (org-latex-compile -(org-export-to-file - 'latex ,outfile ,subtreep ,visible-only ,body-only - ',ext-plist) -(org-latex-compile - (org-latex-export-to-latex - nil subtreep visible-only body-only ext-plist + `(let ((pdf-file + (expand-file-name + (org-latex-compile + (org-export-to-file +'latex ,outfile ,subtreep ,visible-only ,body-only +',ext-plist) +(when org-export-with-concordance + (org-latex-patch-synctex subtreep) + (call-process dired-touch-program nil nil nil pdf-file)) +pdf-file))) +(let ((pdf-file + (org-latex-compile + (org-latex-export-to-latex +nil subtreep visible-only body-only ext-plist + (when org-export-with-concordance + (org-latex-patch-synctex subtreep) +(call-process dired-touch-program nil nil nil pdf-file)) + pdf-file))) (defun org-latex-compile (texfile optional snippet) Compile a TeX file. -- 1.8.2
[O] [PATCH 1/3] Add :begin-line and :end-line to parser results
* lisp/org-element.el: Add :begin-line and :end-line to parser results These properties give the line on which an element begins/ends --- lisp/org-element.el | 120 1 file changed, 120 insertions(+) diff --git a/lisp/org-element.el b/lisp/org-element.el index e09d2cb..c074092 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -521,6 +521,8 @@ Assume point is at the beginning of the block. (nconc (list :begin begin :end end + :begin-line (org-element--line-number-at-pos begin) + :end-line (org-element--line-number-at-pos end) :hiddenp hidden :contents-begin contents-begin :contents-end contents-end @@ -575,6 +577,8 @@ Assume point is at beginning of drawer. (nconc (list :begin begin :end end + :begin-line (org-element--line-number-at-pos begin) + :end-line (org-element--line-number-at-pos end) :drawer-name name :hiddenp hidden :contents-begin contents-begin @@ -635,6 +639,8 @@ Assume point is at beginning of dynamic block. (nconc (list :begin begin :end end +:begin-line (org-element--line-number-at-pos begin) +:end-line (org-element--line-number-at-pos end) :block-name name :arguments arguments :hiddenp hidden @@ -696,6 +702,8 @@ Assume point is at the beginning of the footnote definition. (list :label label :begin begin :end end + :begin-line (org-element--line-number-at-pos begin) + :end-line (org-element--line-number-at-pos end) :contents-begin contents-begin :contents-end contents-end :post-blank (count-lines ending end) @@ -812,6 +820,8 @@ Assume point is at beginning of the headline. (list :raw-value raw-value :begin begin :end end + :begin-line (org-element--line-number-at-pos begin) + :end-line (org-element--line-number-at-pos end) :pre-blank (if (not contents-begin) 0 (count-lines pos-after-head contents-begin)) @@ -977,6 +987,8 @@ Assume point is at beginning of the inline task. (list :raw-value raw-value :begin begin :end end +:begin-line (org-element--line-number-at-pos begin) +:end-line (org-element--line-number-at-pos end) :hiddenp hidden :contents-begin contents-begin :contents-end contents-end @@ -1096,6 +1108,8 @@ Assume point is at the beginning of the item. (list :bullet bullet :begin begin :end end + :begin-line (org-element--line-number-at-pos begin) + :end-line (org-element--line-number-at-pos end) ;; CONTENTS-BEGIN and CONTENTS-END may be ;; mixed up in the case of an empty item ;; separated from the next by a blank line. @@ -1181,6 +1195,8 @@ Assume point is at the beginning of the list. (list :type type :begin begin :end end + :begin-line (org-element--line-number-at-pos begin) + :end-line (org-element--line-number-at-pos end) :contents-begin contents-begin :contents-end contents-end :structure struct @@ -1238,6 +1254,8 @@ Assume point is at the beginning of the property drawer. (nconc (list :begin begin :end end +:begin-line (org-element--line-number-at-pos begin) +:end-line (org-element--line-number-at-pos end) :hiddenp hidden :contents-begin contents-begin :contents-end contents-end @@ -1291,6 +1309,8 @@ Assume point is at the beginning of the block. (nconc (list :begin begin :end end +:begin-line (org-element--line-number-at-pos begin) +:end-line (org-element--line-number-at-pos end) :hiddenp hidden :contents-begin
[O] [PATCH 2/3] Introduce machinery to ox.el for concordance generation
* lisp/ox.el (org-export-concordance): New buffer-local variable (org-export-with-concordance): New user option (org-export--concordance-propertize), (org-export--concordance-propertize-pre), (org-export--build-concordance), (org-export--read-concordance): New functions (org-export-data): Call org-export–concordance-propertize where appropriate (org-export-as), (org-export-to-buffer), (org-export-to-file): Handle concordance generation The general idea is as follows: 1) Before copying the buffer for export, call org-export--propertize-pre to add line-number properties to the buffer 2) The parser sees these properties during export (previous commit) 3) org-export-data adds text properties to the strings it generates, indicating which lines they originated from (using function org-export--propertize) 4) These properties survive into the output buffer (because export no longer calls org-no-properties) 5) After export is finished, org-export-build-concordance walks the result buffer, calculating a concordance of source lines and output lines. 6) This value is stored in the org buffer’s org-export-concordance local variable --- lisp/ox.el | 151 + 1 file changed, 121 insertions(+), 30 deletions(-) diff --git a/lisp/ox.el b/lisp/ox.el index ff6407b..e1c76bd 100644 --- a/lisp/ox.el +++ b/lisp/ox.el @@ -302,6 +302,13 @@ and its CDR is a list of export options.) This marker will be used with `C-u C-c C-e' to make sure export repetition uses the same subtree if the previous command was restricted to a subtree.) +(defvar org-export-concordance nil + The concordance resulting from the last export operation. + +The variable is always buffer-local, and only manipulated if +`org-export-with-concordance' is set.) +(make-variable-buffer-local 'org-export-concordance) + ;;; User-configurable Variables ;; @@ -351,6 +358,16 @@ e.g. \c:t\. :group 'org-export-general :type 'boolean) +(defcustom org-export-with-concordance nil + Non-nil means to generate a concordance. + +This is currently useful only for the LaTeX backend (and derived +backends), which can use it to patch the SyncTeX file generated +by LaTeX, so that it is possible to jump back and forth between +the org file and resulting pdf. + :group 'org-export-general + :type 'boolean) + (defcustom org-export-with-creator 'comment Non-nil means the postamble should contain a creator sentence. @@ -2040,6 +2057,61 @@ INFO is a plist containing export directives. (let ((transcoder (cdr (assq type (plist-get info :translate-alist) (and (functionp transcoder) transcoder) +(defun org-export--concordance-propertize (data string) + Add line number text properties to STRING, based on DATA. + +This will allow the construction of a concordance from the +completed string. + (let ((len (length string))) +(when ( len 1) + (put-text-property 0 1 'org-line-num +(org-element-property :begin-line data) +string) + (put-text-property (1- len) len 'org-line-num +(org-element-property :end-line data) +string))) + string) + +(defun org-export--concordance-propertize-pre () + Put line-number text properties on a buffer. + +Each line gets a org-line-num-pre property, which is its line +number in the buffer before any export operations have changed +the buffer. + ;; This is called from `org-export-as', which has issued + ;; `save-restriction'. + (widen) + (while (= 0 (forward-line 1)) +(put-text-property (point) (point-at-eol) 'org-line-num-pre + (line-number-at-pos + +(defun org-export--build-concordance () + Build a concordance, based on text props in an exported buffer. + (save-excursion +(let ((res '()) + next) + (goto-char (point-min)) + (while (setq next (next-single-property-change (point) 'org-line-num)) + (goto-char next) + (setq res (cons (cons (line-number-at-pos) + (get-text-property (point) 'org-line-num)) + res)) + (forward-char 1)) + (setq res (nreverse res)) + (setq next res) + (while (cdr next) + (if (equal (caar next) (caadr next)) + (setcdr next (cddr next)) + (setq next (cdr next + res))) + +(defun org-export--read-concordance (concordance src-line) + Get the original line number from CONCORDANCE for output line SRC-LINE. + (while (and (caadr concordance) + (= (caadr concordance) src-line)) +(setq concordance (cdr concordance))) + (cdar concordance)) + (defun org-export-data (data info) Convert DATA into current back-end format. @@ -2056,11 +2128,16 @@ Return transcoded string. ((memq data (plist-get info :ignore-list)) nil) ;; Plain text. ((eq type 'plain-text) -
[O] export parameters in ORG file
Back in the day, when I C-x C-e to export from an org file, I could tap a key and put all the control factors into the top of the file. Now I don't see that option when I do this. Are they gone? Or is it still possible to do this? Dave
Re: [O] Minibuffer jumping to two lines when agenda displays 3rd(4th) level heading
In order to better describe the problem I see, I set up a simple example file: * H 1 SCHEDULED: 2013-03-31 Sun ** H 1a SCHEDULED: 2013-03-31 Sun ** H 1b *** H 1b1 SCHEDULED: 2013-03-31 Sun H 1b1a SCHEDULED: 2013-03-31 Sun ** H 1b1a1 SCHEDULED: 2013-03-31 Sun * H 2 SCHEDULED: 2013-03-31 Sun In the agenda, when I move my cursor from 'H 1b1' to 'H 1b1a' the minibuffer expands to two lines even though the path display is only using a small portion of the line (ie not wrapping). It seems to have more to do with the heading depth since the same 2-line minibuffer continues when the cursor is in 'H 1b1a1' but drops back to 1-line when moved to 'H 2'. Does anyone have any ideas why this is happening? -ED-
Re: [O] Proposal for new/updated exporter tutorials on Worg
On Sat, Mar 30, 2013 at 8:45 AM, Bastien b...@altern.org wrote: Hi John, thanks for the great work so far! This is of huge help. No problem -- In the absence of lisp ability... the least I can do, in fact. John Hendy jw.he...@gmail.com writes: My thinking on this is that Org-8.0 is a significant step, however it would be nice to write documentation as it pertains to Org 8.0 and not constantly in reference to how it's different from Org-7.x. Agreed. If there is no indication on the Worg page, users should be right in assuming this is for the latest stable version. Instead of an OUTDATED cookie, I suggest introducing #+PROPERTY: OrgCompat_ALL 8.0 7.9 7.8 7.7 (... using values from `customize-package-emacs-version-alist') in a setup file and #+PROPERTY: OrgCompatible 8.0 in files where instructions are relevant starting from 8.0. Then a macro could insert that compatible version. What do you think? Not sure how to implement this, but sounds reasonable. I'd like to get everything export related into it's own directories, if possible. Right now, they're just in org-tutorials for the most part. I'll have to look more closely at what's actually in there. I see org-tutorials as related to Org in general (some of which covers export usage), and export-specific stuff to be in another category. These I'd like to see in their own bucket; if we're now separating pre-8.0 stuff and 8.0-forward things, perhaps another directory could be created. As for the outline above... I changed my mind a bit. I think it makes sense to leave your upgrade guide as the repository for... upgrade-specific information. I rearranged it a bit this evening to help with flow, and also listed out the two main changes users need to make to update: 1) Look for org-export-* options and change them to org-backend-* in config files 2) Specifically load backends in .emacs if they're using more than ASCII, HTML, and LaTeX I also pushed ox-overview, which will now serve as the primary reference for the new exporter and contains the list of exporters table. It's mostly blank, but contains a [non-exported] copy/pasted version of Nicolas' announcement on the mailing list which I think should be incorporated in there somehow. It will be good make sure Worg doesn't overlap the manual too much.[1] At the very least, it should have some explanation of the motivation behind the exporter and the features/advantages it provides (I think that would be of interest). I also made the call (could be reversed) that I think the new Worg exporter documentation should live in worg.git/exporters/backend directories. This can house: - ox-backend.org: overview, primary usage guide, tutorial, references - ox-backend-example.org: a standalone, reproducible example document - ox-backend-example.ext: a compiled/exported version of the tutorial These three will guide the user and allow him/her to download an org file and compile it locally to check their setup and/or results. I think a downloadable end result will also help give an idea of what the exporter is capable of. ox-template.org is now pushed as well. It's modified from ob-doc-template.org. Best regards, John [1] As an aside, is there a good reference for what Worg should/could contain and what should live in the manual? I've noticed recently on the list that, for example, :wrap was documented in the manual even though =:results output wrap= came up on the mailing list and was not in the Worg summary of header options. If too much is duplicated, it make for double the things to track... Where's the manual with respect to the new exporter? If it's ahead of Worg's state, the documentation on Worg can be used to supplement in reference to the manual vs. duplicating what's to come! -- Bastien
Re: [O] Minibuffer jumping to two lines when agenda displays 3rd(4th) level heading
Found the problem. Some color themes boldface the 3rd and 4th heading levels and that causes the minibuffer to jump to 2 lines. No more themes, no more jumping. -ED-
Re: [O] [PATCH] * lisp/ob-core.el (org-babel-execute-src-block): insert hash for silent results
Hi Eric, 2013ko martxoak 23an, Eric Schulte-ek idatzi zuen: Unless you actually try :var and find it lacking in some way, I'd prefer to stick with simply using :var to identify dependencies between code blocks. We've seen in other places how providing multiple alias for header arguments increases rather than reduces confusion. I’m uneasy with how magic :var is, in the sense that it does a lot of heavy lifting with interconversion to/from org syntax, table formats, etc. What if a special convention was introduced, whereby :var _=whatever would not result in any variable binding being introduced into the code block (but would behave the same wrt. dependencies)? This is similar to the syntax for discarding unused values in some programming languages (python comes to mind): #+begin_src python _, foo, _ = iOnlyCareAboutTheSecondValue() #+end_src So, this would look like: #+begin_src R :var a=123 :var _=(R-pid) :var _=(something-else) # code which can access a, but has no access to (R-pid) or (something-else) #+end_src If this doesn’t resonate with you, I’ll just drop this suggestion. I will of course certainly report any problems I have using :var in practice as well, with patches to fix them insofar as it is within my ability to provide them. Maybe the documentation of :var should be improved to enhance discoverability. I would be happy to apply a patch to this effect. Patch is on the way. Why not just return a dummy value at the end of the code block? #+begin_src R :cache yes # code to perform side effect done #+end_src This would require the user to add this dummy result redundantly to many code blocks, for no reason. That is cognitively burdensome (user must remember when to add it) and ugly, if the source code is to be exported in the document (or tangled). But this case is straightforward to detect on org’s end, and fairly straightforward to work around (this is in fact what my original patch was). So I am still not sure why this burden should to be imposed. Well, I suppose one man's dirty kludge is another's beautiful hack. The question here is whether the complexity lies in the implementation (and thus the interface) or in the code block itself. While I generally prefer the later, in this case of :results none :cache yes I would be open to placing some custom logic in the backend, which stores the hash value with the code block, possibly changing #+begin_src R :cache yes # code to perform side effect #+end_src to #+begin_src R :cache 9f4e5b4b07e93c680ab37fc4ba1f75e1bfc0ee0a # code to perform side effect #+end_src keeping in mind that the actual hash value should be hidden after the first couple of characters. [...] If you want the cache in the header, I think I can try to work on a patch, but it does look tricky. So I am not sure I will have time to work on it until next week. (If anyone else wants to beat me to the punch, please feel free!) One question: should we have the cache in the header only for :results none blocks, or for all blocks? I'm just as happy raising an error or warning when the :cache and :results none options are found together, and doing no caching in that case. Users can always just return a dummy value and remove :results none. So should I not work on this modified version of my original patch? I am genuinely trying to be helpful, so that my own modest contribution can make even more useful what is already a very useful tool thanks to the efforts of many people, including you. Maybe I am barking up the wrong tree. I am certainly sorry if you are upset by something I have said – such was never my intention. It sounds like such an (R-pid foo) function would be easy to implement. I'd vote for that solution (implementing this function in your .emacs, and then sharing it if necessary) for now. If this need to associate PIDs with results becomes more wide spread (in a couple of years of Org-mode code blocks this is the first time I've seen it arise), then a built-in solution becomes more appealing. This part of the solution I have implemented: #+name: R-pid #+BEGIN_SRC emacs-lisp (let* ((info (org-babel-get-src-block-info 'light)) (session-name (cdr (assoc :session (nth 2 info) (if (and session-name (not (equal session-name none))) (progn (org-babel-R-initiate-session session-name (nth 2 info)) (with-current-buffer (get-buffer session-name) (process-id (get-process ess-current-process-name none)) #+END_SRC And in my init file: #+BEGIN_SRC emacs-lisp (setq org-babel-default-header-args:R '((:var . R.pid=R-pid))) #+END_SRC I’d prefer to use the proposed _ for the var here, but otherwise this seems to work. Thanks, -- Aaron Ecay
Re: [O] [RFC] new :post header argument for post-processing of code block results
Hi Eric 2013ko martxoak 31an, Eric Schulte-ek idatzi zuen: Hi, I've been wanting to add the ability to post-process the results of a code block for some time, and some recent threads (e.g., [1] and [2]) could both have benefited from post-processing of code block output. This looks very nice! Does this new header argument seem useful? Any suggestions for better syntax which don't add too much conceptual or code complexity? See below. @@ -625,6 +626,11 @@ block. (not (listp result))) (list (list result)) result)) (funcall cmd body params))) + ;; possibly perform post process provided its appropriate + (when (cdr (assoc :post params)) + (let ((*this* result)) + (setq result (org-babel-ref-resolve + (cdr (assoc :post params)) What if you did some string surgery on the :post string, to insert ,data=\the result\ into the call? That way users could just write :post add-width(width=5cm), which would be automatically transformed into add-width(width=5cm,data=[[graph.png]]) before being passed to o-b-ref-resolve. (I guess you’d have to take special care to handle things like :post no-args() and :post no-args properly, stripping the initial comma in the first case and adding parens in the second.) This requires that all :post code blocks take a data argument, but I don’t think that’s more onerous than stipulating the *this* variable at the lisp level. Also, I’m unclear on whether elisp is supported (or should be). Do we want to allow :post (message *this*)? -- Aaron Ecay
[O] [PATCH 00/10] babel cleanups
Here are several patches to fix things in and around org-babel. They're each independent of the others (and hopefully all apply cleanly, without depending on other members of the series). Here's a little summary of each: Aaron Ecay (10): Fix org-babel-R-initiate-session - An obvious bugfix Clean up org-babel-expand-body: functions for awk and picolisp - Makes these functions consistent with other babel languages, though I don't use these languages so can't test Clean up various org-babel-*-maybe commands - Code simplification and avoids an expensive operation under some circumstances Add 'light argument to some uses of org-babel-get-src-block-info - Avoids an expensive operation Remove info arg from several org-babel functions - Code cleanup. Could break third-party code. Use prefix arg in org-edit-special - Makes the function consistent with its docstring, although the new behavior is somewhat odd (C-u C-c ' becomes basically the same as C-c C-v C-z, AFAICT) Simplify org-babel-execute-src-block - Makes data flow cleaner through this function Fix testing/lisp/test-ob-emacs-lisp.el - Obvious bugfix Remove org-babel-check-confirm-evaluate macro - Refactoring. Of all the patches, I am least sure of this one. It is a complicated operation however you slice it, but I find the approach where the complexity is local easier to understand. Deserves careful review, since it touches code which decides whether to evaluate source blocks. Read: has security implications. Document how :var introduces code block dependencies. - Documentation. doc/org.texi | 9 +++ lisp/ob-R.el | 20 +++-- lisp/ob-awk.el | 2 +- lisp/ob-core.el| 156 + lisp/ob-picolisp.el| 2 +- lisp/ob-tangle.el | 2 +- lisp/org.el| 7 +- testing/lisp/test-ob-emacs-lisp.el | 19 +++-- 8 files changed, 112 insertions(+), 105 deletions(-) -- 1.8.2
[O] [PATCH 01/10] Fix org-babel-R-initiate-session
* lisp/ob-R.el (org-babel-R-initiate-session): handle case where the session buffer exists, but does not have a live process If the session buffer exists, but the user has exited the R process manually, then the (R) command will create a new buffer, then try to rename it over the old buffer, causing an error. The right thing to do is to start R within the existing buffer. --- lisp/ob-R.el | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/lisp/ob-R.el b/lisp/ob-R.el index 9875f81..de9ec5b 100644 --- a/lisp/ob-R.el +++ b/lisp/ob-R.el @@ -209,14 +209,18 @@ This function is called by `org-babel-execute-src-block'. (if (org-babel-comint-buffer-livep session) session (save-window-excursion - (require 'ess) (R) - (rename-buffer - (if (bufferp session) - (buffer-name session) -(if (stringp session) -session - (buffer-name - (current-buffer)) + (save-excursion + (when (get-buffer session) + ;; Session buffer exists, but with dead process + (set-buffer session)) + (require 'ess) (R) + (rename-buffer +(if (bufferp session) +(buffer-name session) + (if (stringp session) + session +(buffer-name + (current-buffer))) (defun org-babel-R-associate-session (session) Associate R code buffer with an R session. -- 1.8.2
[O] [PATCH 04/10] Add 'light argument to some uses of org-babel-get-src-block-info
* lisp/ob-core.el (org-babel-do-key-sequence-in-edit-buffer), (org-babel-expand-noweb-references), * lisp/ob-tangle.el (org-babel-tangle): Use 'light argument to `org-babel-get-src-block-info'. --- lisp/ob-core.el | 4 ++-- lisp/ob-tangle.el | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 283628e..0aae998 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -912,7 +912,7 @@ source code block, otherwise return nil. With optional prefix argument RE-RUN the source-code block is evaluated even if results already exist. (interactive P) - (let ((info (org-babel-get-src-block-info))) + (let ((info (org-babel-get-src-block-info 'light))) (when info (save-excursion ;; go to the results, if there aren't any then run the block @@ -2358,7 +2358,7 @@ would set the value of argument \a\ equal to \9\. Note that these arguments are not evaluated in the current source-code block but are passed literally to the \example-block\. (let* ((parent-buffer (or parent-buffer (current-buffer))) - (info (or info (org-babel-get-src-block-info))) + (info (or info (org-babel-get-src-block-info 'light))) (lang (nth 0 info)) (body (nth 1 info)) (ob-nww-start org-babel-noweb-wrap-start) diff --git a/lisp/ob-tangle.el b/lisp/ob-tangle.el index 4bcb2e3..4c6eb5c 100644 --- a/lisp/ob-tangle.el +++ b/lisp/ob-tangle.el @@ -211,7 +211,7 @@ used to limit the exported source code blocks by language. org-babel-default-header-args)) (tangle-file (when (equal arg '(16)) - (or (cdr (assoc :tangle (nth 2 (org-babel-get-src-block-info + (or (cdr (assoc :tangle (nth 2 (org-babel-get-src-block-info 'light (user-error Point is not in a source code block path-collector) (mapc ;; map over all languages -- 1.8.2
[O] [PATCH 05/10] Remove info arg from several org-babel functions
* lisp/ob-core.el (org-babel-load-in-session), (org-babel-initiate-session), (org-babel-switch-to-session) (org-babel-switch-to-session-with-code): Remove info optional arg The info arg is threaded through this code, but never used by callers (at least in org code). --- lisp/ob-core.el | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 0aae998..c69b736 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -794,13 +794,13 @@ arguments and pop open the results in a preview buffer. (add-hook 'org-tab-first-hook 'org-babel-header-arg-expand) ;;;###autoload -(defun org-babel-load-in-session (optional arg info) +(defun org-babel-load-in-session (optional arg) Load the body of the current source-code block. Evaluate the header arguments for the source block before entering the session. After loading the body this pops open the session. (interactive) - (let* ((info (or info (org-babel-get-src-block-info))) + (let* ((info (org-babel-get-src-block-info)) (lang (nth 0 info)) (params (nth 2 info)) (body (if (not info) @@ -820,13 +820,13 @@ session. (end-of-line 1))) ;;;###autoload -(defun org-babel-initiate-session (optional arg info) +(defun org-babel-initiate-session (optional arg) Initiate session for current code block. If called with a prefix argument then resolve any variable references in the header arguments and assign these variables in the session. Copy the body of the code block to the kill ring. (interactive P) - (let* ((info (or info (org-babel-get-src-block-info (not arg + (let* ((info (org-babel-get-src-block-info (not arg))) (lang (nth 0 info)) (body (nth 1 info)) (params (nth 2 info)) @@ -849,19 +849,19 @@ the session. Copy the body of the code block to the kill ring. (funcall init-cmd session params))) ;;;###autoload -(defun org-babel-switch-to-session (optional arg info) +(defun org-babel-switch-to-session (optional arg) Switch to the session of the current code block. Uses `org-babel-initiate-session' to start the session. If called with a prefix argument then this is passed on to `org-babel-initiate-session'. (interactive P) - (pop-to-buffer (org-babel-initiate-session arg info)) + (pop-to-buffer (org-babel-initiate-session arg)) (end-of-line 1)) (defalias 'org-babel-pop-to-session 'org-babel-switch-to-session) ;;;###autoload -(defun org-babel-switch-to-session-with-code (optional arg info) +(defun org-babel-switch-to-session-with-code (optional arg) Switch to code buffer and display session. (interactive P) (let ((swap-windows @@ -870,10 +870,9 @@ with a prefix argument then this is passed on to (set-window-buffer (next-window) (current-buffer)) (set-window-buffer (selected-window) other-window-buffer)) (other-window 1))) - (info (org-babel-get-src-block-info)) (org-src-window-setup 'reorganize-frame)) (save-excursion - (org-babel-switch-to-session arg info)) + (org-babel-switch-to-session arg)) (org-edit-src-code) (funcall swap-windows))) -- 1.8.2
[O] [PATCH 03/10] Clean up various org-babel-*-maybe commands
* lisp/ob-core.el (org-babel-if-in-src-block): New macro (org-babel-execute-src-block-maybe), (org-babel-expand-src-block-maybe), (org-babel-load-in-session-maybe), (org-babel-pop-to-session-maybe): Use it org-babel-get-src-block-info is a potentially expensive operation, which is why its ‘light’ argument exists. But in any case, it is overkill to query the whole info, if all that is needed is whether point is in a block or not. Factor the simplified common code out into a macro. --- lisp/ob-core.el | 31 +-- 1 file changed, 17 insertions(+), 14 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index 723aa9d..283628e 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -365,15 +365,22 @@ of potentially harmful code. (or (org-babel-execute-src-block-maybe) (org-babel-lob-execute-maybe))) +(defmacro org-babel-when-in-src-block (rest body) + `(if (or (org-babel-where-is-src-block-head) + (org-babel-get-inline-src-block-matches)) + (progn +,@body +t) + nil)) + (defun org-babel-execute-src-block-maybe () Conditionally execute a source block. Detect if this is context for a Babel src-block and if so then run `org-babel-execute-src-block'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info - (progn (org-babel-eval-wipe-error-buffer) - (org-babel-execute-src-block current-prefix-arg info) t) nil))) + (org-babel-when-in-src-block + (org-babel-eval-wipe-error-buffer) + (org-babel-execute-src-block current-prefix-arg))) ;;;###autoload (defun org-babel-view-src-block-info () @@ -409,10 +416,8 @@ a window into the `org-babel-get-src-block-info' function. Detect if this is context for a org-babel src-block and if so then run `org-babel-expand-src-block'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info - (progn (org-babel-expand-src-block current-prefix-arg info) t) - nil))) + (org-babel-when-in-src-block + (org-babel-expand-src-block current-prefix-arg))) ;;;###autoload (defun org-babel-load-in-session-maybe () @@ -420,10 +425,8 @@ then run `org-babel-expand-src-block'. Detect if this is context for a org-babel src-block and if so then run `org-babel-load-in-session'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info - (progn (org-babel-load-in-session current-prefix-arg info) t) - nil))) + (org-babel-when-in-src-block + (org-babel-load-in-session current-prefix-arg))) (add-hook 'org-metaup-hook 'org-babel-load-in-session-maybe) @@ -433,8 +436,8 @@ then run `org-babel-load-in-session'. Detect if this is context for a org-babel src-block and if so then run `org-babel-pop-to-session'. (interactive) - (let ((info (org-babel-get-src-block-info))) -(if info (progn (org-babel-pop-to-session current-prefix-arg info) t) nil))) + (org-babel-when-in-src-block + (org-babel-pop-to-session current-prefix-arg))) (add-hook 'org-metadown-hook 'org-babel-pop-to-session-maybe) -- 1.8.2
[O] [PATCH 02/10] Clean up org-babel-expand-body: functions for awk and picolisp
* lisp/ob-awk.el (org-babel-expand-body:awk), lisp/ob-picolisp.el (org-babel-expand-body:picolisp): remove optional arg from these functions The optional argument is apparently never passed by org-babel code. Maybe this is a relic of an earlier calling convention? --- lisp/ob-awk.el | 2 +- lisp/ob-picolisp.el | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/ob-awk.el b/lisp/ob-awk.el index f717fec..373d5fd 100644 --- a/lisp/ob-awk.el +++ b/lisp/ob-awk.el @@ -44,7 +44,7 @@ (defvar org-babel-awk-command awk Name of the awk executable command.) -(defun org-babel-expand-body:awk (body params optional processed-params) +(defun org-babel-expand-body:awk (body params) Expand BODY according to PARAMS, return the expanded body. (dolist (pair (mapcar #'cdr (org-babel-get-header params :var))) (setf body (replace-regexp-in-string diff --git a/lisp/ob-picolisp.el b/lisp/ob-picolisp.el index e785366..1d17919 100644 --- a/lisp/ob-picolisp.el +++ b/lisp/ob-picolisp.el @@ -78,7 +78,7 @@ :version 24.1 :type 'string) -(defun org-babel-expand-body:picolisp (body params optional processed-params) +(defun org-babel-expand-body:picolisp (body params) Expand BODY according to PARAMS, return the expanded body. (let ((vars (mapcar #'cdr (org-babel-get-header params :var))) (result-params (cdr (assoc :result-params params))) -- 1.8.2
[O] [PATCH 07/10] Simplify org-babel-execute-src-block
* lisp/ob-core.el (org-babel-execute-src-block): Simplify control flow Avoid potential duplication of org-babel-process-params call. Also makes the code simpler. --- lisp/ob-core.el | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index c69b736..d8c11ee 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -557,13 +557,11 @@ Optionally supply a value for PARAMS which will be merged with the header arguments specified at the front of the source code block. (interactive) - (let* ((info (or info (org-babel-get-src-block-info))) -(merged-params (org-babel-merge-params (nth 2 info) params))) -(when (org-babel-check-evaluate - (let ((i info)) (setf (nth 2 i) merged-params) i)) - (let* ((params (if params -(org-babel-process-params merged-params) - (nth 2 info))) + (let* ((info (or info (org-babel-get-src-block-info 'light +(setf (nth 2 info) (org-babel-merge-params (nth 2 info) params)) +(when (org-babel-check-evaluate info) + (setf (nth 2 info) (org-babel-process-params (nth 2 info))) + (let* ((params (nth 2 info)) (cachep (and (not arg) (cdr (assoc :cache params)) (string= yes (cdr (assoc :cache params) (new-hash (when cachep (org-babel-sha1-hash info))) @@ -578,8 +576,7 @@ block. (let ((result (org-babel-read-result))) (message (replace-regexp-in-string % %% (format %S result))) result))) -((org-babel-confirm-evaluate - (let ((i info)) (setf (nth 2 i) merged-params) i)) +((org-babel-confirm-evaluate info) (let* ((lang (nth 0 info)) (result-params (cdr (assoc :result-params params))) (body (setf (nth 1 info) -- 1.8.2
[O] [PATCH 08/10] Fix testing/lisp/test-ob-emacs-lisp.el
* testing/lisp/test-ob-emacs-lisp.el: Move stray test inside ert-deftest --- testing/lisp/test-ob-emacs-lisp.el | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/testing/lisp/test-ob-emacs-lisp.el b/testing/lisp/test-ob-emacs-lisp.el index 94092e4..d03f048 100644 --- a/testing/lisp/test-ob-emacs-lisp.el +++ b/testing/lisp/test-ob-emacs-lisp.el @@ -62,17 +62,20 @@ (should (string= (buffer-substring-no-properties (point-at-bol) (point-at-eol)) -(org-test-with-temp-text-in-file + +(ert-deftest ob-emacs-lisp/commented-last-block-line () + (org-test-with-temp-text-in-file #+begin_src emacs-lisp :var a=2 2;; #+end_src - (org-babel-next-src-block) - (org-ctrl-c-ctrl-c) - (re-search-forward results nil t) - (forward-line) - (should (string= - : 2 - (buffer-substring-no-properties (point-at-bol) (point-at-eol) +(org-babel-next-src-block) +(org-ctrl-c-ctrl-c) +(re-search-forward results nil t) +(forward-line) +(should (string= +: 2 +(buffer-substring-no-properties (point-at-bol) (point-at-eol)) + (provide 'test-ob-emacs-lisp) ;;; test-ob-emacs-lisp.el ends here -- 1.8.2
[O] [PATCH 06/10] Use prefix arg in org-edit-special
* lisp/org.el (org-edit-special): Use prefix arg, as docstring says we do Only makes a difference for src-block editing. --- lisp/org.el | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index 04ce386..1edfbc4 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -19943,7 +19943,7 @@ When in a fixed-width region, call `org-edit-fixed-width-region'. When at an #+INCLUDE keyword, visit the included file. On a link, call `ffap' to visit the link at point. Otherwise, return a user error. - (interactive) + (interactive P) (let ((element (org-element-at-point))) (assert (not buffer-read-only) nil Buffer is read-only: %s (buffer-name)) @@ -19958,8 +19958,9 @@ Otherwise, return a user error. ;; At a src-block with a session and function called with ;; an ARG: switch to the buffer related to the inferior ;; process. - (funcall (intern (concat org-babel-prep-session: lang)) - session params) + (switch-to-buffer + (funcall (intern (concat org-babel-prep-session: lang)) + session params)) (keyword (if (member (org-element-property :key element) '(INCLUDE SETUPFILE)) (find-file -- 1.8.2
[O] [PATCH 09/10] Remove org-babel-check-confirm-evaluate macro
* lisp/ob-core.el (org-babel-check-confirm-evaluate): remove (org-babel-check-evaluate), (org-babel-confirm-evaluate): move logic here This macro is used in only two places, and has two almost-independent complex logics coded into it. So, suppress the macro and move the logic into the respective functions. --- lisp/ob-core.el | 89 ++--- 1 file changed, 40 insertions(+), 49 deletions(-) diff --git a/lisp/ob-core.el b/lisp/ob-core.el index d8c11ee..65c5a0b 100644 --- a/lisp/ob-core.el +++ b/lisp/ob-core.el @@ -284,49 +284,26 @@ Returns a list (setf (nth 2 info) (org-babel-process-params (nth 2 info (when info (append info (list name indent) -(defvar org-current-export-file) ; dynamically bound -(defmacro org-babel-check-confirm-evaluate (info rest body) - Evaluate BODY with special execution confirmation variables set. - -Specifically; NOEVAL will indicate if evaluation is allowed, -QUERY will indicate if a user query is required, CODE-BLOCK will -hold the language of the code block, and BLOCK-NAME will hold the -name of the code block. - (declare (indent defun)) - (org-with-gensyms - (lang block-body headers name eval eval-no export eval-no-export) -`(let* ((,lang (nth 0 ,info)) - (,block-body (nth 1 ,info)) - (,headers(nth 2 ,info)) - (,name (nth 4 ,info)) - (,eval (or (cdr (assoc :eval ,headers)) -(when (assoc :noeval ,headers) no))) - (,eval-no(or (equal ,eval no) -(equal ,eval never))) - (,export (org-bound-and-true-p org-current-export-file)) - (,eval-no-export (and ,export (or (equal ,eval no-export) - (equal ,eval never-export - (noeval (or ,eval-no ,eval-no-export)) - (query (or (equal ,eval query) -(and ,export (equal ,eval query-export)) -(when (functionp org-confirm-babel-evaluate) - (funcall org-confirm-babel-evaluate - ,lang ,block-body)) -org-confirm-babel-evaluate)) - (code-block (if ,info (format %s ,lang) )) - (block-name (if ,name (format (%s) ,name) ))) - ,@body))) +;; dynamically bound during export +(defvar org-current-export-file) +;; dynamically bound during asynchronous export +(defvar org-babel-confirm-evaluate-answer-no) (defsubst org-babel-check-evaluate (info) Check if code block INFO should be evaluated. Do not query the user. - (org-babel-check-confirm-evaluate info -(not (when noeval - (message (format Evaluation of this%scode-block%sis disabled. - code-block block-name)) - - ;; dynamically scoped for asynchroneous export -(defvar org-babel-confirm-evaluate-answer-no) + (let* ((params (nth 2 info)) +(name (nth 4 info)) +(eval (cdr (assq :eval params))) + (can-eval (not (or (member eval '(never no)) + (assq :noeval params) + (and (org-bound-and-true-p org-current-export-file) +(member eval '(no-export never-export))) +(when (not can-eval) + (message (format Evaluation of this %s code-block (%s) is disabled. + (nth 0 info) + (if name (concat ( name ) ) +can-eval)) (defsubst org-babel-confirm-evaluate (info) Confirm evaluation of the code block INFO. @@ -341,16 +318,30 @@ confirmation from the user. Note disabling confirmation may result in accidental evaluation of potentially harmful code. - (org-babel-check-confirm-evaluate info -(not (when query - (unless - (and (not (org-bound-and-true-p - org-babel-confirm-evaluate-answer-no)) - (yes-or-no-p -(format Evaluate this%scode block%son your system? -code-block block-name))) -(message (format Evaluation of this%scode-block%sis aborted. - code-block block-name))) + + (let* ((params (nth 2 info)) + (name (if (nth 4 info) (concat ( (nth 4 info) ) ) )) +(eval (cdr (assq :eval params))) + (should-query (or (equal eval query) + (and (org-bound-and-true-p org-current-export-file) +(equal eval query-export)) + (and (functionp org-confirm-babel-evaluate) +(funcall org-confirm-babel-evaluate + (nth 0 info) + (nth 1 info))) +
[O] [PATCH 10/10] Document how :var introduces code block dependencies.
* doc/org.texi: Document how :var introduces code block dependencies.
---
doc/org.texi | 9 +
1 file changed, 9 insertions(+)
diff --git a/doc/org.texi b/doc/org.texi
index 6791570..dda922e 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -13211,6 +13211,15 @@ include anything in the Org mode file that takes a
@code{#+NAME:},
@code{#+BEGIN_EXAMPLE} blocks, other code blocks, and the results of other
code blocks.
+When a reference is made to another code block, the referenced block will be
+evaluated whenever needed, in order to supply its value to the referencing
+block. If the referenced block is cached (see @ref{cache}), its value will
+be reused if possible, instead of being re-calculated. If the referring code
+block is cached, its hash value will depend on the value of all the code
+blocks it references. This system can thus be used to create a system of
+as-needed re-evaluation among code blocks similar to that provided by
+@uref{http://yihui.name/knitr/, knitr} or Sweave.
+
Argument values can be indexed in a manner similar to arrays (see @ref{var,
Indexable variable values}).
--
1.8.2
[O] [PATCH] Add 'inline-only option to org-export-babel-evaluate
* lisp/ob-exp.el (org-export-babel-evaluate): Update defcustom to provide 'inline-only option (org-babel-exp-results): Implement 'inline-only for org-export-babel-evaluate This is useful because there is no way for inline results to be stored. The imagined usecase is that all non-inline source blocks will be evaluated manually by the user. Inline blocks, however, must be evaluated during export, or they will be simply deleted by the exporter. --- lisp/ob-exp.el | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el index 0d98690..6783bd5 100644 --- a/lisp/ob-exp.el +++ b/lisp/ob-exp.el @@ -52,10 +52,13 @@ (defcustom org-export-babel-evaluate t Switch controlling code evaluation during export. When set to nil no code will be evaluated as part of the export -process. +process. When set to 'inline-only, only inline code blocks will +be executed. :group 'org-babel :version 24.1 - :type 'boolean) + :type '(choice (const :tag Never nil) +(const :tag Only inline code inline-only) +(const :tag Always t))) (put 'org-export-babel-evaluate 'safe-local-variable (lambda (x) (eq x nil))) (defun org-babel-exp-get-export-buffer () @@ -378,7 +381,9 @@ Results are prepared in a manner suitable for export by org-mode. This function is called by `org-babel-exp-do-export'. The code block will be evaluated. Optional argument SILENT can be used to inhibit insertion of results into the buffer. - (when (and org-export-babel-evaluate + (when (and (or (eq org-export-babel-evaluate t) +(and (eq type 'inline) + (eq org-export-babel-evaluate 'inline-only))) (not (and hash (equal hash (org-babel-current-result-hash) (let ((lang (nth 0 info)) (body (if (org-babel-noweb-p (nth 2 info) :eval) -- 1.8.2
