[O] Sub-tree EXPORT_ properties are not over-riding file-level options
My exports are not picking up sub-tree EXPORT_ properties. Emacs: GNU Emacs 24.3.1 (i386-mingw-nt6.1.7601) of 2013-03-17 on MARVIN Org: Org-mode version 8.2.10 (release_8.2.10-16-g4c37a9 Here's my test file (export-test.org): #+AUTHOR: Daniel Sinder #+OPTIONS: toc:nil * First Heading - Item 1.a - Item 1.b * Second Heading :PROPERTIES: :EXPORT_AUTHOR: E. Maxor Gamode :END: - Item 2.a - Item 2.b When I export the whole file to ASCII, the author is set, as expected, from the AUTHOR option (blank lines removed for brevity): ___ EXPORT-TEST Daniel Sinder ___ 1 First Heading === - Item 1.a - Item 1.b 2 Second Heading - Item 2.a - Item 2.b When I select just the Second Heading, I then get the following (note, EXPORT_AUTHOR property is not picked up): ___ EXPORT-TEST Daniel Sinder ___ 1 Second Heading - Item 2.a - Item 2.b If I disable the loading of my locally installed, bleeding edge org-mode from my init.el, it brings me back to Org-mode version 7.9.3f (release_7.9.3f-17-g7524ef), which is the old export engine (I think). However the sub-tree export at least does what I'd expect in terms of setting the title (from the heading) and author (from the property): Second Heading == Author: E. Maxor Gamode Date: 2014-11-12 19:53:00 Pacific Standard Time - Item 2.a - Item 2.b I've verified the same problem for other EXPORT_ properties and other export formats (e.g., html). Is this a bug in the new export engine, or am I doing something wrong? Any suggestions/help would be appreciated. Thanks, Dan
Re: [O] [PATCH] inline src block results can be removed
On Wed, 12 Nov 2014, Aaron Ecay wrote:
Hi Chuck,
2014ko azaroak 12an, "Charles C. Berry"-ek idatzi zuen:
Inline src blocks cannot update their results --- causing some of us
heaadaches [1].
These patches fix that by placing the result of an inline src block in an
export snippet with a faux :back-end called 'babel'.
So C-c C-c with point on src_R{1+2} will insert `@@babel:3@@'. Updating
the contents of the inline src block and retyping C-c C-c will update the
snippet. On export, these snippets are rendered using the verbatim
transcoder, e.g. \texttt{3} for latex backends.
Support for most backends is provided.
org-babel-execute-buffer will also update such snippets.
Instead of using an export snippet, which requires per-backend changes,
you could wrap results in a macro, e.g. {{{results(2)}}}.
Users could customize this macro per-buffer (with the usual #+macro
keyword) to provide their own formatting of inline results. You
could provide the fallback interpretation in the second call to
‘org-macro-replace-all’ in ‘org-export-as’ (currently responsible
for expanding a few macros like {{{author}}} and {{{date}}}).
What do you think of this idea?
Aaron,
I like the flexibility that macros would allow.
Some care needs to be taken with commas, but not a big deal.
I don't think the usual #+MACRO works here, as the definition would be
found in `org-macro-templates' by the first call and existing stuff would
be expanded instead of being left for babel to remove it. But setting it
up as a document keyword should work, right?
Don't know if there are other gotchas.
Maybe a limited collection of formats could be set up to support basic
markup options and the macro could choose amongst them with a second arg
set by a babel header arg.
I am not quite sure how to marry this to header args. Maybe the :wrap
header arg should be hijacked for inline src blocks to specify a macro for
the results.
I mean, does anyone actually use stuff like src_R[:wrap latex]{1+2}? The
current result cannot be parsed as an export block, AFAICS.
Chuck
Re: [O] pdf images in html export
On Wed, Nov 12, 2014 at 3:32 PM, Andreas Leha
wrote:
> Hi John,
>
> John Hendy writes:
>> On Nov 12, 2014 7:36 AM, "Andreas Leha"
>> wrote:
>>>
>>> Hi Rainer,
>>>
>>> Rainer M Krug writes:
>>> > Andreas Leha writes:
[snip]
>>> Here, I am after a solution, that works on images that are not
>> produced
>>> but merely included via [[file:./some.pdf]].
>>>
>>
>> If the names are always the same, could you just sed or replace-regexp
>> all *.pdf for *.png?
>>
>
> I could. And I would need to do the conversion manually as well.
Agreed, and sounds like you're already considering ImageMagick for
this. I've used it similarly with more or less good results. I always
have to look up the right options, play with one file a bunch to get a
nice blend of size/quality, and also have learned to use whatever
option (either convert or mogrify) saves a *new* version, as I didn't
get at first that one of those edits the file in-place!
> But I still want the pdfs to go into the LaTeX export.
>
>> Not elegant, but works easily/now, and takes less time than this
>> thread :)
>
> Hint taken. Such feature is apparently not too important for most.
>
Yeah, that was mostly tongue in cheek... I'd be doing the exact same
thing (looking for a better way to automate/process, even though
technically it's simply changing the the contents of
\includegraphics{something} or . Thus, to the
last point, I'd generate .pdfs, leave the LaTeX version alone, convert
some other image format for html, and then sed/replace-regexp on the
html to change all image.pdf -> image.png.
John
> [...]
>
> Thanks,
> Andreas
>
>
Re: [O] pdf images in html export
Hi John, John Hendy writes: > On Nov 12, 2014 7:36 AM, "Andreas Leha" > wrote: >> >> Hi Rainer, >> >> Rainer M Krug writes: >> > Andreas Leha writes: >> > >> >> Hi Marco, >> >> >> >> Marco Wahl writes: >> >>> Andreas Leha writes: >> >>> >> how would I export an org file containing >> >> [[file:./myimage.pdf]] >> >> to html so that a say png version myimage.pdf is inlined in the > html >> which links to the pdf? >> >> I guess it should be possible to run imagemagick on all pdf > links during >> export somehow. >> >>> >> >>> You could introduce a relation of the pdf-filenames to the > respective >> >>> thumb-filenames e.g. by using the suffix '_thumb'. Before the > export >> >>> the conversion tool would create the thumbs. >> >>> >> >>> The org-file could reference the data as >> >>> >> >>> [[file:./myimage.pdf][file:myimage_thumb.png]] >> >>> >> >>> See the info page (info "(org)Images in HTML export")? >> >>> >> >>> Untested. I just accidentially browsed that info page yesterday. >> >>> >> >>> >> >> >> >> Thanks for your thoughts. I would like to automate all of that. > So, I >> >> guess the first question is where to put code that would trigger > the >> >> conversion and how to best detect links to pdfs. >> > >> > Well - this is coming again and again - but no solution out of the >> > box. There are effectively two approaches: >> > >> > 1) Macro to change properties according to backend used. >> > >> > One usage is changing the file name extension according to the >> > backend. This is implemented as a simplified macro below. This > could >> > be done by using ~(by-backend (html "graph.png") (latex > "graph.pdf") (t "graph.pdf"))~ >> > >> > See > [ > [http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html#sec-4-3][work > section > ob-doc-LaTeX]] for details. >> > >> > #+begin_src emacs-lisp >> > (setq org-babel-latex-htlatex "htlatex") >> > (defmacro rmk-by-backend (&rest body) >> > `(case (if (boundp 'backend) (org-export-backend-name backend) > nil) ,@body)) >> > #+end_src >> > >> > 2) To use svg image format, which is supported by both (although > has >> > it's drawbacks: slow rendering of the html, need to run external > programs upon compilation) >> > >> > So the first might be the modst feasible option. >> > >> >> Thanks for this. I am aware of how to *produce* graphics in > different >> formats for different export backends. I use your first approach, >> which I think is the better solution. >> >> Here, I am after a solution, that works on images that are not > produced >> but merely included via [[file:./some.pdf]]. >> > > If the names are always the same, could you just sed or replace-regexp > all *.pdf for *.png? > I could. And I would need to do the conversion manually as well. But I still want the pdfs to go into the LaTeX export. > Not elegant, but works easily/now, and takes less time than this > thread :) Hint taken. Such feature is apparently not too important for most. [...] Thanks, Andreas
Re: [O] pdf images in html export
On Nov 12, 2014 7:36 AM, "Andreas Leha" wrote: > > Hi Rainer, > > Rainer M Krug writes: > > Andreas Leha writes: > > > >> Hi Marco, > >> > >> Marco Wahl writes: > >>> Andreas Leha writes: > >>> > how would I export an org file containing > > [[file:./myimage.pdf]] > > to html so that a say png version myimage.pdf is inlined in the html > which links to the pdf? > > I guess it should be possible to run imagemagick on all pdf links during > export somehow. > >>> > >>> You could introduce a relation of the pdf-filenames to the respective > >>> thumb-filenames e.g. by using the suffix '_thumb'. Before the export > >>> the conversion tool would create the thumbs. > >>> > >>> The org-file could reference the data as > >>> > >>> [[file:./myimage.pdf][file:myimage_thumb.png]] > >>> > >>> See the info page (info "(org)Images in HTML export")? > >>> > >>> Untested. I just accidentially browsed that info page yesterday. > >>> > >>> > >> > >> Thanks for your thoughts. I would like to automate all of that. So, I > >> guess the first question is where to put code that would trigger the > >> conversion and how to best detect links to pdfs. > > > > Well - this is coming again and again - but no solution out of the > > box. There are effectively two approaches: > > > > 1) Macro to change properties according to backend used. > > > > One usage is changing the file name extension according to the > > backend. This is implemented as a simplified macro below. This could > > be done by using ~(by-backend (html "graph.png") (latex "graph.pdf") (t "graph.pdf"))~ > > > > See [[ http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html#sec-4-3][work section ob-doc-LaTeX]] for details. > > > > #+begin_src emacs-lisp > > (setq org-babel-latex-htlatex "htlatex") > > (defmacro rmk-by-backend (&rest body) > > `(case (if (boundp 'backend) (org-export-backend-name backend) nil) ,@body)) > > #+end_src > > > > 2) To use svg image format, which is supported by both (although has > >it's drawbacks: slow rendering of the html, need to run external programs upon compilation) > > > > So the first might be the modst feasible option. > > > > Thanks for this. I am aware of how to *produce* graphics in different > formats for different export backends. I use your first approach, > which I think is the better solution. > > Here, I am after a solution, that works on images that are not produced > but merely included via [[file:./some.pdf]]. > If the names are always the same, could you just sed or replace-regexp all *.pdf for *.png? Not elegant, but works easily/now, and takes less time than this thread :) John > I think there should be the possibility to include these into html (and > odt) export without any user interaction. So, I > - do not want to write a source block just to produce the by-backend image > - do not want to change the link manually > - do not want to run the converter manually > > I am pretty sure this should be achievable with standard orgmode tools > (like filters, export hooks, or anything). > > Since 'this is coming again and again' it seems a non-esoteric task. > And as there is 'no solution out of the box', I assume(d) that somebody has > written these filters already. > > Regards, > Andreas > >
Re: [O] pdf images in html export
Hi Chuck, "Charles C. Berry" writes: > On Wed, 12 Nov 2014, Andreas Leha wrote: > >> Hi Rainer, >> >> Rainer M Krug writes: >>> Andreas Leha writes: >>> Hi Marco, Marco Wahl writes: > Andreas Leha writes: > >> how would I export an org file containing >> >> [[file:./myimage.pdf]] >> >> to html so that a say png version myimage.pdf is inlined in the html >> which links to the pdf? >> > > [deleted] > > Andreas replying: > >> >> Thanks for this. I am aware of how to *produce* graphics in different >> formats for different export backends. I use your first approach, >> which I think is the better solution. >> >> Here, I am after a solution, that works on images that are not produced >> but merely included via [[file:./some.pdf]]. >> >> I think there should be the possibility to include these into html (and >> odt) export without any user interaction. So, I >> - do not want to write a source block just to produce the by-backend image >> - do not want to change the link manually >> - do not want to run the converter manually >> >> I am pretty sure this should be achievable with standard orgmode tools >> (like filters, export hooks, or anything). >> >> Since 'this is coming again and again' it seems a non-esoteric task. >> And as there is 'no solution out of the box', I assume(d) that somebody has >> written these filters already. >> > > What you want is a custom `hyperlink type'. > > I don't know if anyone has written this, but the machinery is in > `org-add-link-type'. You user would enter (say) > > [[pdf:./some.pdf]] > > and clicking on it would open the file (assuming a proper FOLLOW > argument) and exporting would handle all the behind the scenes > tinkering to create png's or whatever is needed for the backend in > question (assuming a suitable EXPORT argument). > > The docstring for `org-add-link-type' has details. Also there is a > worked example and more instructions at > > (info "(org) Adding hyperlink types") > > HTH, It does. Thanks for this hint. This comes close to what I am after. But -- at the risk of being persistent -- this still requires me to change the orgmode document, if only to change [[file:...]] to [[pdf:...]]. I still think that this use case is so common, that it would be nice for org support of the original document. Maybe that even deserves first class support in org. One could imagine some customizeable variable org-transcode-images-on-export, that would know a list of supported image formats for each export backend and try to run imagemagick on the others to transcode them into exportable images linking to the original. Given that this does not exist (and given that it won't be me implementing that) I was hoping for a custom (hacky?) solution just for pdfs. Given that this appears not to exist either, I will probably follow your suggestion of adding a custom link type. Thanks, Andreas
Re: [O] converting to "init.org"
Alexander Baier writes: > [ Accidentally hit send, ... ] > > On 2014-11-12 20:27 Sharon Kimble wrote: >> *** Agenda config >> #+BEGIN_SRC emacs-lisp >> '(org-agenda-include-all-todo t) >> '(org-agenda-span 21) >> '(org-agenda-include-diary t) >> '(org-agenda-insert-diary-extract-time t) >> '(org-agenda-insert-diary-strategy (quote top-level)) > > These are just quoted lists containing a variable and presumably a value > said variable should be set to. This lisp code does "nothing" when > executed, at least not setting these variables. To me this looks like > something, that belongs into a customize-set-variables call. I am not > sure how to get those into your init.org file. I just let them reside in > my init.el file, which is also calls org-babel to do the real > initialization via org-babel-load-file. > Yes, these are probably cut-n-pasted from the customize file but without the part that really does the work: (custom-set-variables '(org-agenda-span 21)) -- Nick
Re: [O] Embedded LaTeX does not work with Unicode quotes
Nick Dokos writes:
> "punctuation" in the syntax tables. Look for org-latex-regexps in
> org.el
The line in question is
#+BEGIN_SRC emacs-lisp
("$" "\\([^$]\\|^\\)\\(\\(\\$\\([^
\r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^
\r\n,.$]\\)\\$\\)\\)\\([- .,?;:'\")\000]\\|$\\)" 2 nil)
#+END_SRC
It's probably not too hard to see that the culprit is the bunch of
punctuation characters towards the end. Indeed if you change .,?;:'\"
to .,?;:'\"” -- that solves the OPs problem. However, it might be even
better to use a more general syntax, [:punct:], which matches all
punctuation (as we want). So:
#+BEGIN_SRC emacs-lisp
("$" "\\([^$]\\|^\\)\\(\\(\\$\\([^
\r\n,;.$][^$\n\r]*?\\(\n[^$\n\r]*?\\)\\{0,2\\}[^
\r\n,.$]\\)\\$\\)\\)\\([- [:punct:]\000]\\|$\\)" 2 nil)
#+END_SRC
--
Florian Beck
Re: [O] converting to "init.org"
Aloha Sharon, You need to set the variables with =set= or =setq=. Sharon Kimble writes: > I have been converting/building my "init.el" to "init.org" and it is > working well, but there are a few things that I'm not sure > about. For instance, I have a command to display 21 days in my > agenda, but it is not happening. This is the command - > > ** Agenda > > *** Agenda config > #+BEGIN_SRC emacs-lisp > '(org-agenda-include-all-todo t) > '(org-agenda-span 21) > '(org-agenda-include-diary t) > '(org-agenda-insert-diary-extract-time t) > '(org-agenda-insert-diary-strategy (quote top-level)) #+BEGIN_SRC emacs-lisp (setq org-agenda-span 21) #+END_SRC hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] converting to "init.org"
[ Accidentally hit send, ... ] On 2014-11-12 20:27 Sharon Kimble wrote: > *** Agenda config > #+BEGIN_SRC emacs-lisp > '(org-agenda-include-all-todo t) > '(org-agenda-span 21) > '(org-agenda-include-diary t) > '(org-agenda-insert-diary-extract-time t) > '(org-agenda-insert-diary-strategy (quote top-level)) These are just quoted lists containing a variable and presumably a value said variable should be set to. This lisp code does "nothing" when executed, at least not setting these variables. To me this looks like something, that belongs into a customize-set-variables call. I am not sure how to get those into your init.org file. I just let them reside in my init.el file, which is also calls org-babel to do the real initialization via org-babel-load-file. HTH, -- Alexander Baier
Re: [O] converting to "init.org"
On 2014-11-12 20:27 Sharon Kimble wrote: > *** Agenda config > #+BEGIN_SRC emacs-lisp > '(org-agenda-include-all-todo t) > '(org-agenda-span 21) > '(org-agenda-include-diary t) > '(org-agenda-insert-diary-extract-time t) > '(org-agenda-insert-diary-strategy (quote top-level)) These are just quoted lists containing a variable and presumably a value said variable should be set to. This lisp code does "nothing" when executed, at least not setting these variables. To me this looks like something, that belongs into a customize-set-variables call. I am not sure how to get those into your init.org file. I just let them reside in my init.el file, which is also responsible for -- Alexander Baier
Re: [O] [PATCH] inline src block results can be removed
Hi Chuck,
2014ko azaroak 12an, "Charles C. Berry"-ek idatzi zuen:
>
> Inline src blocks cannot update their results --- causing some of us
> heaadaches [1].
>
> These patches fix that by placing the result of an inline src block in an
> export snippet with a faux :back-end called 'babel'.
>
> So C-c C-c with point on src_R{1+2} will insert `@@babel:3@@'. Updating
> the contents of the inline src block and retyping C-c C-c will update the
> snippet. On export, these snippets are rendered using the verbatim
> transcoder, e.g. \texttt{3} for latex backends.
>
> Support for most backends is provided.
>
> org-babel-execute-buffer will also update such snippets.
Instead of using an export snippet, which requires per-backend changes,
you could wrap results in a macro, e.g. {{{results(2)}}}.
Users could customize this macro per-buffer (with the usual #+macro
keyword) to provide their own formatting of inline results. You
could provide the fallback interpretation in the second call to
‘org-macro-replace-all’ in ‘org-export-as’ (currently responsible
for expanding a few macros like {{{author}}} and {{{date}}}).
What do you think of this idea?
--
Aaron Ecay
[O] converting to "init.org"
I have been converting/building my "init.el" to "init.org" and it is working well, but there are a few things that I'm not sure about. For instance, I have a command to display 21 days in my agenda, but it is not happening. This is the command - --8<---cut here---start->8--- ** Agenda *** Agenda config #+BEGIN_SRC emacs-lisp '(org-agenda-include-all-todo t) '(org-agenda-span 21) '(org-agenda-include-diary t) '(org-agenda-insert-diary-extract-time t) '(org-agenda-insert-diary-strategy (quote top-level)) --8<---cut here---end--->8--- Its obviously a fault in my configuration, but I can't see what the solution is. At the moment I just get the default display of just 7 days. Thanks Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots TGmeds = http://www.tgmeds.org.uk Debian testing, fluxbox 1.3.5, emacs 24.4.1.0 signature.asc Description: PGP signature
Re: [O] pdf images in html export
On Wed, 12 Nov 2014, Andreas Leha wrote: Hi Rainer, Rainer M Krug writes: Andreas Leha writes: Hi Marco, Marco Wahl writes: Andreas Leha writes: how would I export an org file containing [[file:./myimage.pdf]] to html so that a say png version myimage.pdf is inlined in the html which links to the pdf? [deleted] Andreas replying: Thanks for this. I am aware of how to *produce* graphics in different formats for different export backends. I use your first approach, which I think is the better solution. Here, I am after a solution, that works on images that are not produced but merely included via [[file:./some.pdf]]. I think there should be the possibility to include these into html (and odt) export without any user interaction. So, I - do not want to write a source block just to produce the by-backend image - do not want to change the link manually - do not want to run the converter manually I am pretty sure this should be achievable with standard orgmode tools (like filters, export hooks, or anything). Since 'this is coming again and again' it seems a non-esoteric task. And as there is 'no solution out of the box', I assume(d) that somebody has written these filters already. What you want is a custom `hyperlink type'. I don't know if anyone has written this, but the machinery is in `org-add-link-type'. You user would enter (say) [[pdf:./some.pdf]] and clicking on it would open the file (assuming a proper FOLLOW argument) and exporting would handle all the behind the scenes tinkering to create png's or whatever is needed for the backend in question (assuming a suitable EXPORT argument). The docstring for `org-add-link-type' has details. Also there is a worked example and more instructions at (info "(org) Adding hyperlink types") HTH, Chuck
Re: [O] [PATH] Speedups to org-table-recalculate
Hi Nathaniel On Wed, Nov 12, 2014 at 12:51 PM, Nathaniel Flath wrote: > New patches attached! Now that they apply I found: > + "Re-applying formulas to full table...(line %d)"))) Missing cnt. > + (message "Re-applying formulas...done" cnt)) Superfluous cnt. Michael
Re: [O] Embedded LaTeX does not work with Unicode quotes
On 2014-11-12, at 07:05, Nick Dokos wrote: > Marcin Borkowski writes: > >> Hi list, >> >> I have this: „$n\eps\le b$”, and it seems not to be recognized as a >> LaTeX fragment. The manual says: >> >> >> To avoid conflicts with currency specifications, single `$' characters >> are only recognized as math delimiters if the enclosed text contains at >> most two line breaks, is directly attached to the `$' characters with no >> whitespace in between, and if the closing `$' is followed by whitespace, >> punctuation or a dash. >> >> >> When I C-u C-x = on the closing quote, I get >> >> >> ... >>syntax: . which means: punctuation >> ... >> >> >> so I don't know why it is not recognized as punctuation. Consequently, >> it is exported verbatim (with `\$') into LaTeX, and also (obviously) C-c >> C-x C-l does not fontify it. When I change ” into " (the ASCII #x22 >> quote), everything is ok. >> > > The $...$ construct is recognized by a regexp which, while complicated, > is not complicated enough to recognize everything that's marked > "punctuation" in the syntax tables. Look for org-latex-regexps in org.el > (and note that the regexp for "$" is about twice as long as the next > longest regexp - the one for "begin"). The others (for \(...\), \[...\] > and $$..$$) are fairly trivial. > >> My questions: >> >> 1. Isn't it a bug? >> > > Yes, probably - but looking at the regexp, I cringe: I don't want to even > try deciphering it, let alone change it - life's too short... Ah, regex. I have no more questions... >> 2. If not, what can I do to in my config so that it is recognized >> properly? >> >> PS. I just recalled that using \(...\) should help, and indeed it does. >> Still, I'm curious about the answer to my questions (now that I >> remembered a workaround, especially #1). >> > That is indeed the best solution. Yep. Thanks! -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
Re: [O] Inline code :results replace not working
Sebastien Vauban writes: > > "Charles C. Berry" wrote: > > I find myself writing an inline src block, then typing `C-c C-c C-x u' > > to view > > and then remove the result, then revise, and repeat. I'd be happy to > > just leave > > it in the document. > > What command are you calling with the above? Oops! Make that 'C-c C-c y C-x u' - C-c C-c runs the command org-ctrl-c-ctrl-c. - y confirms code block evaluation - - C-x u runs the command undo. --- saving myself two keystrokes (C-x u) isn't much, but if I wonder off and do something else, then I have to navigate back, find the offending result and edit it out. Best, Chuck
Re: [O] pdf images in html export
Andreas Leha writes: > Hi Rainer, > > Rainer M Krug writes: >> Andreas Leha writes: >> >>> Hi Marco, >>> >>> Marco Wahl writes: Andreas Leha writes: > how would I export an org file containing > > [[file:./myimage.pdf]] > > to html so that a say png version myimage.pdf is inlined in the html > which links to the pdf? > > I guess it should be possible to run imagemagick on all pdf links during > export somehow. You could introduce a relation of the pdf-filenames to the respective thumb-filenames e.g. by using the suffix '_thumb'. Before the export the conversion tool would create the thumbs. The org-file could reference the data as [[file:./myimage.pdf][file:myimage_thumb.png]] See the info page (info "(org)Images in HTML export")? Untested. I just accidentially browsed that info page yesterday. >>> >>> Thanks for your thoughts. I would like to automate all of that. So, I >>> guess the first question is where to put code that would trigger the >>> conversion and how to best detect links to pdfs. >> >> Well - this is coming again and again - but no solution out of the >> box. There are effectively two approaches: >> >> 1) Macro to change properties according to backend used. >> >> One usage is changing the file name extension according to the >> backend. This is implemented as a simplified macro below. This could >> be done by using ~(by-backend (html "graph.png") (latex "graph.pdf") (t >> "graph.pdf"))~ >> >> See >> [[http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html#sec-4-3][work >> section ob-doc-LaTeX]] for details. >> >> #+begin_src emacs-lisp >> (setq org-babel-latex-htlatex "htlatex") >> (defmacro rmk-by-backend (&rest body) >> `(case (if (boundp 'backend) (org-export-backend-name backend) nil) >> ,@body)) >> #+end_src >> >> 2) To use svg image format, which is supported by both (although has >>it's drawbacks: slow rendering of the html, need to run external programs >> upon compilation) >> >> So the first might be the modst feasible option. >> > > Thanks for this. I am aware of how to *produce* graphics in different > formats for different export backends. I use your first approach, > which I think is the better solution. I agree with you. > > Here, I am after a solution, that works on images that are not produced > but merely included via [[file:./some.pdf]]. OK - understood. > > I think there should be the possibility to include these into html (and > odt) export without any user interaction. So, I > - do not want to write a source block just to produce the by-backend image > - do not want to change the link manually > - do not want to run the converter manually I agree with you - this *should* be possible, and I assume not to difficult to implement. In my opinion, this should also work out of the box when enabling it e.g. via a property. > > I am pretty sure this should be achievable with standard orgmode tools > (like filters, export hooks, or anything). Yes - it should be. > > Since 'this is coming again and again' it seems a non-esoteric task. > And as there is 'no solution out of the box', I assume(d) that somebody has > written these filters already. Unfortunately not... Cheers, Rainer > > Regards, > Andreas > > > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] pdf images in html export
Hi Rainer, Rainer M Krug writes: > Andreas Leha writes: > >> Hi Marco, >> >> Marco Wahl writes: >>> Andreas Leha writes: >>> how would I export an org file containing [[file:./myimage.pdf]] to html so that a say png version myimage.pdf is inlined in the html which links to the pdf? I guess it should be possible to run imagemagick on all pdf links during export somehow. >>> >>> You could introduce a relation of the pdf-filenames to the respective >>> thumb-filenames e.g. by using the suffix '_thumb'. Before the export >>> the conversion tool would create the thumbs. >>> >>> The org-file could reference the data as >>> >>> [[file:./myimage.pdf][file:myimage_thumb.png]] >>> >>> See the info page (info "(org)Images in HTML export")? >>> >>> Untested. I just accidentially browsed that info page yesterday. >>> >>> >> >> Thanks for your thoughts. I would like to automate all of that. So, I >> guess the first question is where to put code that would trigger the >> conversion and how to best detect links to pdfs. > > Well - this is coming again and again - but no solution out of the > box. There are effectively two approaches: > > 1) Macro to change properties according to backend used. > > One usage is changing the file name extension according to the > backend. This is implemented as a simplified macro below. This could > be done by using ~(by-backend (html "graph.png") (latex "graph.pdf") (t > "graph.pdf"))~ > > See > [[http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html#sec-4-3][work > section ob-doc-LaTeX]] for details. > > #+begin_src emacs-lisp > (setq org-babel-latex-htlatex "htlatex") > (defmacro rmk-by-backend (&rest body) > `(case (if (boundp 'backend) (org-export-backend-name backend) nil) > ,@body)) > #+end_src > > 2) To use svg image format, which is supported by both (although has >it's drawbacks: slow rendering of the html, need to run external programs > upon compilation) > > So the first might be the modst feasible option. > Thanks for this. I am aware of how to *produce* graphics in different formats for different export backends. I use your first approach, which I think is the better solution. Here, I am after a solution, that works on images that are not produced but merely included via [[file:./some.pdf]]. I think there should be the possibility to include these into html (and odt) export without any user interaction. So, I - do not want to write a source block just to produce the by-backend image - do not want to change the link manually - do not want to run the converter manually I am pretty sure this should be achievable with standard orgmode tools (like filters, export hooks, or anything). Since 'this is coming again and again' it seems a non-esoteric task. And as there is 'no solution out of the box', I assume(d) that somebody has written these filters already. Regards, Andreas
Re: [O] pdf images in html export
Andreas Leha writes: > Hi Marco, > > Marco Wahl writes: >> Andreas Leha writes: >> >>> how would I export an org file containing >>> >>> [[file:./myimage.pdf]] >>> >>> to html so that a say png version myimage.pdf is inlined in the html >>> which links to the pdf? >>> >>> I guess it should be possible to run imagemagick on all pdf links during >>> export somehow. >> >> You could introduce a relation of the pdf-filenames to the respective >> thumb-filenames e.g. by using the suffix '_thumb'. Before the export >> the conversion tool would create the thumbs. >> >> The org-file could reference the data as >> >> [[file:./myimage.pdf][file:myimage_thumb.png]] >> >> See the info page (info "(org)Images in HTML export")? >> >> Untested. I just accidentially browsed that info page yesterday. >> >> > > Thanks for your thoughts. I would like to automate all of that. So, I > guess the first question is where to put code that would trigger the > conversion and how to best detect links to pdfs. Well - this is coming again and again - but no solution out of the box. There are effectively two approaches: 1) Macro to change properties according to backend used. One usage is changing the file name extension according to the backend. This is implemented as a simplified macro below. This could be done by using ~(by-backend (html "graph.png") (latex "graph.pdf") (t "graph.pdf"))~ See [[http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-LaTeX.html#sec-4-3][work section ob-doc-LaTeX]] for details. #+begin_src emacs-lisp (setq org-babel-latex-htlatex "htlatex") (defmacro rmk-by-backend (&rest body) `(case (if (boundp 'backend) (org-export-backend-name backend) nil) ,@body)) #+end_src 2) To use svg image format, which is supported by both (although has it's drawbacks: slow rendering of the html, need to run external programs upon compilation) So the first might be the modst feasible option. Rainer > > Thanks, > Andreas > > > -- Rainer M. Krug email: Rainerkrugsde PGP: 0x0F52F982 signature.asc Description: PGP signature
Re: [O] [PATH] Speedups to org-table-recalculate
New patches attached! On Sun, Nov 9, 2014 at 9:12 PM, Michael Brand wrote: > Hi Nathaniel > > On Sun, Nov 9, 2014 at 11:18 AM, Nathaniel Flath > wrote: > > Updated patches attached. > > The second does not apply after the first on today's > release_8.3beta-552-ga95cfeb. Unrelated: The second has new closing > parentheses on an own line. > > Michael > 0002-org-table.el-org-table-recalculate-is-quieter.patch Description: Binary data 0001-org-table.el-org-table-recalculate-early-returns.patch Description: Binary data
Re: [O] [patch] Bug (regression) in org-replace-disputed-keys. Bisected.
From: Nicolas Goaziou
> Could you provide a patch with git format-patch?
Glad to contribute. I attached two patches, the first for the lisp fix, and the
second for org.texi. The code is confirmed to work, and the info correctly
compiles. More is described later.
Now, release notes (http://orgmode.org/Changes.html) fix proposal. I here write
"the full version". (Sorry. I know concise is better.)
1. Version 8.1, "Important bugfixes" section
The following sentence should be moved to "Incompatible changes" section:
"The replacement of disputed keys is now turned of when reading a date"
Furthermore, the following should be added: "N.B. This is reverted in Version
8.3."
2. Please add this to the next version "Incompatible changes" section:
"`org-replace-disputed-keys' has been ignored when reading date since version
8.1, but the former behavior is restored again."
Perhaps to "New features" can be added: "Keybinding for reading date can be
customized with a new variable `org-read-date-minibuffer-local-map'. (In fact,
it was introduced in version 8.0, but it was not announced.)"
Some comments on my org.texi patch. I renamed the section "Creating timestamps"
to "Timestamp commands," since not all commands don't create. (Links are
updated.) I rewrote some explanations. I think it's better, but I'm not sure if
my tone of voice (e.g. "Date/time prompt is ``smart enough''") is acceptable.
Some whitespace cleanup accompanies, so you may want to use "git show -b".
I added the description of key "!" in timestamp creation. But I don't know what
"diary" in Emacs is, so you may want to improve it.
Regards,
Teika (Teika kazura)
PS I may send a patch to fix hardcoded C-x (following C-c), by introducing
"org-mode-ctrl-x-map" and so on. I rebind C-x, and some are screwed up by
hardcoding. ;-)
>From 1ef556a1eae75045b560c65d8a4ba2e71da71a11 Mon Sep 17 00:00:00 2001
From: Teika kazura
Date: Sat, 8 Nov 2014 16:48:36 +0900
Subject: [PATCH 1/2] Let `org-read-date' respect `org-replace-disputed-keys'
again.
Beginning from org-8.1, org-read-date ignores org-replace-disputed-keys. This commit restores the original behavior. Users who want the org-8.1 behavior should customize `org-read-date-minibuffer-local-map' instead.
See http://thread.gmane.org/gmane.emacs.orgmode/90626/focus=91318 for the discussion on this issue.
This commit in effect reverts a6986494a0c4fc5d3363c2bebe48215e7138e4f1 and e8023dde58f267a525b63184ec07d371b5a4c8b5.
---
lisp/org.el | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 87f1725..8146eb5 100755
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -16600,8 +16600,7 @@ So these are more for recording a certain time/date."
(defvar org-read-date-inactive)
(defvar org-read-date-minibuffer-local-map
- (let* ((org-replace-disputed-keys nil)
- (map (make-sparse-keymap)))
+ (let* ((map (make-sparse-keymap)))
(set-keymap-parent map minibuffer-local-map)
(org-defkey map (kbd ".")
(lambda () (interactive)
--
2.0.4
>From 9c6ed406d5add908aac5b73cdfacc2272f2cf89e Mon Sep 17 00:00:00 2001
From: Teika kazura
Date: Wed, 12 Nov 2014 17:08:00 +0900
Subject: [PATCH 2/2] org.texi: Timestamp sections.
Section "Creating timestamp" is renamed to "Timestamp commands". `org-read-date-minibuffer-local-map' is described. Other contents improvement in that section.
Minor whitespace cleanups.
---
doc/org.texi | 99 ++--
1 file changed, 49 insertions(+), 50 deletions(-)
diff --git a/doc/org.texi b/doc/org.texi
index b01db2c..bfb5b4f 100644
--- a/doc/org.texi
+++ b/doc/org.texi
@@ -458,14 +458,14 @@ Defining columns
Dates and times
* Timestamps:: Assigning a time to a tree entry
-* Creating timestamps:: Commands which insert timestamps
+* Timestamp commands:: Commands which insert timestamps
* Deadlines and scheduling::Planning your work
* Clocking work time:: Tracking how long you spend on a task
* Effort estimates::Planning work effort in advance
* Relative timer:: Notes with a running timer
* Countdown timer:: Starting a countdown timer for a task
-Creating timestamps
+Timestamp commands
* The date/time prompt::How Org mode helps you entering date and time
* Custom time format:: Making dates look different
@@ -4646,7 +4646,7 @@ and agenda buffer with the @kbd{,} command (@pxref{Agenda commands}).
@vindex org-priority-start-cycle-with-default
Increase/decrease priority of current headline@footnote{See also the option
@code{org-priority-start-cycle-with-default}.}. Note that these keys are
-also used to modify timestamps (@pxref{Creating timestamps}). See also
+also used to modify timestamps (@pxref{Timestamp commands}). See also
@ref{Conflicts}, for a discussion of the interaction with
@code{shift-selection-mode}.
@end table
@@ -5771,7 +5771,7 @@ is use
Re: [O] [RFC] Change property drawer syntax
Nicolas, Sebastien Vauban wrote: > After heavy testing (on all my Org files, I mean) of the function > `org-repair-property-drawers', it works perfectly except for the > following corner-case (when there are Org properties in "quote" > blocks). > > PS- I did not retest (yet) the same thing in #+begin/end_src > blocks... as playing with that example files makes my Emacs eat 100% > of the CPU (infloop?). I've restarted Emacs 5 or 6 times before > being able to write this ECM... I confirm the problem is the same if Org properties are enclosed in a #+begin/end_src block such as: --8<---cut here---start->8--- ** Sectionnement Exemple de section avec un titre court pour LaTeX : #+begin_src org ,* Ceci est un titre de section assez long :PROPERTIES: :ALT_TITLE: Ceci est un titre court :END: #+end_src --8<---cut here---end--->8--- Upon execution of the repair function, that entry will be wrongly converted. Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Change property drawer syntax
Hello Nicolas, Nicolas Goaziou wrote: > As discussed previously, I would like to modify property drawers > syntax. [...] > > However, it will break some Org documents. In particular, TODO-states > changes are usually logged before any drawer, including properties > drawers. The following function repairs them. > > (defun org-repair-property-drawers () > "Fix properties drawers in current buffer. > Ignore non Org buffers." > (when (eq major-mode 'org-mode) > (org-with-wide-buffer >(goto-char (point-min)) >(let ((case-fold-search t) > (inline-re (and (featurep 'org-inlinetask) > (concat (org-inlinetask-outline-regexp) > "END[ \t]*$" > (org-map-entries > (lambda () > (unless (and inline-re (org-looking-at-p inline-re)) > (save-excursion > (let ((end (save-excursion (outline-next-heading) (point > (forward-line) > (when (org-looking-at-p org-planning-line-re) > (forward-line)) > (when (and (< (point) end) > (not (org-looking-at-p org-property-drawer-re)) > (save-excursion >(re-search-forward org-property-drawer-re end > t))) > (insert (delete-and-extract-region > (match-beginning 0) > (min (1+ (match-end 0)) end))) > (unless (bolp) (insert "\n" After heavy testing (on all my Org files, I mean) of the above function, it works perfectly except for the following corner-case (when there are Org properties in "quote" blocks): --8<---cut here---start->8--- * Reference Example of Custom ID: #+begin_verse ,* Some title :PROPERTIES: :CUSTOM_ID: SomeTitle :END: Lorem ipsum #+end_verse --8<---cut here---end--->8--- will be converted to: --8<---cut here---start->8--- * Reference :PROPERTIES: :CUSTOM_ID: SomeTitle :END: Example of Custom ID: #+begin_verse ,* Some title Lorem ipsum #+end_verse --8<---cut here---end--->8--- upon execution of `org-repair-property-drawers'. PS- I did not retest (yet) the same thing in #+begin/end_src blocks... as playing with that example files makes my Emacs eat 100% of the CPU (infloop?). I've restarted Emacs 5 or 6 times before being able to write this ECM... Best regards, Seb -- Sebastien Vauban
Re: [O] [RFC] Change property drawer syntax
Hello Nicolas, Nicolas Goaziou wrote: > Sebastien Vauban writes: > >> It does work perfectly on the "meta-stuff" (SCHEDULED, DEADLINE, >> etc.). Though, it moves as well the "body" text -- while I'm not >> using `org-indent-mode'. >> >> * New section >> >> ** The SCHED will be moved >>SCHEDULED: <2011-08-18 Thu> >> >> ** This one won't be moved along with the heading >> SCHEDULED: <2011-08-18 Thu> >> >> Because of this text here... >> ^ Space inserted here. > > This is expected, actually. I realize that `org-adapt-indentation' > docstring is not totally up-to-date. > > If your indentation shouldn't depend on the current headline level, > you might want to set this variable to nil. I've done that but, now, it does not support anymore the structure I had in all my Org files: --8<---cut here---start->8--- ** TODO Show typical Org entry SCHEDULED: <2014-11-08 Sat> :LOGBOOK: CLOCK: [2014-11-11 Tue 12:35]--[2014-11-11 Tue 14:19] => 1:44 :END: I have the planning lines and the drawers indented at the level of the entry. On the other hand, the "body text" of the entry always begins at column 0. This makes a clear distinction between "meta-stuff" and the contents of the entry itself. --8<---cut here---end--->8--- Now, with `org-adapt-indentation' set to `t', the whole "block" moves to the right when demoting, and to the left (except for the LOGBOOK drawer!? [1]) when promoting. With `org-adapt-indentation' set to `nil', nothing moves (but the headline), when demoting or promoting. Thanks for your help. Best regards, Seb [1] See http://screencast.com/t/nsGNuoHL. -- Sebastien Vauban
Re: [O] pdf images in html export
Hi Marco, Marco Wahl writes: > Andreas Leha writes: > >> how would I export an org file containing >> >> [[file:./myimage.pdf]] >> >> to html so that a say png version myimage.pdf is inlined in the html >> which links to the pdf? >> >> I guess it should be possible to run imagemagick on all pdf links during >> export somehow. > > You could introduce a relation of the pdf-filenames to the respective > thumb-filenames e.g. by using the suffix '_thumb'. Before the export > the conversion tool would create the thumbs. > > The org-file could reference the data as > > [[file:./myimage.pdf][file:myimage_thumb.png]] > > See the info page (info "(org)Images in HTML export")? > > Untested. I just accidentially browsed that info page yesterday. > > Thanks for your thoughts. I would like to automate all of that. So, I guess the first question is where to put code that would trigger the conversion and how to best detect links to pdfs. Thanks, Andreas
Re: [O] Inline code :results replace not working
"Charles C. Berry" wrote: > I find myself writing an inline src block, then typing `C-c C-c C-x u' to view > and then remove the result, then revise, and repeat. I'd be happy to just > leave > it in the document. What command are you calling with the above? Best regards, Seb -- Sebastien Vauban
[O] org-mobile-pull leaves a messed-up sparse tree display
Attached to this e-mail, please find an image of the appearance of one of my org buffers after doing org-mobile-pull. Before the pull, I collapsed all the subtrees (S-TAB once). The pull added some new nodes. The nodes appear to be filed correctly. But, it looks like org is trying to do some kind of sparse tree display, but it's hiding some line breaks that should not be hidden. If I collapse the subtrees and reopen them, then the display is correct. But then I lose any visual cues about where the new information got filed. I'd better hope that I remember where I put them... I'm extremely busy at the moment, not much time to hack up a reproducer. I'll do it if there's a fairly good chance that somebody will look at this bug. But I wanted to ask first what's the likelihood of getting it fixed. (If it's unlikely, then I'll reserve my time for other tasks.) Thanks, hjh
Re: [O] pdf images in html export
Andreas Leha writes: > how would I export an org file containing > > [[file:./myimage.pdf]] > > to html so that a say png version myimage.pdf is inlined in the html > which links to the pdf? > > I guess it should be possible to run imagemagick on all pdf links during > export somehow. You could introduce a relation of the pdf-filenames to the respective thumb-filenames e.g. by using the suffix '_thumb'. Before the export the conversion tool would create the thumbs. The org-file could reference the data as [[file:./myimage.pdf][file:myimage_thumb.png]] See the info page (info "(org)Images in HTML export")? Untested. I just accidentially browsed that info page yesterday. HTH, Marco
