Re: [O] org-tree-slide annoyance
Hi Henry, Thank you for using org-tree-slide and reporting the issue. Please use the following patch to avoid the error. PATCH: Replace the original code with (defun ots-display-tree-with-narrow () Show a tree with narrowing and also set a header at the head of slide. (goto-char (point-at-bol)) (when (ots-last-heading-position) (hide-subtree) ; support CONTENT (subtrees are shown) (org-show-entry) (show-children) (org-cycle-hide-drawers 'all) (org-narrow-to-subtree)) (setq display-tree-slide-string (if (equal org-tree-slide-modeline-display 'outside) (ots-count-slide (point)) )) (when org-tree-slide-slide-in-effect (ots-slide-in org-tree-slide-slide-in-brank-lines)) (when org-tree-slide-header (ots-show-slide-header))) This patch is a tentative code for checking behavior in your environments, but I think you will be able to open org files without heading. I'll update it again within a few days. Best, Takaaki 2013/7/15 Nick Dokos ndo...@gmail.com henry atts s...@online.de writes: Carsten Dominik carsten.domi...@gmail.com writes: On 15.7.2013, at 10:33, henry atts s...@online.de wrote: I use org-tree-slide-mode by default with (add-hook 'org-mode-hook 'org-tree-slide-mode) This works kind of acceptable minus some minor annoyances. But one thing makes it nearly unusuable. tree-slide rigidly expects at least one header. So if I open an org file without heading, or if I create a new one, I get an error message: File mode specification error: (error before first heading) If I include a setup file with `#+SETUPFILE:', which of course has no headings in it, org-tree-slide stops working at all. Hi Henry, you could wrap turning on of the mode into a function that checks if there is a node, and if not, just add one. - Carsten Okay, but on the one hand this doesn't solve the problem with `SETUPFILE'. On the other hand what if I want an org file without any heading on purpose? Or otherwise asked is a file a `real' org file only if it has headings in it? No, I don't think so, but there are bugs (there was a bug in the latex exporter once that required a heading at the beginning). I presume Carsten's suggestion was as a workaround to a bug (although I might have misinterpreted his comment). You might say if you want some features of orgmode _and_ an org file without heading you can always use, say, text-mode and load orgstruct as a minor mode. Which does not solve the problem as well because with the org-tree-mode hook for orgmode it shows some strange behaviour equally. I like org-tree-mode but I think it does not play well with orgmode in some cases. And as far as I see it even is not in contrib. Yes, I went looking for it there and did not find it :-) So maybe you can ping the author about the bug - s/he might even fix it, particularly now that the package is being used by at least one other person! Or contribute the fix yourself - if you like the package, then others might too, so it might even end up in contrib at some point. -- Nick
[O] Export of property key:value
I've been trying to get a handle on this the past couple of days since I
wanted to use column mode for revising properties and then export
(print) the subtree out showing those properties under the heading. I
understand that the exporter changed and now doesn't export the
properties drawer in total (and I think I understand why). It appears,
though, that I have to duplicate the syntax key: {{{property(key)}}}
for every subheading. It would seem to me that the simplest solution, at
least from the users perspective, would be to have a way to specify
certain property keys to be exported for a particular subtree but I
haven't found that option yet.
This is my simple example. Is there a simpler way to export the amount
property without duplicating amount: {{{property(amount)}}} in every
subheading?
#+OPTIONS: toc:nil d:t
* Buy stuff
:PROPERTIES:
:COLUMNS: %25ITEM %TODO %15amount(Amount){$}
:END:
** DONE Buy something
:PROPERTIES:
:amount: 1234.56
:END:
amount: {{{property(amount)}}}
** TODO Buy something else
:PROPERTIES:
:ID: db34ed38-7658-48b4-9770-9a572efcdb11
:amount: 5445.43
:END:
Re: [O] Export of property key:value
Hello,
Edward DeMeulle e...@demeulle.org writes:
This is my simple example. Is there a simpler way to export the amount
property without duplicating amount: {{{property(amount)}}} in every
subheading?
#+OPTIONS: toc:nil d:t
* Buy stuff
:PROPERTIES:
:COLUMNS: %25ITEM %TODO %15amount(Amount){$}
:END:
** DONE Buy something
:PROPERTIES:
:amount: 1234.56
:END:
amount: {{{property(amount)}}}
** TODO Buy something else
:PROPERTIES:
:ID: db34ed38-7658-48b4-9770-9a572efcdb11
:amount: 5445.43
:END:
You can use a hook (e.g., `org-export-before-processing-hook) to insert
amount : {{{property(amount)}}} (or with `org-entry-get', you don't
need the macro in that case) after each property drawer with an amount
property.
Regards,
--
Nicolas Goaziou
Re: [O] Should comments break paragraphs?
Christian Wittern cwitt...@gmail.com writes: On 2013-07-16 03:54, Nicolas Goaziou wrote: Yes. Comments are elements. Elements cannot be found in paragraphs. Hmm. In my book, the concept of comments implies that they should be able to appear on any line in the text, without altering the meaning of the context it appears in. So to me, it would seem necessary to treat comments as special, different from other elements. Just my 2 yen, I have to agree with you here: a comment should *not* impact on the result, because if it does, it is not a comment anymore, but a command. It should be exported in the exporter as either a comment in the resulting document (e.g %% in LaTeX, a comment or note in odt, ...) or ignored in the exported document, but definitely not have an impact on the *layout* of the document. Cheers, Rainer Christian -- Rainer M. Krug email: RMKrugatgmaildotcom pgpuz86KjgPd_.pgp Description: PGP signature
Re: [O] Should comments break paragraphs?
Hello, Christian Wittern cwitt...@gmail.com writes: Hmm. In my book, the concept of comments implies that they should be able to appear on any line in the text, without altering the meaning of the context it appears in. So to me, it would seem necessary to treat comments as special, different from other elements. I don't think comments make much sense anywhere in Org (e.g., in an example block or in a source block). Also Org has no inline comment syntax (and I don't think it needs one: it is no programming language). So comments do not really fit in paragraphs. Last, but not least, it is also easier to parse it that way. Now, if you want to improve comments anyway, you can always provide patches. There's some non-trivial work involved, though. Regards, -- Nicolas Goaziou
Re: [O] Can't export in 7.8.11 and can't get 8.0.4 to work
Hi Paul, Paul Whipp paul.wh...@gmail.com writes: If I use the package installer to upgrade org I get version 8.0.4 but it then fails to complete my initialisation with: Symbol's function definition is void: org-defvaralias Please share the parts of your configuration that are relevant to this, e.g. your package initialization and your Org initialization. Thanks, -- Bastien
Re: [O] Should comments break paragraphs?
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Christian Wittern cwitt...@gmail.com writes: Hmm. In my book, the concept of comments implies that they should be able to appear on any line in the text, without altering the meaning of the context it appears in. So to me, it would seem necessary to treat comments as special, different from other elements. I don't think comments make much sense anywhere in Org (e.g., in an example block or in a source block). Also Org has no inline comment syntax (and I don't think it needs one: it is no programming language). So comments do not really fit in paragraphs. I see comments as entities which do not have any impact on the final product. If you regard the org file as the final product, then I completely agree (I use org mainly for literate programming, and I don't use any comments unless in linger code blocks, but that is not in org). But if I use org for writing e.g. presentations in beamer, I might want to add comments which should not be on the product (slides, article, handout, ...) but which contain info in the org file. So we are talking different levels here. Cheers, Rainer Last, but not least, it is also easier to parse it that way. Now, if you want to improve comments anyway, you can always provide patches. There's some non-trivial work involved, though. Regards, -- Rainer M. Krug email: RMKrugatgmaildotcom pgpHXDk6bqTgo.pgp Description: PGP signature
Re: [O] Should comments break paragraphs?
Hello, Rainer M Krug rai...@krugs.de writes: I see comments as entities which do not have any impact on the final product. If you regard the org file as the final product, then I completely agree (I use org mainly for literate programming, and I don't use any comments unless in linger code blocks, but that is not in org). But if I use org for writing e.g. presentations in beamer, I might want to add comments which should not be on the product (slides, article, handout, ...) but which contain info in the org file. So we are talking different levels here. Comments do not alter the final product: they are ignored during export. But there are places where you cannot have comments, at all. If we look at the following example, similar to OP's: Some text # comment Some other text comment do not split the paragraph: there were two paragraphs since the beginning (but still no spoon). It's only disturbing if you think comments can be inserted within paragraphs, which is not the case. This may not be perfect, but, as for me, it's good enough. Another option would be to remove every comment line before parsing the buffer (which is, IIRC, what previous exporter did), but it would only hide the situation for a while. After all I could expect to have comments anywhere, including some places like * Headline # Between an headline and planning info. Update org-agenda.el. SCHEDULED: 2013-07-16 Tue - item 1 # Some comment between items. Update org-list.el - item 2 #+HEADER: var=2 # A comment between affiliated keywords and true data. Update ob-core.el. #+RESULTS: some-table | a | | a | b | # Comments within rows. Update org-table.el | c | d | And then, the situation would appear again: it's not just about the parser or the exporter. Every part of Org would have to handle comments differently. Again, I think comments are acceptable, once you are aware about their limitations. But, I don't prevent you from opening that can of worms. Regards, -- Nicolas Goaziou
Re: [O] Problems with LaTeX source block
Hi Andreas, I forgot to send the following remarks in my previous
post.
I encounter a problem with pgfplots. The following works, and produces a
png with a white background
#+NAME: python-tikz
#+header: :results raw :file py2tikz_sin.png
#+header: :imagemagick yes :fit yes :headers '(\\usepackage{tikz,pgfplots})
#+BEGIN_SRC latex :exports results
\begin{tikzpicture}
\begin{axis}
\draw [green,-] (0,0) -- (2,2) -- (3,1);
\end{axis}
\end{tikzpicture}
#+END_SRC
However, the following produces a png with only the axis displayed (but
the boundaries are wrong), the data points don't appear. Strangely, the
png produced is transparent: the background is the one of the Emacs buffer.
#+NAME: python-tikz
#+header: :results raw :file py2tikz_sin.png
#+header: :imagemagick yes :fit yes :headers '(\\usepackage{tikz,pgfplots})
#+BEGIN_SRC latex :exports results
\begin{tikzpicture}
\begin{axis}
\addplot [red,only lines] table {sin_py2csv.csv};
\end{axis}
\end{tikzpicture}
#+END_SRC
The temp latex file seems ok (pdflatex produces a correct picture). I
couldn't find the command line for imagemagick conversion to png to test
it though.
Julien.
Re: [O] Problems with LaTeX source block
Hi Julien,
Julien Cubizolles j.cubizol...@free.fr writes:
Hi Andreas, I forgot to send the following remarks in my previous
post.
I encounter a problem with pgfplots. The following works, and produces a
png with a white background
#+NAME: python-tikz
#+header: :results raw :file py2tikz_sin.png
#+header: :imagemagick yes :fit yes :headers '(\\usepackage{tikz,pgfplots})
#+BEGIN_SRC latex :exports results
\begin{tikzpicture}
\begin{axis}
\draw [green,-] (0,0) -- (2,2) -- (3,1);
\end{axis}
\end{tikzpicture}
#+END_SRC
However, the following produces a png with only the axis displayed (but
the boundaries are wrong), the data points don't appear. Strangely, the
png produced is transparent: the background is the one of the Emacs buffer.
#+NAME: python-tikz
#+header: :results raw :file py2tikz_sin.png
#+header: :imagemagick yes :fit yes :headers '(\\usepackage{tikz,pgfplots})
#+BEGIN_SRC latex :exports results
\begin{tikzpicture}
\begin{axis}
\addplot [red,only lines] table {sin_py2csv.csv};
\end{axis}
\end{tikzpicture}
#+END_SRC
The temp latex file seems ok (pdflatex produces a correct picture). I
couldn't find the command line for imagemagick conversion to png to test
it though.
The problem is in your external data file, I guess.
What happens, is that org creates a temporary tex file in a temporary
directory (it is in /tmp/babel-sth under Linux) and compiles this tex
file there. At that directory your sin_py2csv.csv is not present.
So, one quick remedy should be to use an absolute path to the csv.
Regards,
Andreas
Re: [O] Should comments break paragraphs?
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Rainer M Krug rai...@krugs.de writes: I see comments as entities which do not have any impact on the final product. If you regard the org file as the final product, then I completely agree (I use org mainly for literate programming, and I don't use any comments unless in linger code blocks, but that is not in org). But if I use org for writing e.g. presentations in beamer, I might want to add comments which should not be on the product (slides, article, handout, ...) but which contain info in the org file. So we are talking different levels here. Comments do not alter the final product: they are ignored during export. But there are places where you cannot have comments, at all. If we look at the following example, similar to OP's: Some text # comment Some other text comment do not split the paragraph: there were two paragraphs since the beginning (but still no spoon). It's only disturbing if you think comments can be inserted within paragraphs, which is not the case. I think I see what you mean: if the comment would not be there, the text would look as follow: , | Some text | | Some other text ` for the exporter. So the comment here , | Some text | # comment | Some other text ` is ignored, but not the empty line resulting - is this correct? I think the confusion is that comments in org are between comment lines and inline comments in this regard. This may not be perfect, but, as for me, it's good enough. [snip: examples (24 lines)] Again, I think comments are acceptable, once you are aware about their limitations. But, I don't prevent you from opening that can of worms. Don't worry - I am happy as it stands now and have no complains. Regards, Cheers, Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom pgphSyn1BKEbt.pgp Description: PGP signature
Re: [O] Should comments break paragraphs?
Rainer M Krug rai...@krugs.de writes: Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Rainer M Krug rai...@krugs.de writes: I see comments as entities which do not have any impact on the final product. If you regard the org file as the final product, then I completely agree (I use org mainly for literate programming, and I don't use any comments unless in linger code blocks, but that is not in org). But if I use org for writing e.g. presentations in beamer, I might want to add comments which should not be on the product (slides, article, handout, ...) but which contain info in the org file. So we are talking different levels here. Comments do not alter the final product: they are ignored during export. But there are places where you cannot have comments, at all. If we look at the following example, similar to OP's: Some text # comment Some other text comment do not split the paragraph: there were two paragraphs since the beginning (but still no spoon). It's only disturbing if you think comments can be inserted within paragraphs, which is not the case. I think I see what you mean: if the comment would not be there, the text would look as follow: , | Some text | | Some other text ` for the exporter. So the comment here , | Some text | # comment | Some other text ` is ignored, but not the empty line resulting - is this correct? I think the confusion is that comments in org are between comment lines and inline comments in this regard. In that case, I guess some confusion might come from LaTeX, for example, where also the newline is ignored by the comment, s.t. in LaTeX , | Some text | % comment | Some other text ` is interpreted as , | Some text | Some other text ` [...] IMO, there is no 'feature' in the 'paragraph breaking' comments in org. But I understand that it is quite hard to change that behaviour. Regards, Andreas
Re: [O] Should comments break paragraphs?
Another option would be to remove every comment line before parsing the buffer (which is, IIRC, what previous exporter did), but it would only hide the situation for a while. After all I could expect to have comments anywhere, including some places like On your example, why wouldn't it work if we remove comments before exporting ? Fabrice
Re: [O] Should comments break paragraphs?
Rainer M Krug rai...@krugs.de writes: I think I see what you mean: if the comment would not be there, the text would look as follow: , | Some text | | Some other text ` for the exporter. So the comment here , | Some text | # comment | Some other text ` is ignored, but not the empty line resulting - is this correct? I think the confusion is that comments in org are between comment lines and inline comments in this regard. You can replace the comment by a blank line, or a fixed-width area, or a table... It may be better to think it that way: # syntax introduces a commented paragraph, not a comment line. Regards, -- Nicolas Goaziou
Re: [O] Should comments break paragraphs?
2013/7/16 Fabrice Popineau fabrice.popin...@supelec.fr Another option would be to remove every comment line before parsing the buffer (which is, IIRC, what previous exporter did), but it would only hide the situation for a while. After all I could expect to have comments anywhere, including some places like On your example, why wouldn't it work if we remove comments before exporting ? Ok. Understood thanks to Rainer's message. However, it would still be useful to be able to comment some line of text in the middle of a paragraph. This is only an example. I agree that the usual meaning of comments is that they shouldn't have an impact on the output. But Org is almost a 2D language. Fabrice
Re: [O] Should comments break paragraphs?
Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: In that case, I guess some confusion might come from LaTeX, for example, where also the newline is ignored by the comment, s.t. in LaTeX , | Some text | % comment | Some other text ` is interpreted as , | Some text | Some other text ` Comparing Org and LaTeX is like comparing apples and oranges: it can only lead to false assumptions and cloud thinking. IMO, there is no 'feature' in the 'paragraph breaking' comments in org. But I understand that it is quite hard to change that behaviour. Just to be clear. I didn't talk about a feature. I merely described the state of affairs, and added that, albeit not perfect, it seemed good enough to me. Regards, -- Nicolas Goaziou
Re: [O] Should comments break paragraphs?
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: In that case, I guess some confusion might come from LaTeX, for example, where also the newline is ignored by the comment, s.t. in LaTeX , | Some text | % comment | Some other text ` is interpreted as , | Some text | Some other text ` Comparing Org and LaTeX is like comparing apples and oranges: it can only lead to false assumptions and cloud thinking. Agreed. I just wanted to mention one possible source of such false assumptions. IMO, there is no 'feature' in the 'paragraph breaking' comments in org. But I understand that it is quite hard to change that behaviour. Just to be clear. I didn't talk about a feature. I merely described the state of affairs, and added that, albeit not perfect, it seemed good enough to me. I hope I did not offend you with that paragraph. I did not want to say that you called it a feature. If was merely a summary of the thread, as I understood it. I actually never ran into the problem myself, as I do not comment too much in my org files. So I am in the 'good enough' group as well. Regards, Andreas
[O] Please Comment: a potential Innovation about proviewing latex fragement with imagemagick
* Approach of previewing latex fragement with imagemagick is like this:
** The original:
1. (emacs buffer font height) - (evalue a density value) -- (imagemagick
destiny option)
2. (latex fragement) -- (tmp latex file) - (pdf) - (png) ( convert with
above destiny option)
** Advantages
1. It works well at the moment.
** disadvantages
2. we get the formula about (font height - density value) by test and test
and test...
** A pontential approach:
1. (emacs buffer font height) - (latex macros;
\fontsize{font-size}{fontsize*1.2}) - (insert tmp latex file )- pdf -
png( convert with fixed density, for example: 96)
** Advantages
1. More intuition
2. This approach may be used the feature p-with-dvipng, by using this
approach,
Maybe we can code a common function shared with imagemagick ang dvipng.
** disadvantages
1. depend latex command \fontsize.
Any comment?
Feng Shu
Re: [O] [bug?] Copy content from one to another table changes the content
Hi again, I think I got a bit more of an idea what is going wrong thanks to Nick. I use $1 = remote(prf94120_orig, @@#$6) which reads copy from table prf94120_orig row (@) of the current to be processed field (@#) column ($) 6 into column ($) 1. The org-mode manual refers to @# as operator for formulas and hence I believe the result will be parsed by calc to get a meaningful output. That is ok for simple strings without space or comma separators, since they remain strings. However, a string like text,text will be send to calc as (text,text) which is the calc notation for imaginary numbers. Either, I should use a different way to copy the column or this could be considered as a bug?! Actually, I still do not understand the need to let calc parse that a field-content. If I want to do math, I am not suppose to express this explicit by my formula? Instead of having a single field content of 1 + 2 evaluated to be 3 by remote copy, I would expect to do something like remote(NAME, REF) + remote(NAME, REF) for calculating the sum of two remote fields or in case I really have a complete expression in a single field, I would expect to do something like (calc remote(NAME, REF)) explicit to get it parsed by calc and placing the result in the new table?! Somehow, I miss something. Would be glad if someone could explain to me the reason for the original behaviour. Thanks Torsten On 15 July 2013 15:36, Nick Dokos ndo...@gmail.com wrote: Torsten Wagner torsten.wag...@gmail.com writes: I can confirm that behaviour for org-mode 8.0 (tested on 7.9.3f) if that matter. Furtermore, I tested a lot of alternatives. lastname, firstname lastname, firstname lastname; firstname etc. It seems, they all get somehow evaluated by calc, which ends up in funny different results. I do not understand what was the intention of letting the code be parsed by calc but it seems to cause trouble. As I said, I don't know much about the implementation of tables, but I think passing every entry in the table through calc is by design. And it does not need to cause trouble either: (calc-eval abc, def) --- abc, def So trying to selectively *not* pass a cell through calc seems to be the wrong way to go. Will test to comment how to get around it Thanks Torsten On 15 July 2013 11:43, Torsten Wagner torsten.wag...@gmail.com wrote: Hi Nick, very good observation. Just wonder are we the first who observe this problem?! It seems org-table-make-reference and calc-eval have some sort of an different idea of the data content. Yes calc use that notation to deal with imaginary numbers. Funny coincidence, the students in that list just struggle with exactly those imaginary numbers and now there names became a imaginary number itself... ;) Thanks for the tip, I will see if some search and replace helps me to create a intermediate solution. Thanks Torsten On 14 July 2013 05:29, Nick Dokos ndo...@gmail.com wrote: Torsten Wagner torsten.wag...@gmail.com writes: I just notice a strange behaviour within tables. I want to copy a column of one table into another... using $1=remote(prf94120_orig, @@#$6). The original content consist of names in the form lastname,firstnames. However, executing the above formular I receive lastname + firstnames i I have totally no clue what is the reason for that a bug?! Happens within Org-mode version 8.0.3 I tried it (on a single table too - no remote) and I get the same behavior. I can't pretend to understand how anything in org-table.el works, but I think this is a clue: on line 2678, org-table-make-reference is called. If I call it by hand like this (org-table-make-reference a, b nil nil nil) -- (a, b) Then on line 2706, calc-eval is called. If I call it by hand on the value above (calc-eval (a, b)) -- a + b i I think it's trying to do arithmetic on complex numbers... -- Nick -- Nick
Re: [O] Problems with LaTeX source block
Julien Cubizolles j.cubizol...@free.fr writes:
[...]
However, the following produces a png with only the axis displayed (but
the boundaries are wrong), the data points don't appear. Strangely, the
png produced is transparent: the background is the one of the Emacs buffer.
Interesting. I have this behaviour as well in terms of background. I
use a dark theme on all of my windows, be they emacs or xterms. The png
generated by imagemagick sets the background to transparent which means
I cannot see the images produced as the actual drawing and text are
black.
I am happy with this: just had to remember to set the drawing colour to
white by \begin{tikzpicture}[white].
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.5-337-g9f3bed
Re: [O] tikz for multiple targets
Hi Eric et al.,
I now have a system I am happy with mostly for using LaTeX code blocks
heading to multiple export targets. The solution I am using is a
combination of what has been discussed in this thread (by-backend
customisation of headers for babel) and using noweb substitution for the
main content. I have two LaTeX babel source blocks, one for PDF export
and the other for HTML export. Each of these has a tikzpicture
environment which then includes the actual instructions for drawing
brought in using noweb.
The problem I have remaining is how to get the version used to export to
PDF via LaTeX to use a figure environment with captioning. I had
thought that something along these lines would work:
#+begin_src org
,#+name: picturecontents
,#+begin_src latex :noweb yes :exports none
\node[red!50!black] (a) {A};
\node (b) [right of=a] {B};
\draw[-] (a) -- (b);
,#+end_src
,#+name: flowdiagram
,#+header: :exports (if (and (boundp 'backend) (eq (org-export-backend-name
backend) (intern latex))) results none)
,#+header: :results latex
,#+header: :noweb yes
,#+begin_src latex
\begin{tikzpicture}
picturecontents
\end{tikzpicture}
,#+end_src
,#+caption: Testing figure caption for figure going to multiple destinations
,#+results: flowdiagram
#+end_src
as I expected the export to put the results of the flowdiagram code
block after the results line. This doesn't work: the exported LaTeX
has no figure environment etc. The diagram does come out but it is
placed directly into the document.
I hope this all makes sense? Any suggestions?
thanks,
eric
--
: Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.5-337-g9f3bed
Re: [O] tikz for multiple targets
Hi Eric,
Eric S Fraga e.fr...@ucl.ac.uk writes:
Hi Eric et al.,
I now have a system I am happy with mostly for using LaTeX code blocks
heading to multiple export targets. The solution I am using is a
combination of what has been discussed in this thread (by-backend
customisation of headers for babel) and using noweb substitution for the
main content. I have two LaTeX babel source blocks, one for PDF export
and the other for HTML export. Each of these has a tikzpicture
environment which then includes the actual instructions for drawing
brought in using noweb.
The problem I have remaining is how to get the version used to export to
PDF via LaTeX to use a figure environment with captioning. I had
thought that something along these lines would work:
#+begin_src org
,#+name: picturecontents
,#+begin_src latex :noweb yes :exports none
\node[red!50!black] (a) {A};
\node (b) [right of=a] {B};
\draw[-] (a) -- (b);
,#+end_src
,#+name: flowdiagram
,#+header: :exports (if (and (boundp 'backend) (eq (org-export-backend-name
backend) (intern latex))) results none)
,#+header: :results latex
,#+header: :noweb yes
,#+begin_src latex
\begin{tikzpicture}
picturecontents
\end{tikzpicture}
,#+end_src
,#+caption: Testing figure caption for figure going to multiple destinations
,#+results: flowdiagram
#+end_src
as I expected the export to put the results of the flowdiagram code
block after the results line. This doesn't work: the exported LaTeX
has no figure environment etc. The diagram does come out but it is
placed directly into the document.
I hope this all makes sense? Any suggestions?
thanks,
eric
I actually think, that it would be cool, if latex supported the tikz
output as R does.
But since you have a dedicated latex export-only block, the simplest
solution would be to put the caption inside:
--8---cut here---start-8---
#+latex_header: \usepackage{tikz}
#+latex_header: \usepackage{hyperref}
* Test
#+name: picturecontents
#+begin_src latex :noweb yes :exports none
\node[red!50!black] (a) {A};
\node (b) [right of=a] {B};
\draw[-] (a) -- (b);
#+end_src
#+name: flowdiagram
#+header: :exports (if (and (boundp 'backend) (eq (org-export-backend-name
backend) (intern latex))) results none)
#+header: :results latex
#+header: :noweb yes
#+begin_src latex
\begin{figure}
\begin{tikzpicture}
picturecontents
\end{tikzpicture}
\caption{Testing figure caption for figure going to multiple destinations}
\end{figure}
#+end_src
--8---cut here---end---8---
Regards,
Andreas
Re: [O] [Patch] ob-ditaa.el for Cygwin
Hi, Achim Thanks for your suggestion. Yes, a wrapper script will also work. I will use such a script if Org doesn't consider the Cygwin issue. Regards, Yujie 2013/7/16 Achim Gratz strom...@nexgo.de Yujie Wen writes: Could someone please take a look and, if it is satisfactory, please help to apply it? You're missing a Changelog and emacs-p might better be called cygwin-p. More to the point: I don't think Org should care about such system idiosyncrasies at all. Instead you might use a wrapper script for Cygwin that converts the arguments and then calls the native Windows java executable. I am used to Orgmode under Cygwin and sometimes uses ditaa for drawing diagrams. But without this patch, I have to switch to Windows native Emacs for calling ditaa. If there's anything to do on the Org side then removing the still hardcoded call of java. 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
Re: [O] [bug?] Copy content from one to another table changes the content
Hi Torsten On Tue, Jul 16, 2013 at 12:24 PM, Torsten Wagner torsten.wag...@gmail.com wrote: Either, I should use a different way to copy the column or this could be considered as a bug?! Some time ago I did some experiments about just copying a field that I put into the ERT function test-org-table/copy-field in testing/lisp/test-org-table.el for documentation. The Calc variants there are more for fun than useful. The Lisp variant: #+TBLFM: $1 = '(identity remote(prf94120_orig, @@#$6)) test-org-table.el on the Web: http://orgmode.org/w/org-mode.git?p=org-mode.git;a=blob;f=testing/lisp/test-org-table.el Michael
[O] clock adjustments
Are there any keystrokes/functions built in that would let me adjust the time between to tasks auto-magically. I mean, I just worked on task B, after finishing task A, but forgot to clock out of task A and into task B. Is there anything I can do while on task B that would let me incrementally steal time from task A? Dave
Re: [O] Problems with LaTeX source block
The following message is a courtesy copy of an article that has been posted to gmane.emacs.orgmode as well. Hi Andreas Andreas Leha andreas.l...@med.uni-goettingen.de writes: The problem is in your external data file, I guess. What happens, is that org creates a temporary tex file in a temporary directory (it is in /tmp/babel-sth under Linux) and compiles this tex file there. At that directory your sin_py2csv.csv is not present. So, one quick remedy should be to use an absolute path to the csv. You were right, using the whole path for the data file fixed this problem. It would be convenient to have the PATH of the org file added to some TEXMF path prior to compilation to address this issue. Thanks for your help, Julien.
Re: [O] Problems with LaTeX source block
Hi Eric,
Eric S Fraga e.fr...@ucl.ac.uk writes:
Interesting. I have this behaviour as well in terms of background. I
use a dark theme on all of my windows, be they emacs or xterms. The png
generated by imagemagick sets the background to transparent which means
I cannot see the images produced as the actual drawing and text are
black.
I am happy with this: just had to remember to set the drawing colour to
white by \begin{tikzpicture}[white].
The background/foreground are supposed to be changed by setting the
:buffer yes header and by customizing org-format-latex-options. I didn't
try it though, I'm happy with the [white] option to tikzpicture.
However, I noticed something odd. If I use the following headers
--8---cut here---start-8---
#+header: :results raw :file py2tikz_sin.png
#+header: :imagemagick yes :fit yes :headers '(\\usepackage{tikz,pgfplots})
#+header: :iminoptions -density 600 :imoutoptions -geometry 400
--8---cut here---end---8---
the png is transparent. If I remove the last line:
--8---cut here---start-8---
#+header: :results raw :file py2tikz_sin.png
#+header: :imagemagick yes :fit yes :headers '(\\usepackage{tikz,pgfplots})
--8---cut here---end---8---
I get the white background back, although in both cases, imagemagick is
used.
Julien.
[O] import R data frame into org-mode table
I have an R script that generates a data frame, that I export to a CSV file. The data looks something like this: ,Variant,Xaxis,N,mean,sd,se 1,line1,10,5,111.11,9.33,3.11 1,line1,20,5,112.11,9.13,3.14 1,line1,30,5,113.11,9.43,3.10 1,line2,10,5,101.11,8.33,2.11 1,line2,20,5,100.11,8.13,2.12 1,line2,30,5,108.11,8.03,2.10 I have an ongoing org-mode document in which I'd like to report this data. I'd like to add a table that looks something like this: | Variant | X Axis | Y Axis | N | Mean | Standard Deviation | Standard Error | || The data will change frequently over the coming months. I'd like org-mode to auto-magically read a CSV file, to construct my org-table on-the-fly. I'd hoping to avoid copying and pasting results each time. Is there some org-mode or emacs+ESS magic I can use to populate my empty table, with source data from my CSV file? -- Rob
Re: [O] tikz for multiple targets
Andreas Leha andreas.l...@med.uni-goettingen.de writes: [...] But since you have a dedicated latex export-only block, the simplest solution would be to put the caption inside: D'uh! That is so obvious (in hindsight ;-) blush... thanks! -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.5-337-g9f3bed
Re: [O] clock adjustments
da...@adboyd.com (J. David Boyd) writes: Are there any keystrokes/functions built in that would let me adjust the time between to tasks auto-magically. I mean, I just worked on task B, after finishing task A, but forgot to clock out of task A and into task B. Is there anything I can do while on task B that would let me incrementally steal time from task A? Dave Just found my own answer: S-M-UP/DOWN (org-timestamp-up/down) On CLOCK log lines, increase/decrease the timestamp at point and the one of the previous (or the next clock) timestamp by the same duration. For example, if you hit S-M-UP to increase a clocked-out timestamp by five minutes, then the clocked-in timestamp of the next clock will be increased by five minutes.
Re: [O] Should comments break paragraphs?
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Christian Wittern cwitt...@gmail.com writes: Hmm. In my book, the concept of comments implies that they should be able to appear on any line in the text, without altering the meaning of the context it appears in. So to me, it would seem necessary to treat comments as special, different from other elements. I don't think comments make much sense anywhere in Org (e.g., in an example block or in a source block). Also Org has no inline comment syntax (and I don't think it needs one: it is no programming language). So comments do not really fit in paragraphs. When Org-mode is used as a document preparation language inline comments are very useful. The use case being notes on the surrounding material which are not to be published. Both HTML and LaTeX support comments and at least in LaTeX they are extensively used (in my experience) and can be very helpful. Last, but not least, it is also easier to parse it that way. Stripping lines starting with ^ *#[^+] is a trivial pre-processing step, and would support the traditional Org-mode comments which (as I recall) could previously appear mid paragraph without causing problems. Now, if you want to improve comments anyway, you can always provide patches. There's some non-trivial work involved, though. The attached patch worked on some small example files for me. From ce4c30ebe56d4cd66810bca48824d8841e7b130d Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Tue, 16 Jul 2013 09:44:59 -0600 Subject: [PATCH] support inline comments w/o breaking paragraphs * lisp/org-element.el (org-element-parse-buffer): Strip inline comments as a pre-processing step before exporting. --- lisp/org-element.el | 20 +--- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index 8d64657..d69d9ba 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -4092,13 +4092,19 @@ or objects within the parse tree. This function assumes that current major mode is `org-mode'. (save-excursion -(goto-char (point-min)) -(org-skip-whitespace) -(org-element--parse-elements - (point-at-bol) (point-max) - ;; Start in `first-section' mode so text before the first - ;; headline belongs to a section. - 'first-section nil granularity visible-only (list 'org-data nil +(let ((save (buffer-string))) + (unwind-protect + (progn + (goto-char (point-min)) + (delete-matching-lines ^ *# .[^\n]*\n) + (org-skip-whitespace) + (org-element--parse-elements + (point-at-bol) (point-max) + ;; Start in `first-section' mode so text before the first + ;; headline belongs to a section. + 'first-section nil granularity visible-only (list 'org-data nil))) + (delete-region (point-min) (point-max)) + (insert save) (defun org-element-parse-secondary-string (string restriction optional parent) Recursively parse objects in STRING and return structure. -- 1.8.3.2 Cheers, Regards, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Should comments break paragraphs?
Hello, Eric Schulte schulte.e...@gmail.com writes: When Org-mode is used as a document preparation language inline comments are very useful. The use case being notes on the surrounding material which are not to be published. Both HTML and LaTeX support comments and at least in LaTeX they are extensively used (in my experience) and can be very helpful. Again, Org is neither LaTeX nor HTML. Stripping lines starting with ^ *#[^+] is a trivial pre-processing step, and would support the traditional Org-mode comments which (as I recall) could previously appear mid paragraph without causing problems. The attached patch worked on some small example files for me. As I explained in a previous post, it's only a kludge hiding the real problem: comments cannot appear anywhere, even if we don't take export into account. Actually, handling comments during export is the easiest part of the problem. From ce4c30ebe56d4cd66810bca48824d8841e7b130d Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Tue, 16 Jul 2013 09:44:59 -0600 Subject: [PATCH] support inline comments w/o breaking paragraphs * lisp/org-element.el (org-element-parse-buffer): Strip inline comments as a pre-processing step before exporting. The parser is unrelated to the export process, so export pre-processing shouldn't happen in org-element.el. Also, parsing a buffer mustn't modify it in the process. Even if you move it to ox.el, this is not an acceptable solution. Think about the following example - item 1 # with a comment - item 2 If you simply delete matching lines, you break the list. Regards, -- Nicolas Goaziou
Re: [O] Should comments break paragraphs?
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Eric Schulte schulte.e...@gmail.com writes: When Org-mode is used as a document preparation language inline comments are very useful. The use case being notes on the surrounding material which are not to be published. Both HTML and LaTeX support comments and at least in LaTeX they are extensively used (in my experience) and can be very helpful. Again, Org is neither LaTeX nor HTML. I did not intend to suggest that Org was either LaTeX or HTML. Org-mode is a document preparation system, and I think there is a strong motivation for the inline comment use case in any document preparation system. Stripping lines starting with ^ *#[^+] is a trivial pre-processing step, and would support the traditional Org-mode comments which (as I recall) could previously appear mid paragraph without causing problems. The attached patch worked on some small example files for me. As I explained in a previous post, it's only a kludge hiding the real problem: comments cannot appear anywhere, even if we don't take export into account. So are you proposing to remove comments from Org-mode entirely? I think this would be a significant regression. Actually, handling comments during export is the easiest part of the problem. Yes, I can see how teaching e.g., the new list parser to ignore comments could be tricky. From ce4c30ebe56d4cd66810bca48824d8841e7b130d Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Tue, 16 Jul 2013 09:44:59 -0600 Subject: [PATCH] support inline comments w/o breaking paragraphs * lisp/org-element.el (org-element-parse-buffer): Strip inline comments as a pre-processing step before exporting. The parser is unrelated to the export process, so export pre-processing shouldn't happen in org-element.el. Also, parsing a buffer mustn't modify it in the process. But if we treat comments as semantically empty, then maybe they should be ignored by the parser? Even if you move it to ox.el, this is not an acceptable solution. Think about the following example - item 1 # with a comment - item 2 If you simply delete matching lines, you break the list. Yes, I would argue that this list should be broken, because with or without the comment the items are separated by two blank lines. In my opinion comments as semantically empty lines is a simple rule for both users and parsers to understand. Cheers, Regards, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Should comments break paragraphs?
Nicolas Goaziou n.goaz...@gmail.com writes: Hello, Andreas Leha andreas.l...@med.uni-goettingen.de writes: In that case, I guess some confusion might come from LaTeX, for example, where also the newline is ignored by the comment, s.t. in LaTeX , | Some text | % comment | Some other text ` is interpreted as , | Some text | Some other text ` Comparing Org and LaTeX is like comparing apples and oranges: it can only lead to false assumptions and cloud thinking. True but the original three lines (text, comment, text) gets exported differently to LaTeX and to HTML. The former results in one paragraph; the latter in two. So even though you may treat the two text lines as separate elements in the parser, the LaTeX output is as if they were one element as there is no blank line between them (LaTeX's paragraph separator). But I'm happy with how things are! I export to LaTeX mostly and comments basically act as inline comments when they sit between two normal paragraphs. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.3.50.1, Org release_8.0.5-337-g9f3bed
Re: [O] [PATCH] org-contacts: Update contacts cache if it contains markers with no buffer
Øyvind Stegard oyvi...@ifi.uio.no writes: Hi list, Hello, In contrib/lisp/org-contacts.el: The function `org-contacts-db-need-update-p' does two checks to determine if the contacts cache should be updated: 1. If the variable `org-contacts-last-update' is nil. 2. If modification time of any file containing contacts is more recent than timestamp recorded in `org-contacts-last-update'. There is another case where an update is required: when marker objects contained in the contact cache `org-contacts-db' suddenly point to no buffer. If a buffer containing contacts is killed, but underlying file is not modified, org-contacts will not detect this, and cached markers that pointed to the now killed buffer will become dead (have no buffer associated with them). This seems to cause problems at least in `org-contacts-anniversaries', which if used as diary sexp in an agenda file, will cause Bad sexp errors. I have not done any thorough analysis of `org-contacts-anniversaries' itself, but it seems to work OK whenever the markers in `org-contacts-db' are OK. And it looks like the markers are used in that code. To reproduce: 1. Load up org-contacts and do a query with M-x org-contacts. 2. Kill at least one org-buffer containing a contact with BIRTHDAY property set (but do not save underlying file). 3. Make sure to use %%(org-contacts-anniversaries) in some agenda file. 4. Opening agenda should produce a Bad sexp error. I've attached a patch (against git master) which I am currently using. It will cause org-contacts to re-load if a marker is found in cache that points to no buffer. This looked to me like the quickest approach for fixing it without getting to know org-contacts.el better. Thanks for the bug report! Don't you think that checking if one of the buffer would be enough and faster? With something like (every #'get-file-buffer org-contacts-files) Regards, Øyvind -- Daimrod/Greg signature.asc Description: PGP signature
Re: [O] Should comments break paragraphs?
Eric Schulte schulte.e...@gmail.com writes:
So are you proposing to remove comments from Org-mode entirely?
Certainly not.
I'm on the good enough side and I simply suggest to live with it.
Also, if you badly need inline comments, there's the empty comment
macro:
#+MACRO: comment
Some text {{{comment(This is my comment)}}} and some more.
But if we treat comments as semantically empty, then maybe they should
be ignored by the parser?
Yes, we can ignore them at the parser level. But what about the rest of
Org? There are many places that do not rely on the parser and do not
ignore comments (lists being an example, agenda being another one, and
I'm pretty sure comments at some locations can break Babel too).
Something could be done, but again, it would certainly not be
a one-liner in org-element.el or ox.el.
Even if you move it to ox.el, this is not an acceptable solution. Think
about the following example
- item 1
# with a comment
- item 2
If you simply delete matching lines, you break the list.
Yes, I would argue that this list should be broken, because with or
without the comment the items are separated by two blank lines.
On the other hand, visually, this list looks perfectly correct.
In my opinion comments as semantically empty lines is a simple rule
for both users and parsers to understand.
Comments are already almost semantically empty lines. That's why:
Text
# Comment
Other Text
generates two paragraphs in Org (and in every back-end excepted `latex',
but that's a different problem). They basically act as a paragraph
separator, much like blank lines.
Also, note that if they really are empty lines, they cannot be inlined
within paragraphs either.
Regards,
--
Nicolas Goaziou
Re: [O] Orgmode fails to export specific web-links as latex/pdf
A quick related observation. Consider this Org-mode link:
[[https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(%C2%AB%D0%9F%D1%96%D1%81%D0%BD%D1%8F_%D0%BF%D1%80%D0%B8_%D0%BA%D0%BE%D0%BB%D0%B8%D1%81%D1%86%D1%96%C2%BB).ogg][https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(«Пісня_при_колисці»).ogg]]
The LaTeX code it generates:
\href{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(«Пісня_при_колисці»).ogg}{\url{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby}$_{\text{(«Пісня}_{\text{при}}_{\text{колисці»}}\text{)}}$.ogg}
Or if I add a #+OPTIONS: ^:nil line, then LaTeX code will be the following:
\href{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(«Пісня_при_колисці»).ogg}{\url{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby}\_(«Пісня\_при\_колисці»).ogg}
I.e. it wraps only part of the description of the link with \url due
to the parentheses in it.
2013/7/10, Bastien b...@gnu.org:
Nicolas Goaziou n.goaz...@gmail.com writes:
I will have a look at it, but this is not clear to me either. I still
have to understand what should be escaped, and when.
All right, no hurry! And thanks a lot in advance,
--
Bastien
Re: [O] Orgmode fails to export specific web-links as latex/pdf
One more thing, related to unicode inside the href of the link:
[[https://commons.wikimedia.org/wiki/File:%D0%91%D1%83%D0%B7%D0%BE%D0%BA.ogg][https://commons.wikimedia.org/wiki/File:Бузок.ogg]]
Turns into:
\href{https://commons.wikimedia.org/wiki/File:Бузок.ogg}{\url{https://commons.wikimedia.org/wiki/File:Бузок.ogg}}
I.e. for some reason the href gets url-decoded. Such links don't work in evince.
2013/7/16, Yury Bulka yurk...@gmail.com:
A quick related observation. Consider this Org-mode link:
[[https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(%C2%AB%D0%9F%D1%96%D1%81%D0%BD%D1%8F_%D0%BF%D1%80%D0%B8_%D0%BA%D0%BE%D0%BB%D0%B8%D1%81%D1%86%D1%96%C2%BB).ogg][https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(«Пісня_при_колисці»).ogg]]
The LaTeX code it generates:
\href{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(«Пісня_при_колисці»).ogg}{\url{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby}$_{\text{(«Пісня}_{\text{при}}_{\text{колисці»}}\text{)}}$.ogg}
Or if I add a #+OPTIONS: ^:nil line, then LaTeX code will be the
following:
\href{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(«Пісня_при_колисці»).ogg}{\url{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby}\_(«Пісня\_при\_колисці»).ogg}
I.e. it wraps only part of the description of the link with \url due
to the parentheses in it.
2013/7/10, Bastien b...@gnu.org:
Nicolas Goaziou n.goaz...@gmail.com writes:
I will have a look at it, but this is not clear to me either. I still
have to understand what should be escaped, and when.
All right, no hurry! And thanks a lot in advance,
--
Bastien
[O] some orgweb typos corrected
some orgweb typos corrected 0001-Some-typos-corrected.patch Description: Binary data
Re: [O] Orgmode fails to export specific web-links as latex/pdf
Hello,
Yury Bulka yurk...@gmail.com writes:
A quick related observation. Consider this Org-mode link:
[[https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(%C2%AB%D0%9F%D1%96%D1%81%D0%BD%D1%8F_%D0%BF%D1%80%D0%B8_%D0%BA%D0%BE%D0%BB%D0%B8%D1%81%D1%86%D1%96%C2%BB).ogg][https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(«Пісня_при_колисці»).ogg]]
The LaTeX code it generates:
\href{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby_(«Пісня_при_колисці»).ogg}{\url{https://commons.wikimedia.org/wiki/File:Lysenko-Lullaby}$_{\text{(«Пісня}_{\text{при}}_{\text{колисці»}}\text{)}}$.ogg}
This is to be expected. Only the beginning of your description part
matches `org-plain-link-re' and gets converted to a link.
Regards,
--
Nicolas Goaziou
[O] table references in org-babel AND latex
Hi There, it might be nice to include documentation about table references in org-babel AND latex, i.e.: +begin_example numbers in table [[tab:Table]] are important. #+CAPTION: Description of system #+NAME: tab:Table | Code | |--| |1 | |2 | |4 | |8 | | 16 | | 32 | | 64 | | 128 | | NaN | #+begin_src R :session :var FlaggingTable=tab:FlaggingTable :results silent :eval no-export write.csv(FlaggingTable, file=file.path(doc.dir, FlaggingTable.csv)) #+end_src Won't work, but #+begin_src R :session :var FlaggingTable=tab:FlaggingTable :results silent :eval no-export write.csv(FlaggingTable, file=file.path(doc.dir, FlaggingTable.csv)) #+end_src will! +end_example Maybe I missed something somewhere, it would be nice to see it as a footnote, to keep others sane :). Best, Brian GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars) of 2013-05-15 on DDM03958 Org-mode version 8.0.5 (8.0.5-6-g426917-elpa @ ~/.emacs.d/elpa/org-20130708/)
Re: [O] Orgmode fails to export specific web-links as latex/pdf
Yury Bulka yurk...@gmail.com writes:
One more thing, related to unicode inside the href of the link:
[[https://commons.wikimedia.org/wiki/File:%D0%91%D1%83%D0%B7%D0%BE%D0%BA.ogg][https://commons.wikimedia.org/wiki/File:Бузок.ogg]]
Turns into:
\href{https://commons.wikimedia.org/wiki/File:Бузок.ogg}{\url{https://commons.wikimedia.org/wiki/File:Бузок.ogg}}
I.e. for some reason the href gets url-decoded. Such links don't work
in evince.
Indeed, links are url-decoded when parsed (see line 3139 in
org-element.el). I think the reasoning behind it is that url should then
be encoded again to make sure every url is correctly encoded.
One possibility is to use (org-link-escape (org-link-unescape
raw-link)), that is every parsed link will be url-encoded. Another one
is to leave links as-is, but back-end developers will have to deal with
that. I lean towards the former.
Funnily, this only applied to bracket links (i.e., [[link][desc]]),
plain links are not url-decoded (or encoded) at all. This isn't
consistent and also needs to be fixed.
Any opinion?
Regards,
--
Nicolas Goaziou
Re: [O] some orgweb typos corrected
Aris Sotiropoulos soti...@gmail.com writes: some orgweb typos corrected Applied, thanks a lot! -- Bastien
Re: [O] Can't export in 7.8.11 and can't get 8.0.4 to work
Thanks for your help. I had failed to include (package-initialize) in my .emacs which was why 8.0.4 was not working. Problem solved! On 16 July 2013 17:06, Bastien b...@gnu.org wrote: Hi Paul, Paul Whipp paul.wh...@gmail.com writes: If I use the package installer to upgrade org I get version 8.0.4 but it then fails to complete my initialisation with: Symbol's function definition is void: org-defvaralias Please share the parts of your configuration that are relevant to this, e.g. your package initialization and your Org initialization. Thanks, -- Bastien my-org-mode.el Description: Binary data
Re: [O] Should comments break paragraphs?
Hi all, I think everyone agrees that comments are an important part of Org. Nicolas, apart from the current code, what theoretically prevents Org from considering them as *empty* lines (not blank lines)? Where should one start if someone wants to propose a patch for this? Thanks, -- Bastien
