Re: [O] evaluation context in call statements
Eric Schulte writes: In defense of the existing behavior, I don't see the benefit of calling a code block with the same arguments from multiple locations and subsequently littering a file with multiple identical results blocks. I agree that this didn't make all that much sense in the past, but with property evaluation and elisp argument evaluation now anchored to the point of call, the hierarchical position of the call could and (as the test case from Rick) will be used to distinguish between invocations with the same arguments. Since the current way to find the results doesn't know anything about this, it will generally not do the right thing anymore. Note that calls using a session had that property all the time: multiple calls with the same arguments into the same session are useful, but Babel would only keep the last result. If we do want to change this behavior it would be nice to check the email list archives to see if/when the existing behavior has been defended in the past. If you'd happen to know when that was introduced? My only thought about a :target header argument is that it would need to be implemented for other types of code blocks as well, which could lead to very confusing behavior if we have a named code block with a :target header argument which differs from the name. Oh yes, the specification of that would be interesting. I'll try to see how this beam the result anywhere functionality sprang into existence and what the intended use case was (I expect something to do with sessions). My current suggestion is however to limit the results block search to the same subtree and stop searching at later #+CALL and #+BEGIN_SRC line. We could make this conditional on a :[no]clobber argument to keep compatibility with the current behaviour (clobbering the first result would be the current and perhaps default behaviour). Also, if the target is referenced, would the #+call line be re-run? Not any more that a reference to a named result would re-run its source block. My vote is for adding #+name support to call lines, and then handling their results in the same manner as code block results. I'm not sure what this would entail other than replacing the call with its arguments with the name of the call in the results line. But yes, that'd be a step forward, although you'd have to be careful when copying calls. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
[O] Extra list bullets / portable configuration?
Hello! With the input-method TeX it is easy to insert more graphical Unicode characters such as • (\bullet). Some questions about that: 1. Is it possible to make org-mode use • as a bullet character for lists? 2. Is it possible to make another persons org-mode installation aware of this when viewing my document? Question 1. is mostly a curiousity thing, but question 2. would be good to know for pretty much any customization. Including viewing my own files a year later when my configuration has largely changed. kind regards, Klaus
Re: [O] evaluation context in call statements
Hi Eric On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte schulte.e...@gmail.com wrote: I think we could be well served by discussing how people use call lines, how they would use call lines (if this behavior changed), and what behavior would best support these existing and potential use cases. You did not yet answer to what I asked you about more than one call with the same arguments: http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547 In defense of the existing behavior, I don't see the benefit of calling a code block with the same arguments from multiple locations and subsequently littering a file with multiple identical results blocks. Such result blocks do not have to be necessarily identical. What would you suggest for these examples?: 1) It could be just me feeling like to be on the playground: --- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp (format %s org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #marker at 124 in tmp.org #+CALL: i_am_curious_how_this_works() (Here I expect to see the result #marker at 235 in tmp.org.) --- 2) My use case mentioned at the beginning of this message. Michael
Re: [O] Open Document Exporter
Hello, Georg Lehner jorge-...@magma.com.ni writes: In LaTeX export I have the following behaviour: [[*Headline][Headline]] converts to a Hyperlink to the respective headline with description text 'Headline'. [[*Headline]] converts to the respective headline number In ODT export both convert to the headline number. Fixed. The following patch disables smart-quotes when required so by a ':nil option. The (when ... clause was missing from the original code. Fixed. 6. Table caption does not translate I have expanded the 'org-export-dictionary' constant with german (and spanisch) translations of all keywords. Added. However my table captions still show the englisch Table prefix. With Figures (alias 'Illustrations' in ODT) things work fine. This is not fixed yet. Currently, the way ODT exporter handles translations is incompatible with `org-export-dictionary'. I'll have a look at it. Thank you for the report and the patches. Regards, -- Nicolas Goaziou
Re: [O] Starting emacs followed directly by org-agenda search and visiting file removes color formatting
Nicolas Richard theonewiththeevill...@yahoo.fr writes: I just noticed this thread, which i think reports exactly the issue I reported here [this thread was before, but the title didn't catch my eyes -- sorry about that] 87zjuv2r79@yahoo.fr and more or less fixed here 87bo7ati0m@yahoo.fr (not sent as a patch because I'm unsure about it) s/patch/commit/ Let me make that a commit anyway -- I've had no problem with it since I applied it to my tree and maybe it's easier for you to review. HTH : From e7e9946235df776cf9b8998ff80116d06597668e Mon Sep 17 00:00:00 2001 From: Nicolas Richard theonewiththeevill...@yahoo.fr Date: Fri, 21 Jun 2013 10:23:43 +0200 Subject: [PATCH] Move (org-set-font-lock-defaults) from (org-set-regexps-and-options) to (org-mode) * lisp/org.el (org-set-regexps-and-options): don't set font-lock defaults here. (org-mode): set them here. This fixes the bug mentionned in [[gnus:nntp+news.gmane.org:gmane.emacs.orgmode#87zjuv2r79@yahoo.fr]] --- lisp/org.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index f55c53e..7fd1576 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -5146,8 +5146,7 @@ Support for group tags is controlled by the option (mapcar (lambda (w) (substring w 0 -1)) (list org-scheduled-string org-deadline-string org-clock-string org-closed-string))) - (org-compute-latex-and-related-regexp) - (org-set-font-lock-defaults + (org-compute-latex-and-related-regexp (defun org-file-contents (file optional noerror) Return the contents of FILE, as a string. @@ -5331,6 +5330,7 @@ The following commands are available: (setq buffer-display-table org-display-table)) (org-set-regexps-and-options-for-tags) (org-set-regexps-and-options) + (org-set-font-lock-defaults) (when (and org-tag-faces (not org-tags-special-faces-re)) ;; tag faces set outside customize force initialization. (org-set-tag-faces 'org-tag-faces org-tag-faces)) -- 1.8.1.5
Re: [O] Extra list bullets / portable configuration?
Hi, With the input-method TeX it is easy to insert more graphical Unicode characters such as • (\bullet). Some questions about that: 1. Is it possible to make org-mode use • as a bullet character for lists? 2. Is it possible to make another persons org-mode installation aware of this when viewing my document? Perhaps org-bullets may be used for this. It works for headlines, and I guess you could extend it to bullets. This is the correct way to go about it, as changing Org-syntax 'locally' is (generally) not going to happen. https://github.com/sabof/org-bullets –Rasmus -- Hvor meget poesi tror De kommer ud af et glas isvand?
Re: [O] Help with beamer environments + org-special-blocks!
Hi Vikas,
Vikas Rawal wrote:
I am trying to use textpos to position images at specific location on
a frame.
I now use TikZ to do that. I have the impression it is easier. Though, I have
the real impression of writing LaTeX inside an Org buffer... which I dislike.
I'd like to write text as text, and still get the ability to convert that to
HTML, for review, even if the layout wouldn't be (at all) the same.
I would like something like this in the beamer export:
\begin{textblock}{10}(3,3) \visible 2- {
\includegraphics[width=.9\linewidth]{scatterplot2.png}
} \end{textblock}
I have defined the following beamer environment.
(add-to-list 'org-beamer-environments-extra
'(textpos1 w \\begin{textblock}{%h}(3,3) \\visible %a { }
\\end{textblock}))
You normally could use such a block (the old org-special-blocks, now
integrated in Org 8 -- thanks Nicolas):
--8---cut here---start-8---
#+begin_textblock
Contents
#+end_textblock
--8---cut here---end---8---
The problem is (3,3) is fixed in the above specification. How can I
specify it for a given headline? I have tried various ways of
generalising this but nothing seems to work.
For example, if I use the following:
(add-to-list 'org-beamer-environments-extra
'(textpos1 w \\begin{textblock}%h \\visible %a { }
\\end{textblock}))
and write the headline as {10}(3,3), I get \{10\}(3,3) in beamer
export rather than {10}(3,3).
Though, the problem stays the same with what I think is the right way to do
it...
See how Org gets converted to LaTeX:
--8---cut here---start-8---
#+begin_myenvironment \begin{myenvironment}
Test of a new Test of a new
environment.environment.
#+end_myenvironment \end{myenvironment}
--8---cut here---end---8---
That's OK. But the environment had no parameters.
--8---cut here---start-8---
#+begin_myenvironment{3}\#+begin\_myenvironment\{3\}
Test of a new Test of a new
environment.environment.
#+end_myenvironment \#+end\_myenvironment
--8---cut here---end---8---
That's completely invalid LaTeX.
--8---cut here---start-8---
#+begin_myenvironment {3} \begin{myenvironment}
Test of a new Test of a new
environment.environment.
#+end_myenvironment \end{myenvironment}
--8---cut here---end---8---
That's valid LaTeX, but the arguments of the environment have been ignored!
IIRC, that's how we did before, with the original `org-special-blocks' file.
How does one use the escape %o? I have looked through ox-beamer.el,
worg and mailing list archives, but could not find a clear
explanation. Will be grateful for a pointer.
I've no idea. I wonder as well how we do this.
Best regards,
Seb
--
Sebastien Vauban
Re: [O] Help with beamer environments + org-special-blocks!
Hello,
Sebastien Vauban sva-news-D0wtAvR13HarG/idocf...@public.gmane.org
writes:
Vikas Rawal wrote:
For example, if I use the following:
(add-to-list 'org-beamer-environments-extra
'(textpos1 w \\begin{textblock}%h \\visible %a { }
\\end{textblock}))
and write the headline as {10}(3,3), I get \{10\}(3,3) in beamer
export rather than {10}(3,3).
I think we should changes some environment placeholders:
+ Introduce %r which would stand for the raw headline (without any
processing)
+ %H and %U would use the raw headline text instead.
The previous definition would become:
'(textpos1 w \\begin{textblock}%r \\visible %a { } \\end{textblock})
WDYT?
#+begin_myenvironment{3}\#+begin\_myenvironment\{3\}
Test of a new Test of a new
environment.environment.
#+end_myenvironment \#+end\_myenvironment
This should work with a recent Org.
There is also:
#+attr_latex: :options {3}
#+begin_myenvironment
Test of a new
environment
#+end_myenvironment
Regards,
--
Nicolas Goaziou
Re: [O] evaluation context in call statements
On 2013-06-26 02:29, Achim Gratz wrote: Eric Schulte writes: In defense of the existing behavior, I don't see the benefit of calling a code block with the same arguments from multiple locations and subsequently littering a file with multiple identical results blocks. I agree that this didn't make all that much sense in the past, but with property evaluation and elisp argument evaluation now anchored to the point of call, the hierarchical position of the call could and (as the test case from Rick) will be used to distinguish between invocations with the same arguments. Since the current way to find the results doesn't know anything about this, it will generally not do the right thing anymore. Note that calls using a session had that property all the time: multiple calls with the same arguments into the same session are useful, but Babel would only keep the last result. Agreed. The only way to know that the arguments are the same is to evaluated them :). My only thought about a :target header argument is that it would need to be implemented for other types of code blocks as well, which could lead to very confusing behavior if we have a named code block with a :target header argument which differs from the name. Oh yes, the specification of that would be interesting. I'll try to see how this beam the result anywhere functionality sprang into existence and what the intended use case was (I expect something to do with sessions). I believe the ability to replace named results anywhere was added by Nicolas in commit 2f2a80fe (quick look at ob-core w/ vc-annotate). My current suggestion is however to limit the results block search to the same subtree and stop searching at later #+CALL and #+BEGIN_SRC line. We could make this conditional on a :[no]clobber argument to keep compatibility with the current behaviour (clobbering the first result would be the current and perhaps default behaviour). These search bounds make sense, but i think this should be the default behavior. I don't see the current behavior as making sense---at least to me. At the time (late 2012) I found Nicolases changes (named results blocks, attributes and captions on the results block and not the source, etc) confusing. I still find it odd that you need to evaluate a source block before you can e.g, add a caption or attributes to the results (previous behavior was that header arguments on the source block were used for the results in exporting.) Also, i think a new value for :replace (original?) would make more sense than a new :clobber option. My vote is for adding #+name support to call lines, and then handling their results in the same manner as code block results. I'm not sure what this would entail other than replacing the call with its arguments with the name of the call in the results line. But yes, that'd be a step forward, although you'd have to be careful when copying calls. It seems inconsistent to add #+name support to call lines but not the other block modifiers (#+header :var ..., etc). I think call lines are a special case, so would be ok with the new :target option. rick
Re: [O] evaluation context in call statements
My vote is for adding #+name support to call lines, and then handling their results in the same manner as code block results. Achim Gratz strom...@nexgo.de writes: I'm not sure what this would entail other than replacing the call with its arguments with the name of the call in the results line. But yes, that'd be a step forward, although you'd have to be careful when copying calls. This could work exactly as named source blocks work. E.g., Unnamed code block. #+begin_src emacs-lisp 'bar #+end_src #+RESULTS: : bar Named code block. #+name: foo-block #+begin_src emacs-lisp 'foo #+end_src can have text between itself and its results #+RESULTS: foo-block : foo Unnamed call line. #+call: foo-block() #+RESULTS: foo-block() : foo Named call line. #+name: foo-call #+call: foo-block() Can have text between itself and its results. #+RESULTS: foo-call : foo Rick Frankel r...@rickster.com writes: It seems inconsistent to add #+name support to call lines but not the other block modifiers (#+header :var ..., etc). I think call lines are a special case, so would be ok with the new :target option. See above. This is not inconsistent, it is equivalent with how names and code block already work, which means it is less for new users to learn and old users to keep track of. Also, the existing code block results handling has not caused much confusion, and seems to be powerful enough to deal with every use case. Achim Gratz strom...@nexgo.de and Rick Frankel r...@rickster.com write: My current suggestion is however to limit the results block search to the same subtree and stop searching at later #+CALL and #+BEGIN_SRC line. We could make this conditional on a :[no]clobber argument to keep compatibility with the current behaviour (clobbering the first result would be the current and perhaps default behaviour). These search bounds make sense, but i think this should be the default behavior. I don't see the current behavior as making sense---at least to me. I agree that the current behavior is confusing, but I don't like this suggestion. I expect people will be mystified when calls replace results in the same subtree and don't replace blocks elsewhere in the same Org-mode file. No other parts of Org-mode's code block support work this way. At the time (late 2012) I found Nicolases changes (named results blocks, attributes and captions on the results block and not the source, etc) confusing. I still find it odd that you need to evaluate a source block before you can e.g, add a caption or attributes to the results (previous behavior was that header arguments on the source block were used for the results in exporting.) I think this behavior works well and I don't think it will change. I see how it could be nice to automatically apply attributes (e.g., captions, labels etc...) of a code block to that blocks results, but then what if I want to export the code block body and not the results, what if I want to export both. I think Nicolas was right to unify, simplify and clarify the Org-mode attribute semantics. Thanks for the feedback. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] evaluation context in call statements
Michael Brand michael.ch.br...@gmail.com writes: Hi Eric On Wed, Jun 26, 2013 at 12:41 AM, Eric Schulte schulte.e...@gmail.com wrote: I think we could be well served by discussing how people use call lines, how they would use call lines (if this behavior changed), and what behavior would best support these existing and potential use cases. You did not yet answer to what I asked you about more than one call with the same arguments: http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547 They will overwrite eachother's results. We are currently discussing alternatives which would change this behavior. In defense of the existing behavior, I don't see the benefit of calling a code block with the same arguments from multiple locations and subsequently littering a file with multiple identical results blocks. Such result blocks do not have to be necessarily identical. What would you suggest for these examples?: 1) It could be just me feeling like to be on the playground: --- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp (format %s org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #marker at 124 in tmp.org #+CALL: i_am_curious_how_this_works() (Here I expect to see the result #marker at 235 in tmp.org.) --- This works as expected. Depending on the call line executed, I get different points in the second results. 2) My use case mentioned at the beginning of this message. Currently if you want have separate results for call lines with the same variables you will need to use a dummy variable. I'd suggest an OS variable if you are running them on different operating systems. Michael -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] evaluation context in call statements
Hello, Rick Frankel r...@rickster.com writes: At the time (late 2012) I found Nicolases changes (named results blocks, attributes and captions on the results block and not the source, etc) confusing. I still find it odd that you need to evaluate a source block before you can e.g, add a caption or attributes to the results (previous behavior was that header arguments on the source block were used for the results in exporting.) But you couldn't provide different captions (or attributes) to source code and results (or no caption/attribute to one of them only). If you think about it, it's not very odd that captions and attributes apply to the text located just below, instead of some remote or yet to be generated piece of text. Regards, -- Nicolas Goaziou
[O] Process diagrams with dot and some glue using Org-mode
Hi!
I was looking for a reasonable simple method to define processes and
work-flows within Org-mode. My research did not result in anything
existing I found useful. Therefore, I started to read about dot[1]
and found [2].
I would like to define my diagram with the following two tables: one
for the node definitions and one for the interconnections between
notes. The syntax should be pretty self-explanatory (or at least I
hope so):
#+name: foobar-node-table
| *node* | *label*| *shape* | *fillcolor* |
|++-+-|
| S_start| start | ellipse | green |
| S_fill | fill form | | |
| S_send | send form | | |
| S_complete | form complete? | diamond | yellow |
| S_do | do task| | red |
| S_end | end| ellipse | |
#+name: foobar-graph-table
|| S_start | S_fill | S_send | S_complete | S_do | S_end |
| S_start| | - ||| | |
| S_fill | || || | |
| S_send | ||| | | |
| S_complete | | N ||| Y | |
| S_do | |||| | |
| S_end | |||| | |
Some (still missing) glue should use these two tables and
automatically generate the dot script:
#+BEGIN_SRC dot :file ~/test-dot.png :exports results
digraph {
//rankdir=LR;
S_start [label =start, shape = ellipse, style=filled,
fillcolor=green];
S_fill [label =fill form, shape = box];
S_send [label =send form, shape = box];
S_complete [label =form complete?, shape = diamond, style=filled,
fillcolor=yellow];
S_do [label =do task, shape = box, style=filled, fillcolor=red];
S_end [label =end, shape = ellipse];
S_start -- S_fill;
S_fill - S_send;
S_send - S_complete;
S_complete - S_do [taillabel = Y];
S_do - S_end;
S_complete - S_fill [taillabel = N];
}
#+END_SRC
The question is: is somebody with decent ELISP knowledge able to
implement the missing method? :-)
I (not an ELISP hacker) would have to use Python and write a table
parsing class which will get too complicated for my taste :-(
However, my guess is that this could be implemented in ELISP with
much less effort.
I would be happy to document this method and provide it on Worg. In
my opinion, this would be very handy for many Org-mode users.
Thanks!
1. https://en.wikipedia.org/wiki/DOT_language
2. http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-dot.html
--
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
get Memacs from https://github.com/novoid/Memacs
https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] evaluation context in call statements
Nicolas- On 2013-06-26 11:13, Nicolas Goaziou wrote: Rick Frankel r...@rickster.com writes: At the time (late 2012) I found Nicolases changes (named results blocks, attributes and captions on the results block and not the source, etc) confusing. I still find it odd that you need to evaluate a source block before you can e.g, add a caption or attributes to the results (previous behavior was that header arguments on the source block were used for the results in exporting.) But you couldn't provide different captions (or attributes) to source code and results (or no caption/attribute to one of them only). If you think about it, it's not very odd that captions and attributes apply to the text located just below, instead of some remote or yet to be generated piece of text. I agree now (as i did then), with the functionality and understand why and how it works, but i still find having to execute a source block before being able to attribute the results counter-intuitive (as have others). It's kind of like having to wait for the house to be built before you can decide/buy the paint to finish it: ) But I also, don't see any better way to provide the useful functionality of being able to attribute the code block and results separately --- although in my normal use cases, i don't usually export both code and results together. rick
Re: [O] Process diagrams with dot and some glue using Org-mode
Sorry, minor mistake: I could not find out why dot is not able to
mix directed and not directed graphs in one diagram. Therefore I had
to replace th - in the node table with and the corresponding
results as well:
#+name: foobar-node-table
| *node* | *label*| *shape* | *fillcolor* |
|++-+-|
| S_start| start | ellipse | green |
| S_fill | fill form | | |
| S_send | send form | | |
| S_complete | form complete? | diamond | yellow |
| S_do | do task| | red |
| S_end | end| ellipse | |
#+name: foobar-graph-table
|| S_start | S_fill | S_send | S_complete | S_do | S_end |
| S_start| | ||| | |
| S_fill | || || | |
| S_send | ||| | | |
| S_complete | | N ||| Y | |
| S_do | |||| | |
| S_end | |||| | |
#+BEGIN_SRC dot :file ~/test-dot.png :exports results
digraph {
//rankdir=LR;
S_start [label =start, shape = ellipse, style=filled,
fillcolor=green];
S_fill [label =fill form, shape = box];
S_send [label =send form, shape = box];
S_complete [label =form complete?, shape = diamond, style=filled,
fillcolor=yellow];
S_do [label =do task, shape = box, style=filled, fillcolor=red];
S_end [label =end, shape = ellipse];
S_start - S_fill;
S_fill - S_send;
S_send - S_complete;
S_complete - S_do [taillabel = Y];
S_do - S_end;
S_complete - S_fill [taillabel = N];
}
#+END_SRC
This results in a diagram as shown in: http://qr.cx/wEFr
--
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
get Memacs from https://github.com/novoid/Memacs
https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] Process diagrams with dot and some glue using Org-mode
On 2013-06-26 11:23, Karl Voit wrote: Hi! I would like to define my diagram with the following two tables: one for the node definitions and one for the interconnections between notes. The syntax should be pretty self-explanatory (or at least I hope so): I (not an ELISP hacker) would have to use Python and write a table parsing class which will get too complicated for my taste :-( However, my guess is that this could be implemented in ELISP with much less effort. Two things: 1. You don't need to write table parsing code, as passing in a table as an argument to a code block will convert it to an array. For example: #+name: ptable | head1 | head2 | |---+---| | a | 1 | | b | 2 | #+BEGIN_SRC python :var t=ptable :results value return t #+END_SRC #+RESULTS: | a | 1 | | b | 2 | and the python code generated (view w/ `org-babel-expand-src-block'): t=[[a, 1], [b, 2]] return t 2. You can also use the pydot or pygraphviz libraries for generating the graph directly from python instead of generating dot code. rick
Re: [O] evaluation context in call statements
Rick Frankel r...@rickster.com writes: Nicolas- On 2013-06-26 11:13, Nicolas Goaziou wrote: Rick Frankel r...@rickster.com writes: At the time (late 2012) I found Nicolases changes (named results blocks, attributes and captions on the results block and not the source, etc) confusing. I still find it odd that you need to evaluate a source block before you can e.g, add a caption or attributes to the results (previous behavior was that header arguments on the source block were used for the results in exporting.) But you couldn't provide different captions (or attributes) to source code and results (or no caption/attribute to one of them only). If you think about it, it's not very odd that captions and attributes apply to the text located just below, instead of some remote or yet to be generated piece of text. I agree now (as i did then), with the functionality and understand why and how it works, but i still find having to execute a source block before being able to attribute the results counter-intuitive (as have others). You are free to type a #+RESULTS: line manually. If you use yasnippets you could define a snippet for a named code block which inserts the #+RESULTS line concurrently with the code block. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Process diagrams with dot and some glue using Org-mode
Karl Voit devn...@karl-voit.at writes: Hi, I was looking for a reasonable simple method to define processes and work-flows within Org-mode. My research did not result in anything existing I found useful. Therefore, I started to read about dot[1] and found [2]. [...] Some (still missing) glue should use these two tables and automatically generate the dot script: [...] The question is: is somebody with decent ELISP knowledge able to implement the missing method? :-) not really an answer to your question, but I wrote a library (picodoc.el) that automatically generates PlantUML scripts from PicoLisp source code: ,--- | https://github.com/tj64/picodoc/blob/master/picodoc.el `--- maybe you can take some inspiration there. Instead of parsing a source file you would need to process nested lists after applying ,- | org-table-to-lisp is an autoloaded compiled Lisp function in `org-table.el'. | | (org-table-to-lisp optional TXT) | | Convert the table at point to a Lisp structure. | The structure will be a list. Each item is either the symbol `hline' | for a horizontal separator line, or a list of field values as strings. | The table is taken from the parameter TXT, or from the buffer at point. `- to your tables. -- cheers, Thorsten
Re: [O] evaluation context in call statements
Hi Eric On Wed, Jun 26, 2013 at 4:54 PM, Eric Schulte schulte.e...@gmail.com wrote: http://thread.gmane.org/gmane.emacs.orgmode/72513/focus=73547 They will overwrite eachother's results. I do not understand. In order to avoid that they will overwrite eachother's results I added `dummy_name=osx' and `dummy_name=gnu' to the call arguments. What did you mean? We are currently discussing alternatives which would change this behavior. My suggestions to this discussion have been two alternatives that already work now and that I already used, see my use case unicode_normal_form_c and my patch with the ERT in the other thread mentioned above: 1) use :session where supported like for emacs-lisp source blocks 2) use :var dummy_name as a workaround where :session is not supported like for shell source blocks --- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp (format %s org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #marker at 124 in tmp.org #+CALL: i_am_curious_how_this_works() (Here I expect to see the result #marker at 235 in tmp.org.) --- This works as expected. Depending on the call line executed, I get different points in the second results. I am sorry, I wanted to say that I want to do something like (note: not current behavior) --- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp (format %s org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #marker at 124 in tmp.org #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #marker at 236 in tmp.org --- and would like the yet to be defined solution in discussion here to make also this possible, together with the appropriate change if necessary to the example given above. Currently working alternative with the change to use :session: --- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp (format %s org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works[:session upper]() #+RESULTS: i_am_curious_how_this_works[:session upper]() : #marker at 124 in tmp.org #+CALL: i_am_curious_how_this_works[:session lower]() #+RESULTS: i_am_curious_how_this_works[:session lower]() : #marker at 267 in tmp.org --- Currently working alternative with the change to use :var dummy_name: --- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp :var dummy_name= (format %s org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works(dummy_name=upper) #+RESULTS: i_am_curious_how_this_works(dummy_name=upper) : #marker at 143 in tmp.org #+CALL: i_am_curious_how_this_works(dummy_name=lower) #+RESULTS: i_am_curious_how_this_works(dummy_name=lower) : #marker at 290 in tmp.org --- Currently if you want have separate results for call lines with the same variables you will need to use a dummy variable. Ok, this answers one of my questions in the other thread and confirms my expectation. Does it mean that my patch with the ERT as of 2013-06-19 from the other thread is ok for now and can be applied just to reflect what is currently supported? Or should I change something else in the patch? Michael
Re: [O] Process diagrams with dot and some glue using Org-mode
* Rick Frankel r...@rickster.com wrote: Two things: 1. You don't need to write table parsing code, as passing in a table as an argument to a code block will convert it to an array. #+name: ptable | head1 | head2 | |---+---| | a | 1 | | b | 2 | [...] #+RESULTS: | a | 1 | | b | 2 | [...] t=[[a, 1], [b, 2]] You're right, I totally forgot about this neat feature. However, the header information seems to get lost. This requires hard-coded column content which is a minor drawback of this method. 2. You can also use the pydot or pygraphviz libraries for generating the graph directly from python instead of generating dot code. Thanks for the pointer! If somebody else is looking for an example (or some less formal documentation), take a look at [1] which gave me a much better start-up than the pydot web page. 1. https://pythonhaven.wordpress.com/tag/pydot/ -- mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode: get Memacs from https://github.com/novoid/Memacs https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on github
Re: [O] evaluation context in call statements
I am sorry, I wanted to say that I want to do something like (note: not current behavior) --- #+NAME: i_am_curious_how_this_works #+BEGIN_SRC emacs-lisp (format %s org-babel-current-src-block-location) #+END_SRC #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #marker at 124 in tmp.org #+CALL: i_am_curious_how_this_works() #+RESULTS: i_am_curious_how_this_works() : #marker at 236 in tmp.org --- and would like the yet to be defined solution in discussion here to make also this possible, If we do add #+names to call lines, and have them adopt the existing code block result behavior, then the above will work without modification. [...] Currently if you want have separate results for call lines with the same variables you will need to use a dummy variable. Ok, this answers one of my questions in the other thread and confirms my expectation. Does it mean that my patch with the ERT as of 2013-06-19 from the other thread is ok for now and can be applied just to reflect what is currently supported? Or should I change something else in the patch? Yes, I've just applied this patch. Sorry for the delay. Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Process diagrams with dot and some glue using Org-mode
Hi Karl,
Karl Voit devn...@karl-voit.at writes:
I was looking for a reasonable simple method to define processes and
work-flows within Org-mode. My research did not result in anything
existing I found useful. Therefore, I started to read about dot[1]
and found [2].
I would like to define my diagram with the following two tables: one
for the node definitions and one for the interconnections between
notes. The syntax should be pretty self-explanatory (or at least I
hope so):
[...]
The question is: is somebody with decent ELISP knowledge able to
implement the missing method? :-)
I did something simple for generating graphs but without an adjacency
type of matrix as you have defined and without the special types of
edges. So, quite limited with respect to what you want. In any case,
I've attached what I played with a while ago in the hope that maybe some
of it proves useful. What I did taxed my abilities in emacs lisp so I
won't be able to help much in adapting it to what you want...
eric
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.3-193-g334581
* preamble
#+TITLE: businessprocess.org
#+AUTHOR:Eric S Fraga
#+EMAIL: e.fr...@ucl.ac.uk
#+DATE: 2010-11-15 Mon
#+DESCRIPTION: cf.
#+KEYWORDS:
#+LANGUAGE: en
#+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t :t
#+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
#+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js
#+EXPORT_SELECT_TAGS: export
#+EXPORT_EXCLUDE_TAGS: noexport
#+LINK_UP:
#+LINK_HOME:
#+XSLT:
* The problem
Look at [[gnus:nnmaildir%2BUCL:lists#87bp5sacnf@bunting.net.au][this email]].
* the table
#+tblname: processtable
| Step| Description | Next Steps | |
|-+-+-+---|
| Begin | Begin the process | Choice1 | |
| Choice1 | Decide if we are big or small. | Big | Small |
| Big | If we are big then do big things| End | |
| Small | If we are small then figure out if we are really small or possibly big. | ReallySmall | Big |
| ReallySmall | Yes we are really small | End | |
| End | The end.| | |
|-+-+-+---|
* the elisp code
#+source: esf/business-process
#+begin_src emacs-lisp :results value raw :exports results
(defun esf/generate-business-process-graph (table name file)
(let ((entries (nthcdr 2 table))
(output (format digraph %s { name))
)
(message Initial: %s\n table)
(message Entries: %s\n entries)
;; we need to do two iterations through the table, one to define
;; the nodes and then one to connect them.
(setq savedentries entries) ;for second iteration
(while entries
(let ((entry (first entries)))
(if (listp entry)
(let ((step (first entry))
(description (nth 1 entry)) )
(setq output (format %s\n %s [label=\%s\]; output step description))
)
)
(setq entries (cdr entries))
)
)
(setq entries savedentries)
(while entries
(let ((entry (first entries)))
(if (listp entry)
(let ((from (first entry))
(nextsteps (cdr (cdr entry))) )
(message Nextsteps: %s\n nextsteps)
(while nextsteps
(let ((to (first nextsteps)))
(if to
(if (not (string= to ))
(setq output (format %s\n %s - %s; output from to
(setq nextsteps (cdr nextsteps))
)
)
)
)
(setq entries (cdr entries))
)
) ; end while entries left
(format #+begin_src dot :results file :file %s :exports results
%s
}
,#+end_src\n file output)
)
)
(esf/generate-business-process-graph table name file)
#+end_src
* the graph
#+call: esf/business-process(table=processtable, file=business.pdf, name=process) :results value raw
#+results: esf/business-process(table=processtable, file=business.pdf, name=process)
#+begin_src dot :results file :file business.pdf :exports results
digraph process {
Begin [label=Begin the process];
Choice1 [label=Decide if we are big or small.];
Big [label=If we are big then do big things];
Small [label=If we are small then figure out if we are really small or possibly big.];
ReallySmall [label=Yes we are really small];
End [label=The end.];
Begin - Choice1;
Choice1 - Big;
Choice1 - Small;
Big - End;
Small - ReallySmall;
Small - Big;
ReallySmall - End;
}
#+end_src
#+results:
[[file:business.pdf]]
Re: [O] Process diagrams with dot and some glue using Org-mode
On 2013-06-26 13:03, Karl Voit wrote:
* Rick Frankel r...@rickster.com wrote:
Two things:
1. You don't need to write table parsing code, as passing in a
table as an argument to a code block will convert it to an
array.
t=[[a, 1], [b, 2]]
You're right, I totally forgot about this neat feature.
However, the header information seems to get lost. This requires
hard-coded column content which is a minor drawback of this method.
Just use `:colnames no':
#+BEGIN_SRC python :var t=ptable :results value :colnames no
return t
#+END_SRC
t=[[head1, head2], [a, 1], [b, 2]]
return t
Regardless, here's a hack which does what you want. Note to things:
- it executes the dot code directly and uses the :file
header argument for output, because you need the
colnames of the graph table but not of the node table.
- It requires you to specify the range on the node table
#+HEADER: :var nodes=foobar-node-table[2:-1]
#+HEADER: :var graph=foobar-graph-table
#+BEGIN_SRC emacs-lisp :results file :file ./t.png
(org-babel-execute:dot
(concat
digraph {
(mapconcat
(lambda (x)
(format %s [label=\%s\ shape=%s fillcolor=%s]
(car x) (nth 1 x)
(if (string= (nth 2 x)) box (nth 2 x))
(if (string= (nth 3 x)) none (nth 3 x nodes
\n)
\n
(let* ((to-nodes (car graph)) (len (length to-nodes)))
(mapconcat
(lambda (x)
(let ((name (car x)))
(mapconcat
'identity
(loop with result = '()
for i from 1 to len
do
(when ( (length (nth i x)) 0)
(add-to-list 'result
(format %s - %s
[label=\%s\]\n
name
(nth i to-nodes)
(substring (nth i x) 0 -1
finally
return result) \n))) (cdr graph)
))
}) params)
#+END_SRC
And here's a simplier version which uses a graph table in the
following format:
#+name: foobar-graph
| from | to | label |
|++---|
| S_start| S_fill | |
| S_fill | S_send | |
| S_send | S_complete | |
| S_complete | S_fill | N |
| S_complete | S_do | Y |
| S_do | S_end | |
#+HEADER: :var nodes=foobar-node-table graph=foobar-graph
#+BEGIN_SRC emacs-lisp :file ./t2.png :colnames yes
(org-babel-execute:dot
(concat
digraph {\n
(mapconcat
(lambda (x)
(format %s [label=\%s\ shape=%s fillcolor=%s]
(car x) (nth 1 x)
(if (string= (nth 2 x)) box (nth 2 x))
(if (string= (nth 3 x)) none (nth 3 x nodes
\n)
\n
(mapconcat
(lambda (x)
(format %s - %s [taillabel=\%s\]
(car x) (nth 1 x) (nth 2 x))) graph \n)
}\n) params)
#+END_SRC
[O] Oversized inline math mode leading to corrupted HTML output (OLD exporter)
Hi, I am using the *old* exporter (the packaged version in Debian Wheezy), I don't know if this behaviour keeps happening with the new one. I have come up with a minimal case that exhibits this problem — Might be my fault for using this feature wrongly, but it *feels* as a parser error. The problem happens only when outputting HTML, using «OPTIONS: LaTeX:dvipng» in my document preamble, and in a list context. The full test document is: / | #+TITLE: Testing inline math within lists for HTML exporter | #+OPTIONS: LaTeX:dvipng | #+INFOJS_OPT: tdepth:2 sdepth:2 ftoc:nil ltoc:nil | #+LINK_UP: index.html | #+LINK_HOME: index.html | #+STYLE: link rel=stylesheet type=text/css href=css/sistop.css / | | * Foo | - Foo bar baz $(100-3 + 128) \times 4KB = 900KB$ bar foo foo baz bar | baz bar bar baz. Foo baz. | - Quux foo bar bar foo a $(100-3 + 128 + (128 \times 128) ) \times 4KB | = 66436KB$, bar foo quux bar foo baz baz. | - Foo bar. Bar baz foo foo baz bar $(100-3 + 128 + (128 \times 128) + | (128 \times 128 \times 128) ) \times 2KB = 8455044 \approx 8GB$, foo | foo bar baz. \ What happens here? I think the parser fails to see where the math mode ends. The LaTeX snippet is generated correctly (that is, the image in ltxpng/ is generated correctly, but the output to the alt attribute of the img tag is cut at the first newline. I'm pasting here just the generated ul: / | ul | liFoo bar baz img src=ltxpng/test_f3cfc88d233452ff173621df43ec8460f406305a.png alt=$(100-3 + 128) \times 4KB = 900KB$/ bar foo foo baz bar | baz bar bar baz. Foo baz. | /li | liQuux foo bar bar foo a img src=ltxpng/test_75d5a4164cf14c1532c7111fb0ae8a88e1c5a9c9.png alt=$(100-3 + 128 + (128 \times 128) ) \times 4KB | /li | liFoo bar. Bar baz foo foo baz bar img src=ltxpng/test_2497b2e44469a088aef26cf377e3ed761fe649f0.png alt=$(100-3 + 128 + (128 \times 128) + | foo bar baz. | /li | /ul \ Now, it gets more interesting: If this list is succeeded by a heading that appears on the TOC (that is, level one or level two), there is an interaction I cannot explain with infojs, and the whole document is displayed blank in the browser. So, is there a recommendation there I am missing? Is this bug still present in the new exporter? Are there maintenance releases still expected for the old exporter that could address/fix this? Note that the document renders correctly under LaTeX. Thanks a lot!
Re: [O] feature request (rather off-topic)
Hi François Your post with the first-hand background about Lilypond is a very interesting read for me, thank you. On Wed, Jun 26, 2013 at 5:13 AM, François Pinard pin...@iro.umontreal.ca wrote: but really, this is of no interest nowadays. In my opinion, Lilypond is immensely more appealing! Agreed. I did not mention that to be productive I would certainly use Lilypond, preferably in Babel source blocks and for smaller scores together with Org inline images. Still I have some theoretical interest in 2-dimensional (time and pitch) score notation in plain text (not the tablature that is specific to an instrument). Maybe I will try to reach Neil to get an impression of the now historical project. The Lilypond musical notation is quite efficient. I often use it, with a pen on a sheet of paper, in the need of noting some music for myself, when away from home and any computer. For me, it's quicker than drawing staves and notes. Particularly interesting, I will have to remember that. Michael
[O] bug#13820: It was not fixed; it now is, though I don't understand the reason
I've finally found the cause of a long lasting problem between Org and the dev version of Emacs 24.4. Though, I don't understand it... Anyone? When opening Org from my Emacs 24.3.1, everything's OK. Same .emacs file, same everything, but latest version of Emacs: bang! --8---cut here---start-8--- Debugger entered--Lisp error: (wrong-type-argument symbolp (autoload org-agenda Activate appointments found in `org-agenda-files'. With a \\[universal-argument] prefix, refresh the list of appointments. If FILTER is t, interactively prompt the user for a regular expression, and filter out entries that don't match it. If FILTER is a string, use this string as a regular expression for filtering entries out. If FILTER is a function, filter out entries against which calling the function returns nil. This function takes one argument: an entry from `org-agenda-get-day-entries'. FILTER can also be an alist with the car of each cell being either 'headline or 'category. For example: '((headline \IMPORTANT\) (category \Work\)) will only add headlines containing IMPORTANT or headlines belonging to the \Work\ category. ARGS are symbols indicating what kind of entries to consider. By default `org-agenda-to-appt' will use :deadline*, :scheduled* (i.e., deadlines and scheduled items with a hh:mm specification) and :timestamp entries. See the docstring of `org-diary' for details and examples. If an entry has a APPT_WARNTIME property, its value will be used to override `appt-message-warning-time'. (fn optional REFRESH FILTER rest ARGS) t nil)) interactive-form((autoload org-agenda Activate appointments found in `org-agenda-files'.\nWith a \\[universal-argument] prefix, refresh the list of\nappointments.\n\nIf FILTER is t, interactively prompt the user for a regular\nexpression, and filter out entries that don't match it.\n\nIf FILTER is a string, use this string as a regular expression\nfor filtering entries out.\n\nIf FILTER is a function, filter out entries against which\ncalling the function returns nil. This function takes one\nargument: an entry from `org-agenda-get-day-entries'.\n\nFILTER can also be an alist with the car of each cell being\neither 'headline or 'category. For example:\n\n '((headline \IMPORTANT\)\n(category \Work\))\n\nwill only add headlines containing IMPORTANT or headlines\nbelonging to the \Work\ category.\n\nARGS are symbols indicating what kind of entries to consider.\nBy default `org-agenda-to-appt' will use :deadline*, :scheduled*\n(i.e., deadlines and scheduled items with a hh:mm specification)\nand :timestamp entries. See the docstring of `org-diary' for\ndetails and examples.\n\nIf an entry has a APPT_WARNTIME property, its value will be used\nto override `appt-message-warning-time'.\n\n(fn optional REFRESH FILTER rest ARGS) t nil)) advice--make-interactive-form(ad-Advice-org-agenda-to-appt (autoload org-agenda Activate appointments found in `org-agenda-files'.\nWith a \\[universal-argument] prefix, refresh the list of\nappointments.\n\nIf FILTER is t, interactively prompt the user for a regular\nexpression, and filter out entries that don't match it.\n\nIf FILTER is a string, use this string as a regular expression\nfor filtering entries out.\n\nIf FILTER is a function, filter out entries against which\ncalling the function returns nil. This function takes one\nargument: an entry from `org-agenda-get-day-entries'.\n\nFILTER can also be an alist with the car of each cell being\neither 'headline or 'category. For example:\n\n '((headline \IMPORTANT\)\n(category \Work\))\n\nwill only add headlines containing IMPORTANT or headlines\nbelonging to the \Work\ category.\n\nARGS are symbols indicating what kind of entries to consider.\nBy default `org-agenda-to-appt' will use :deadline*, :scheduled*\n(i.e., deadlines and scheduled items with a hh:mm specification)\nand :timestamp entries. See the docstring of `org-diary' for\ndetails and examples.\n\nIf an entry has a APPT_WARNTIME property, its value will be used\nto override `appt-message-warning-time'.\n\n(fn optional REFRESH FILTER rest ARGS) t nil)) advice--tweak(#[128 \300\301\302#\207 [apply ad-Advice-org-agenda-to-appt nil nil] 5 #(Advised function 0 16 (dynamic-docstring-function advice--make-docstring))] ... advice--subst-main(... advice--defalias-fset(... load-with-code-conversion(d:/Users/sva/Public/Repositories/org-mode/lisp/org-loaddefs.el d:/Users/sva/Public/Repositories/org-mode/lisp/org-loaddefs.el t t) funcall(#subr load org-loaddefs.el t t t nil) --8---cut here---end---8--- The culprit: the following chunk of code in my .emacs file... #+begin_src emacs-lisp ;; keep your appointment list clean: if you delete an appointment from ;; your Org agenda file, delete the corresponding alert (defadvice org-agenda-to-appt (before wickedcool activate) Clear the existing
[O] bug#13820: It was not fixed; it now is, though I don't understand the reason
Debugger entered--Lisp error: (wrong-type-argument symbolp (autoload [...] interactive-form((autoload org-agenda Activate appointments found [...] advice--make-interactive-form(ad-Advice-org-agenda-to-appt (autoload I installed a patch into trunk that should fix this, thank you. Stefan
Re: [O] Open Document Exporter
On 06/25/2013 03:35 AM, Vikas Rawal wrote: At the end of the export process I get the message: content.xml changed on disk; really edit the buffer? (y, n, r or C-h) Please type y, n or r; or ? for help After typing 'y', I have to reconfirm with 'yes' and then with 'y' again to get a valid export. Any tips how to fix or avoid this? You perhaps have content.xml open as a buffer in emacs. Close that buffer, and you should be fine. Vikas The content.xml buffer gets created and modified by the exporter. I have found at least one (and the more annoying) place in ox-odt.el, where this happens. Using the 'write-file function Instead of (save-buffer 0) resolved the issue. In the patch below there are the following fixes for ox-odt.el: 1. content.xml changed on disk message avoided = see: @@ -4092,7 +4111,9 @@ 2. Internal cross references By replacing 'OrgXref.' with '__RefHeading__' has prefix of internal link labels, the cross references show the target Heading Line when the mouse hovers over them. The patch is rather brute force, but e.g. table captions and references still show the original behavior: The reference shows Table and the caption shows the Table number when hovering over them. By replacing: text:reference-format=\chapter\ with text:reference-format=\number\ cross references show the real chapter number, not the internal numbering. This is e.g. different, when you decide to change the outline numbering properties Before and After from their defaults. While looking at that I found out that some 'bookmarks' get generated twice by the exporter: once as OrgXref.sec-n-m and once as sec-n-m, with n and m beeing the chapter and section numbers. 3. Search path for contributed style files === @@ -157,7 +157,7 @@ the search path for git based org-mode installations had one parent directory level too much (../). 4. LaTeX like definition lists The rest of the patch deals with trying to make definition lists - term :: definition look as in LaTex and not as in HTML. Caution! the patch is very quirky, it does not work with nested lists at all. It works fine with simple, short definitions though. How to use it: - create a text style named 'OrgDefinitionTerm' in your template file. Bold text is sufficient. - create a paragraph style named 'OrgDefinitionItem' in your template file. I made mine having a hanging indent of 2cm and one (1) tab-stop at 2.1cm. What the patch does: - The 'org-odt--translate-description-lists' filter is removed from the filter stack, so descriptive lists remain just descriptive lists (and do not get split into descriptive-1 and descriptive-2 item pairs. - When transcoding 'descriptive' items to ODT, the term is retrived, typeset in bold, and inserted in front of the 'contents' of the iterm, separated by a tab. - in all case constructs where descriptive-1 and ...-2 occurs, I added descriptive too. How *should* it work: I guess the better solution would be to modify the 'org-odt--translate-description-lists' filter in a way to produce the same effect on the parsed tree representation of the document. So nested definition lists would work. Of course a customizable variable, or some per file/per subtree #+ODT tag is needed to switch on demand between the two representations. Best Regards, Georg Lehner - - - diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el index a76f7dd..c8b704c 100644 --- a/lisp/ox-odt.el +++ b/lisp/ox-odt.el @@ -86,7 +86,7 @@ :export-block ODT :filters-alist '((:filter-parse-tree . (org-odt--translate-latex-fragments - org-odt--translate-description-lists + ;;org-odt--translate-description-lists org-odt--translate-list-tables))) :menu-entry '(?o Export to ODT @@ -157,7 +157,7 @@ and `org-odt-data-dir'.) (eval-when-compile (and (boundp 'org-odt-data-dir) org-odt-data-dir ; see make install (expand-file-name ./styles/ org-odt-data-dir))) - (expand-file-name ../../etc/styles/ org-odt-lib-dir) ; git + (expand-file-name ../etc/styles/ org-odt-lib-dir) ; git (expand-file-name ./etc/styles/ org-odt-lib-dir) ; elpa (expand-file-name ./org/ data-directory) ; system ) @@ -201,7 +201,7 @@ version of org in use and is initialized from from one of: org's own private git repository, GNU ELPA tar or standard Emacs.) -(defconst org-odt-bookmark-prefix OrgXref.) +(defconst org-odt-bookmark-prefix __RefHeading__) (defconst org-odt-manifest-file-entry-tag \nmanifest:file-entry manifest:media-type=\%s\ manifest:full-path=\%s\%s/) @@ -1064,9 +1064,9 @@ See `org-odt--build-date-styles' for implementation details. (defun org-odt--target (text id) (if (not id) text (concat - (format \ntext:bookmark-start text:name=\OrgXref.%s\/ id) + (format \ntext:bookmark-start text:name=\__RefHeading__%s\/
[O] Proper use of 'org-file-apps'
Hello,
I wonder how to use 'org-file-apps'.
As I understand, when I run ~C-c C-o~ on a link of form
[[file:file.pdf][a PDF file]] Org mode uses this variable to decide how
to 'open' this type of file. Instead of docview mode of Emacs I want to
use Okular (it allows to select text from PDF file), so I read docstring
of 'org-file-apps' variable and tried to change it accordingly, but
seems I do something strange because following example don't work.
###
#+TITLE: Self-contained example
#+AUTHOR: Vladimir Lomov
#+PROPERTY: padline no
* Minimal configuration for Emacs
This is minimal configuration to run Emacs
#+BEGIN_SRC emacs-lisp :tangle org-apps-c.el
(add-to-list 'load-path /usr/share/emacs/site-lisp/org)
(require 'org)
(setq org-file-apps
'( (\\.pdf::\\(\\d+\\)\\' . run-me --page %1 %s)
(\\.pdf\\' . run-me %s)
)
)
#+END_SRC
The test script ~run-me~
#+BEGIN_SRC sh :tangle run-me :shebang #!/bin/bash
file=run-me.log
echo INPUT ${file}
echo '$@' ${file}
#+END_SRC
The test Org document
#+BEGIN_SRC org :tangle sample.org
,#+TITEL: A sample
,* Sample head
1. First item, PDF file, [[file:file.pdf][a file]];
2. second item, PDF file with selected page, [[file:file.pdf::2][a file]].
#+END_SRC
Note, that to actually test it one needs a PDF file named as
~file.pdf~ located in the same directory as the test Org document.
This is how I run Emacs to test my settings:
#+BEGIN_EXAMPLE
emacs -Q -l org-apps-c.el --eval '(find-file sample.org)'
#+END_EXAMPLE
What I expect? After I run ~C-c C-o~ on both links, I would expect to
see two different lines (parameters passed to test script) in
~run-me.log~ file. Instead, both parameters are the same. What I do
wrong? Did I understand ~org-file-apps~ correctly?
Org mode version is
#+BEGIN_EXAMPLE
Org-mode version 8.0.3 (release_8.0.3-276-g685b29 @
/usr/share/emacs/site-lisp/org/)
#+END_EXAMPLE
Emacs version is
#+BEGIN_EXAMPLE
GNU Emacs 24.3.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.2) of
2013-06-26 on HOST
#+END_EXAMPLE
###
---
WBR, Vladimir Lomov
--
(Never thought I'd be telling Malcolm and Ilya the same thing... :-)
-- Larry Wall in 199711071819.kaa29...@wall.org
Re: [O] evaluation context in call statements
Eric Schulte writes: My vote is for adding #+name support to call lines, and then handling their results in the same manner as code block results. Achim Gratz strom...@nexgo.de writes: I'm not sure what this would entail other than replacing the call with its arguments with the name of the call in the results line. But yes, that'd be a step forward, although you'd have to be careful when copying calls. This could work exactly as named source blocks work. E.g., [...] I see. The problem then really is that #+CALL lines are currently implicitly named by copying their arguments to the results line. If explicit naming is allowed, this implicit naming should go away or at least not be the default, IMHO. I agree that the current behavior is confusing, but I don't like this suggestion. I expect people will be mystified when calls replace results in the same subtree and don't replace blocks elsewhere in the same Org-mode file. No other parts of Org-mode's code block support work this way. If the results stop being implicitly named, then that problem (and its clumsy solution, which doesn't even work correctly yet) is not needed (I think). Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] Proper use of 'org-file-apps'
Vladimir Lomov lomov...@gmail.com writes: #+BEGIN_SRC emacs-lisp :tangle org-apps-c.el (add-to-list 'load-path /usr/share/emacs/site-lisp/org) (require 'org) (setq org-file-apps '( (\\.pdf::\\(\\d+\\)\\' . run-me --page %1 %s) (\\.pdf\\' . run-me %s) ) ) #+END_SRC \d is Perl regexp syntax for matching a digit, but (afaik) not emacs syntax. Try '( (\\.pdf::\\([0-9]+\\)\\' . run-me --page %1 %s) or '( (\\.pdf::\\([[:digit:]]+\\)\\' . run-me --page %1 %s) instead. -- Nick
