Re: [O] passing the contents of a block as an escaped string
Hello Charles, On 2014-06-24 18:37, Charles Berry ccbe...@ucsd.edu writes: , | #+NAME: prin-block | #+BEGIN_SRC emacs-lisp :var a=abc | (defun foo (blk) | (save-excursion | (org-babel-goto-named-src-block blk) | (nth 1 (org-babel-get-src-block-info 'light | | #+END_SRC | | #+NAME: weird-text | #+BEGIN_SRC python | just some plain text; | | \\ a double slash | | escape eol \n | | OK?? | #+END_SRC | | | #+BEGIN_SRC python :var a=(foo weird-text) :results output | print(a); | #+END_SRC | | #+RESULTS: | : just some plain text; | : | : \\ a double slash | : | : escape eol \n | : | : OK?? | | #+header: :var a=(prin1-to-string (foo weird-text)) | #+BEGIN_SRC python :results output | print(a); | #+END_SRC | | #+RESULTS: | : just some plain text; | : | : a double slash | : | : escape eol \\n | : | : OK?? ` Thanks a lot, it works great. I'm now having utf-8, orgmode, and python problems that I'll explore in another thread. Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 pgpFoKsAgZv3a.pgp Description: PGP signature
[O] babel evaluation of python and utf-8
Hello, I'm having trouble with the babel evaluation of python blocks containing utf-8 encoded characters (which is the encoding of my org file). I tried the approach suggested in this message https://lists.gnu.org/archive/html/emacs-orgmode/2010-12/msg00086.html in the following block #+BEGIN_SRC python :prefix # -*- coding: utf-8 -*- :results output print(u'∀') #+END_SRC but when I evaluate it, I get an error File stdin, line 1 SyntaxError: Non-ASCII character '\xe2' in file stdin on line 1, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details Am I doing something wrong? Thanks, Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 pgpRqVumhA7nU.pgp Description: PGP signature
[O] org-article.cls generated empty after tangling
I followed the instructions on this website: http://orgmode.org/worg/org-contrib/babel/examples/article-class.html and tried to tangle article-class.org to obtain the class file org-article.cls that is to be used when exporting LaTeX files. The file is weirdly empty. Does anybody have an idea why? I have tried without my emacs configuration, and also on another machine.
Re: [O] Org-mode Tables not showing correctly in graphical emacs
Hi David, On 26 Jun 2014, at 08:54, David Rose david.r...@jeppesen.com wrote: I am not sure if this is an actual bug or if I am just missing some new setting/configuration option, but when in a graphical emacs window org-mode table alignments are way off, yet when in a 'terminal' window emacs session tables are shown as expected. It will help a lot when you pick a mono-spaced (fixed width) font (courier, monaco, …). The Terminal mode uses such a font, as you can easily see by the width of the letter ‘i’. Cheers, Peter.
Re: [O] Org-mode Tables not showing correctly in graphical emacs
Thank you Peter. I have to admit I do feel stupid for missing the font differences. That did take care of it. Cheers, David Rose Linux Systems Administrator Information Technology Services Jeppesen A Boeing Company ph: +46 31 722 62 25 | mobile: +46 739 01 82 47 | Voip: 376225 fax: +46 31 720 81 20 | david.r...@jeppesen.com Jeppesen Systems AB | P.O. Box 192, SE-401 23 Göteborg, Sweden Visiting address: Odinsgatan 9, SE-411 03 Göteborg, Sweden www.jeppesen.com/carmen On Thu, Jun 26, 2014 at 10:14:40AM +0200, Peter Frings wrote: Hi David, On 26 Jun 2014, at 08:54, David Rose david.r...@jeppesen.com wrote: I am not sure if this is an actual bug or if I am just missing some new setting/configuration option, but when in a graphical emacs window org-mode table alignments are way off, yet when in a 'terminal' window emacs session tables are shown as expected. It will help a lot when you pick a mono-spaced (fixed width) font (courier, monaco, ?). The Terminal mode uses such a font, as you can easily see by the width of the letter ?i?. Cheers, Peter.
Re: [O] Org-mode Tables not showing correctly in graphical emacs
David Rose david.rose at jeppesen.com writes: Hi, I am not sure if this is an actual bug or if I am just missing some new setting/configuration option, but when in a graphical emacs window org-mode table alignments are way off, yet when in a 'terminal' window emacs session tables are shown as expected. Just as I am not sure if this is a bug, I am not sure if it is in org-mode or emacs itself, so I apologise if this is not the right list for this. I have tried searching on-line for an answer but have nto been able to find this which is why I believe I might just be missing a setting somewhere that I did not need before. I am attaching my .emacs file as well as a screen shot showing the issue I am speaking of. In the screen shot the window on the left is a graphical instance of emacs, and the one on the right is started from a terminal window (emacs -nw --no-desktop). Both are using the same file. My emacs version is: 24.3.1 (x86_64-slackware-linux-gnu with GTK+ version 2.24.17 I am currently using an older version of org-mode as I try to reconfigure my custom latex document classes over to the newer version. Org mode version is: 7.8.11 I have tested this with the newest org-mode version as well though and received the same results as I currently get. Thank you in advance for any assistance, and I again apologise if this is not the correct list for this. Sincerely, Hello, It seems that you are using a proportional font (different width for each character) as opposed to a monospace one. For example, compare the width of '' on line 2 with the 'J' below. Table alignment usually works by ensuring all cells in a column contain the same number of characters, but that only works for monospace fonts. The terminal is using monospace fonts by default. --- Thibaut Verron
[O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
Hello,
I'm forwarding this question asked on stackexchange:
http://tex.stackexchange.com/questions/186605/with-orgtbl-how-to-ensure-
that-braces-and-dollars-are-not-escaped
After some investigation, it seems that the behavior is hidden deep in the
export routines, and I was wisely suggested to ask the question on this list
instead.
I have given some tex-related details in the linked question, including some
motivations and an example, the tl;dr is that in some conditions, the
orgtbl-to-latex exporter will perform arbitrary escape of some characters in
the cells, or other kind of transformations:
$\text{test}$
is exported verbatim (OK).
But
\pbox{test}
becomes
\pbox\{test\}
{test}
becomes
\{test\}
{$test$}
becomes
\{\$test\$\}
And the exporter seems to be trying to be smart, because it will still
ensure that the result is correct:
{$\infty$}
becomes
\{\$$\infty$\$\}
The weirdest of all might be this one:
\pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}
becomes
\pbox\{Foo: \\${bar= (2^{3},1)}$, \$\{baz= (8$^{\text{4}}$)\}\$\}
(Note how the two mathematical expressions recieve different treatment, and
the decision to insert \text around the exponent!)
The option `:no-export`, as expected, has no effect, since it only controls
whether `#_^%` are escaped or not.
Is this a known feature, or a bug? And is there a known workaround?
Thanks,
Thibaut Verron
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
Hello,
Thibaut Verron thibaut.ver...@gmail.com writes:
I'm forwarding this question asked on stackexchange:
http://tex.stackexchange.com/questions/186605/with-orgtbl-how-to-ensure-
that-braces-and-dollars-are-not-escaped
After some investigation, it seems that the behavior is hidden deep in the
export routines, and I was wisely suggested to ask the question on this list
instead.
I have given some tex-related details in the linked question, including some
motivations and an example, the tl;dr is that in some conditions, the
orgtbl-to-latex exporter will perform arbitrary escape of some characters in
the cells, or other kind of transformations:
$\text{test}$
is exported verbatim (OK).
But
\pbox{test}
becomes
\pbox\{test\}
You should upgrade to Org 8.
{test}
becomes
\{test\}
This is intended.
{$test$}
becomes
\{\$test\$\}
This is to be expected as matching single dollar math snippets is
fragile. I suggest to use \(...\) instead: {\(test\)}
And the exporter seems to be trying to be smart, because it will still
ensure that the result is correct:
{$\infty$}
becomes
\{\$$\infty$\$\}
Ditto. Use \(...\). Or, better, {\infty} as \infty is an Org entity
which will properly translated into LaTeX code.
The weirdest of all might be this one:
\pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}
becomes
\pbox\{Foo: \\${bar= (2^{3},1)}$, \$\{baz= (8$^{\text{4}}$)\}\$\}
You cannot write raw LaTeX macros with complicated arguments (e.g.,
containing braces) in an Org buffer. In this case, you have to tell the
exporter it is LaTeX code and don't expect it to find it out:
@@latex:\pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}@@
This will be ignored in any exporter but latex (and beamer).
The option `:no-export`, as expected, has no effect, since it only controls
whether `#_^%` are escaped or not.
This option doesn't exist anymore in Org 8.
Is this a known feature, or a bug? And is there a known workaround?
Actually, this is consistent if you understand the limitations of Org.
As a rule of thumb, avoid using $..$ constructs and macros with
convoluted arguments (but \hfill{} and \vspace{1cm} are fine) when
writing raw LaTeX in an Org buffer.
For anything more complicated, use @@latex:...@@
or #+BEGIN_LATEX...#+END_LATEX (inline and non-inline version).
Again, all this assumes you are using Org 8.
HTH,
Regards,
--
Nicolas Goaziou
Re: [O] /some 'text'/
On 2014-06-26 03:38, Alan L Tyree alanty...@gmail.com writes:
I have the following expression in my manuscript:
/Caltex Oil (Aust) Pty Ltd v The Dredge 'Willemstad'/ [1976] HCA 65
I want the /.../ part to be italicised on export, but (of course) it isn't.
The variable org-emphasis-regexp-components was customizable before
8.0. Is there some workaround to get my desired results? I suppose
writing some filters is one way. Anything simpler?
You can set it by hand (before loading org). This is what I have in my
init file.
#+begin_src emacs-lisp
(setq org-emphasis-regexp-components
'( \t('\{ - \t.,:!?;'\)}\\ \t\n, . 1))
#+end_src
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
pgp2fUlFmD7kl.pgp
Description: PGP signature
Re: [O] babel evaluation of python and utf-8
On 2014-06-26 09:35, Alan Schmitt alan.schm...@polytechnique.org writes: #+BEGIN_SRC python :prefix # -*- coding: utf-8 -*- :results output print(u'∀') #+END_SRC I see that somewhere the email did not get through, the character above is a forall character. I have the same problem with a simpler accent #+BEGIN_SRC python :prefix # -*- coding: utf-8 -*- :results output print(u'é') #+END_SRC Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 pgp2KIZ_YP4vY.pgp Description: PGP signature
Re: [O] org-ref in action
+1 for org-bibtex (and ox-bibtex) that I'm using for a couple of years. But org-ref seems to go further (video is convincing). It would be really nice to merge org-ref and org-bibtex before they split too far apart. Wishful thinking from me because I don't see that I'm in position to do it. Fabrice 2014-06-26 3:10 GMT+02:00 Matt Lundin m...@imapmail.org: Eric Schulte schulte.e...@gmail.com writes: This is a lot of useful functionality, and very nicely presented. Did you happen to try the built in bibtex support in Org-mode core and contrib? And if so, is there a reason that you implemented this all independently? I think part of the problem with existing Org-mode bibtex support is that no-one knows it exists. Well, you can count on one big fan of org-bibtex.el here! (Though I must admit that I have not used ox-bibtex.el.) To help address this I threw up a very quick-and-dirty screen cast demonstrating some of Org's existing bibtex functionality. https://vimeo.com/99167082 Thanks! Over the years, I've particularly appreciated the way org-bibtex.el makes it easy to keep bib data together with notes/todos. Both org-bibtex-read and org-bibtex-yank have become indispensable to my own workflow. Best, Matt -- Fabrice Popineau - SUPELEC Département Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 --
[O] Using #+NAME for single value, not table?
Hi I use #+NAME to define some parameters for my analysis, which works quite nice for tables. but I would now like to use the same apprioach for values, e.g. a single number, but I don't manage. Is this possible? For illustration a short example: --8---cut here---start-8--- *** Species names and iespece codes #+NAME: SPECIES | | fullName| shortName | iespece | IFNName | color | |-+-+---+-+-+---| | fagus | Fagus sylvatica | fagus | 4 | fagus_sylvatica | red | | quercus | Quercus robur | quercus | 3 | quercus_robur | green | *** Random Number Definition Defines random number generator kind, normal.kind and seed (see set.seed help in R for details) #+NAME: RNGSEED 13 --8---cut here---end---8--- SPECIES works, but how do I get RNGSEED to be 13? Thanks, Rainer -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpWWHuaxKYSI.pgp Description: PGP signature
Re: [O] :header-args: over several lines?
Aaron Ecay aarone...@gmail.com writes: 2014ko ekainak 25an, Rainer M Krug-ek idatzi zuen: Hi I want to add many variables to a subtree. But it seems that :header-args: only allows one line - is this true? In my case, this line would be exceedingly long and very difficult to debug. Is there a way of having :header-args: span several lines (like var+)? Exactly that should work, i.e. using header-args+: And it does - should be added to the manual in the example. Along the same lines: When I use , | :header-args: :var RNGKIND=Mersenne-Twister | :header-args+: :var RNGNORMALKIND=Inversion ` both variables are transferred - is var+ generally redundant, or i=only in this case? Thanks, Rainer , | * foo | :PROPERTIES: | :header-args+: :exports none | :header-args+: :results value | :END: | | #+begin_src elisp | (org-entry-get nil header-args) | #+end_src | | #+RESULTS: | : :exports none :results value ` -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug PGP: 0x0F52F982 pgpW6utUtXU2L.pgp Description: PGP signature
Re: [O] org-ref in action
Some features could be merged, but there is an important difference in that org-ref uses bibtex as the backend database, and reftex for searching, and org-bibtex uses org-mode headings as the backend database, and tag/property searches (I think). It is like the difference between org-contacts and bbdb. They both serve similar needs, but with different data sources, and different ways to think about it. We might be able to figure out a way to specify a backend that would allow the independent features to work in both though. John --- John Kitchin Associate Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu On Thu, Jun 26, 2014 at 8:21 AM, Fabrice Popineau fabrice.popin...@supelec.fr wrote: +1 for org-bibtex (and ox-bibtex) that I'm using for a couple of years. But org-ref seems to go further (video is convincing). It would be really nice to merge org-ref and org-bibtex before they split too far apart. Wishful thinking from me because I don't see that I'm in position to do it. Fabrice 2014-06-26 3:10 GMT+02:00 Matt Lundin m...@imapmail.org: Eric Schulte schulte.e...@gmail.com writes: This is a lot of useful functionality, and very nicely presented. Did you happen to try the built in bibtex support in Org-mode core and contrib? And if so, is there a reason that you implemented this all independently? I think part of the problem with existing Org-mode bibtex support is that no-one knows it exists. Well, you can count on one big fan of org-bibtex.el here! (Though I must admit that I have not used ox-bibtex.el.) To help address this I threw up a very quick-and-dirty screen cast demonstrating some of Org's existing bibtex functionality. https://vimeo.com/99167082 Thanks! Over the years, I've particularly appreciated the way org-bibtex.el makes it easy to keep bib data together with notes/todos. Both org-bibtex-read and org-bibtex-yank have become indispensable to my own workflow. Best, Matt -- Fabrice Popineau - SUPELEC Département Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 --
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
Now, are these limitations of Org really preventing it from exporting a string verbatim? That would seem like the most logical default in this situation, wouldn't it? (Disclaimer: I don't understand the limitations of Org, so these last questions may be ridiculous to someone who does) Apparently not, the following quick attempt seems to be doing the job fine enough: (defun tv/orgtbl-to-latex-verbatim (table params) (flet ((org-export-string-as (string backend optional b e) string)) (orgtbl-to-latex table params))) However, it is extra dirty, and ignoring so many parameters in a function is probably not safe. :-) Is there really no similar mechanism built-in org? Should I polish this function and submit a patch? Or am I running into a wall? Thanks, Thibaut Verron
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
2014-06-26 12:38 GMT+02:00 Nicolas Goaziou m...@nicolasgoaziou.fr:
Hello,
Thibaut Verron thibaut.ver...@gmail.com writes:
I'm forwarding this question asked on stackexchange:
http://tex.stackexchange.com/questions/186605/with-orgtbl-how-to-ensure-
that-braces-and-dollars-are-not-escaped
After some investigation, it seems that the behavior is hidden deep in
the
export routines, and I was wisely suggested to ask the question on this
list
instead.
I have given some tex-related details in the linked question, including
some
motivations and an example, the tl;dr is that in some conditions, the
orgtbl-to-latex exporter will perform arbitrary escape of some
characters in
the cells, or other kind of transformations:
$\text{test}$
is exported verbatim (OK).
But
\pbox{test}
becomes
\pbox\{test\}
You should upgrade to Org 8.
{test}
becomes
\{test\}
This is intended.
{$test$}
becomes
\{\$test\$\}
This is to be expected as matching single dollar math snippets is
fragile. I suggest to use \(...\) instead: {\(test\)}
And the exporter seems to be trying to be smart, because it will still
ensure that the result is correct:
{$\infty$}
becomes
\{\$$\infty$\$\}
Ditto. Use \(...\). Or, better, {\infty} as \infty is an Org entity
which will properly translated into LaTeX code.
The weirdest of all might be this one:
\pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}
becomes
\pbox\{Foo: \\${bar= (2^{3},1)}$, \$\{baz= (8$^{\text{4}}$)\}\$\}
You cannot write raw LaTeX macros with complicated arguments (e.g.,
containing braces) in an Org buffer. In this case, you have to tell the
exporter it is LaTeX code and don't expect it to find it out:
@@latex:\pbox{Foo: \\${bar= (2^{3},1)}$, ${baz= (8^{4})}$}@@
This will be ignored in any exporter but latex (and beamer).
The option `:no-export`, as expected, has no effect, since it only
controls
whether `#_^%` are escaped or not.
This option doesn't exist anymore in Org 8.
Is this a known feature, or a bug? And is there a known workaround?
Actually, this is consistent if you understand the limitations of Org.
As a rule of thumb, avoid using $..$ constructs and macros with
convoluted arguments (but \hfill{} and \vspace{1cm} are fine) when
writing raw LaTeX in an Org buffer.
For anything more complicated, use @@latex:...@@
or #+BEGIN_LATEX...#+END_LATEX (inline and non-inline version).
Again, all this assumes you are using Org 8.
HTH,
Regards,
--
Nicolas Goaziou
Thank you for your answer,
I forgot to repeat the information about my environment I gave on
stackexchange. In particular, this is Org 8.2.6.
Also, this is not an org buffer, but a latex buffer with the orgtbl minor
mode. Indeed I should have mentioned it in the body of the question, it's
easily missed in the title.
However, I understand that the underlying mechanism is the same as the one
used to export an org buffer to latex, and that it probably suffers from
the same limitations.
Now, are these limitations of Org really preventing it from exporting a
string verbatim? That would seem like the most logical default in this
situation, wouldn't it? (Disclaimer: I don't understand the limitations of
Org, so these last questions may be ridiculous to someone who does)
Thanks,
Thibaut Verron
PS. Indeed \(..\) does work for the dollars, thank you for the tip. I
should have pointed out that \bgroup ... \egroup works as a replacement for
outermost pairs of braces too. However, I do not have any solution for the
\pbox{...} thing. And I would prefer a more robust solution which would not
require me to change the way I write the tables, because otherwise, I'd
still risk facing new unexportable constructs at random times.
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
Thibaut Verron thibaut.ver...@gmail.com writes:
Now, are these limitations of Org really preventing it from exporting a
string verbatim? That would seem like the most logical default in this
situation, wouldn't it?
I disagree in the general case. The most logical default for Org is to
treat contents as plain text and ensure that the export conforms to what
appears in the buffer. As a bonus, it can leave LaTeX code as-is when it
recognizes some, which depends on Org's understanding of LaTeX syntax
(hence the limitations I'm talking about).
Now, in the context of a LaTeX buffer using orgtbl minor mode, it could
make sense in some situations to treat cell contents verbatim. I don't
think it should be the default, but there could be an option for that.
Anyway, there's a solution, see below.
Apparently not, the following quick attempt seems to be doing the job fine
enough:
(defun tv/orgtbl-to-latex-verbatim (table params)
(flet ((org-export-string-as
(string backend optional b e)
string))
(orgtbl-to-latex table params)))
However, it is extra dirty, and ignoring so many parameters in a function
is probably not safe. :-)
I think defining your own translator function is the way to go. For
example, the following (untested) could work:
(defun my-orgtbl-to-latex-verbatim (table params)
(let* ((alignment (mapconcat (lambda (x) (if x r l))
org-table-last-alignment ))
(params2
(list
:tstart (concat \\begin{tabular}{ alignment })
:tend \\end{tabular}
:lstart :lend :sep
:efmt %s\\,(%s) :hline \\hline)))
(orgtbl-to-generic table (org-combine-plists params2 params
Regards,
--
Nicolas Goaziou
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
2014-06-26 15:17 GMT+02:00 Nicolas Goaziou m...@nicolasgoaziou.fr:
Thibaut Verron thibaut.ver...@gmail.com writes:
Now, are these limitations of Org really preventing it from exporting
a
string verbatim? That would seem like the most logical default in this
situation, wouldn't it?
I disagree in the general case. The most logical default for Org is to
treat contents as plain text and ensure that the export conforms to what
appears in the buffer. As a bonus, it can leave LaTeX code as-is when it
recognizes some, which depends on Org's understanding of LaTeX syntax
(hence the limitations I'm talking about).
Of course, I did not mean it for org-mode buffers! ;)
Now, in the context of a LaTeX buffer using orgtbl minor mode, it could
make sense in some situations to treat cell contents verbatim. I don't
think it should be the default, but there could be an option for that.
Anyway, there's a solution, see below.
Apparently not, the following quick attempt seems to be doing the job
fine
enough:
(defun tv/orgtbl-to-latex-verbatim (table params)
(flet ((org-export-string-as
(string backend optional b e)
string))
(orgtbl-to-latex table params)))
However, it is extra dirty, and ignoring so many parameters in a function
is probably not safe. :-)
I think defining your own translator function is the way to go. For
example, the following (untested) could work:
(defun my-orgtbl-to-latex-verbatim (table params)
(let* ((alignment (mapconcat (lambda (x) (if x r l))
org-table-last-alignment ))
(params2
(list
:tstart (concat \\begin{tabular}{ alignment })
:tend \\end{tabular}
:lstart :lend :sep
:efmt %s\\,(%s) :hline \\hline)))
(orgtbl-to-generic table (org-combine-plists params2 params
Indeed it does work.
But, unless I am mistaken, this is exactly the definition given here:
http://orgmode.org/manual/Translator-functions.html#Translator-functions
and so I was not wrong, this used to work as I expected.
I suspect that this change (regression?) will cause problems to a lot of
other users when they will upgrade their org to the current version.
Would changing the last lines of `orgtbl-to-latex` to something like this
work as a long-term solution?
(require 'ox-latex)
(let* ((*orgtbl-verbatim* (plist-get params :verbatim))
(backend (if *orgtbl-verbatim* nil 'latex)))
(orgtbl-to-generic table (org-combine-plists params2 params)
backend
Thanks for your time,
Thibaut verron
Re: [O] org-ref in action
John Kitchin jkitc...@andrew.cmu.edu writes: Some features could be merged, but there is an important difference in that org-ref uses bibtex as the backend database, and reftex for searching, and org-bibtex uses org-mode headings as the backend database, and tag/property searches (I think). It is like the difference between org-contacts and bbdb. They both serve similar needs, but with different data sources, and different ways to think about it. Yes, org-bibtex.el generally precludes the use of reftex to enter citations. I get around this problem with a custom perl script, which runs automatically in the background, extracts all org-bibtex data, and deposits it in a central bib file. We might be able to figure out a way to specify a backend that would allow the independent features to work in both though. I think the key in any possible feature merge is to remember citation management is idiosyncratic. I.e., org-mode should offer helper functions that enable individuals to customize their own workflows rather than systems that dictate a particular workflow (e.g., a single notes file) or presuppose a specific export backend. For instance, org-mode citation tools should not assume that users will export via bibtex/bibtex2html rather than, say, biber/biblatex or pandoc (which now has a powerful, format-agnostic citation filter).[1] Best, Matt Footnotes: [1] http://johnmacfarlane.net/pandoc/demo/example19/Citations.html
Re: [O] org-ref in action
Matt Lundin m...@imapmail.org writes: John Kitchin jkitc...@andrew.cmu.edu writes: Some features could be merged, but there is an important difference in that org-ref uses bibtex as the backend database, and reftex for searching, and org-bibtex uses org-mode headings as the backend database, and tag/property searches (I think). It is like the difference between org-contacts and bbdb. They both serve similar needs, but with different data sources, and different ways to think about it. Yes, org-bibtex.el generally precludes the use of reftex to enter citations. s/enter/search/
Re: [O] org-ref in action
On Thu, Jun 26, 2014 at 9:08 AM, Matt Lundin m...@imapmail.org wrote: I think the key in any possible feature merge is to remember citation management is idiosyncratic. Off topic: How do people choose today? Why choose bibtex over biblatex? Where do people discuss such questions like this in real life?
Re: [O] org-ref in action
On 2014-06-26 at 10:11, Grant Rettke wrote: Why choose bibtex over biblatex? People choose bibtex because that is how it has been done and is well supported/documented and still popular on Google results. People choose biblatex because that appears to be the new under-development with-bells-and-whistles way moving forward. Where do people discuss such questions like this in real life? http://tex.stackexchange.com -k.
Re: [O] org-ref in action
Grant Rettke g...@wisdomandwonder.com writes: How do people choose today? Why choose bibtex over biblatex? For journal submission. With BibTeX you only have to copy paste at the end of your LaTeX file the contents of the generated .bbl file. Moreover, journals provide a default style for BibTeX, not biblatex. And I have never seen a journal that supports biblatex (there might be a few), but any journal that supports LaTeX supports BibTeX. Where do people discuss such questions like this in real life? In the orgmode list =)
Re: [O] org-ref in action
Grant Rettke g...@wisdomandwonder.com writes: On Thu, Jun 26, 2014 at 9:08 AM, Matt Lundin m...@imapmail.org wrote: I think the key in any possible feature merge is to remember citation management is idiosyncratic. Off topic: How do people choose today? Why choose bibtex over biblatex? Thanks to inertia, bibtex still has a number of users in the sciences, since it was originally designed for scientific citations. In the humanities, however, bibtex is a non-starter, since biblatex offers much more flexibility. The good news is that bibtex and biblatex use the same database format, so it's easy to transition from bibtex to biblatex. However, there are other options, such as CSL.[1] Where do people discuss such questions like this in real life? I'm not sure I understand your question. Could you clarify? I simply meant that everyone will have a different workflow/system for storing and managing citations. E.g., some will prefer to store bibliographical data in a zotero database, others in a single bib file, others in multiple bib files, others as properties in org headlines, etc. I think one can make a conception distinction here between citation management (i.e., how one stores bibliographical data) and citation processing (i.e., the software one uses to export that data to some output format). There are many, many formats (mods, bib, etc.) and tools (biber, bibtex, csl/citeproc, etc.) for formatting bibliographical data. In an ideal world, one should be able to 1) process bibliographical data from multiple formats; 2) choose from hundreds of citation styles; and 3) format citations for multiple backends. I am not suggesting that org-mode should directly support all these things, but its default methods of handling citations should not get in the way of using external tools that provide such flexibility. For instance, pandoc (an immensely impressive piece of software!) accepts bibliographical data from numerous sources and processes it for multiple outputs (html, plain text, docx, rtf, etc.). By contrast, ox-bibtex.el runs citations through bibtex2html, which is pretty much limited to the old-fashioned bibtex formats. Ironically, ox-bibtex.el invokes pandoc to convert from html to plain text, but only after it has already used bibtex2html to process the data. Best, Matt Footnotes: [1] Citation Style Language - http://citationstyles.org/
Re: [O] babel evaluation of python and utf-8
#+BEGIN_SRC python :prefix # -*- coding: utf-8 -*- :results output print(u'é') #+END_SRC I also see the same problem here. Even if you include # -*- coding: utf-8 -*- as the first line. Shouldn't org-babel already be using utf-8 instead of ASCII for input/output? By the way, with Python3 it doesn't happen since it doesn't need the coding:utf-8 declaration anymore.
[O] minor problem on major version number
I have some backward-compat code that does this: --8---cut here---start-8--- ;;(setq major-version (string-to-number (nth 0 (split-string (org-version) [.] (setq major-version 8) (if ( major-version 8) (progn (require 'org-latex) ... (progn (require 'ox-latex) ... --8---cut here---end---8--- After last night's git pull, org-version returns beta_8.3 which broke the major-version calculation above. I hardwired the org version major number above, but I was wondering if we could agree on some convention/method that will not break in the future - maybe an org-major-version function? Thanks, Nick
[O] results from Python block not visible
Hi, this babel code recently stopped working on my system: #+BEGIN_SRC python :results output print x #+END_SRC It prints: #+RESULTS: : None I expected to see x. This worked some days ago. If I use a command like os.system(xeyes), I see it running. In addition I don't see the Python block highlighted GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 2014-06-20 on la4 org-mode from today Debian. Python 2.7 (same with Python 3). It also happens under emacs -Q Of course I loaded Python support: (org-babel-do-load-languages 'org-babel-load-languages '((R . t) (C . t) ; … (python . t) (ruby . t) (sql . t) (sqlite . t))) Greetings, Daniel
Re: [O] org-ref in action
John Kitchin jkitc...@andrew.cmu.edu writes: Some features could be merged, but there is an important difference in that org-ref uses bibtex as the backend database, and reftex for searching, and org-bibtex uses org-mode headings as the backend database, and tag/property searches (I think). It is like the difference between org-contacts and bbdb. They both serve similar needs, but with different data sources, and different ways to think about it. We might be able to figure out a way to specify a backend that would allow the independent features to work in both though. I wonder what the API would look like. The following functions comes to my mind. I'm not sure if there would be much more for org-ref... - jump location for citation by ID - return bibtex information for citation by ID - validate citation With those functions I imagine that a good deal of higher-level code could be shared in a backend agnostic way. Including, - jump to citations - provide information on citations - collect citations during publishing (possibly automatically create the bib file) If merging makes sense that's great, but if not then there's certainly no harm in a diverse ecosystem of org tools supporting different work flows and backend tools. Best, Eric John --- John Kitchin Associate Professor Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 http://kitchingroup.cheme.cmu.edu On Thu, Jun 26, 2014 at 8:21 AM, Fabrice Popineau fabrice.popin...@supelec.fr wrote: +1 for org-bibtex (and ox-bibtex) that I'm using for a couple of years. But org-ref seems to go further (video is convincing). It would be really nice to merge org-ref and org-bibtex before they split too far apart. Wishful thinking from me because I don't see that I'm in position to do it. Fabrice 2014-06-26 3:10 GMT+02:00 Matt Lundin m...@imapmail.org: Eric Schulte schulte.e...@gmail.com writes: This is a lot of useful functionality, and very nicely presented. Did you happen to try the built in bibtex support in Org-mode core and contrib? And if so, is there a reason that you implemented this all independently? I think part of the problem with existing Org-mode bibtex support is that no-one knows it exists. Well, you can count on one big fan of org-bibtex.el here! (Though I must admit that I have not used ox-bibtex.el.) To help address this I threw up a very quick-and-dirty screen cast demonstrating some of Org's existing bibtex functionality. https://vimeo.com/99167082 Thanks! Over the years, I've particularly appreciated the way org-bibtex.el makes it easy to keep bib data together with notes/todos. Both org-bibtex-read and org-bibtex-yank have become indispensable to my own workflow. Best, Matt -- Fabrice Popineau - SUPELEC Département Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 -- -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] results from Python block not visible
Daniel Clemente n142...@gmail.com writes: Hi, this babel code recently stopped working on my system: #+BEGIN_SRC python :results output print x #+END_SRC It prints: #+RESULTS: : None I expected to see x. This worked some days ago. This works for me using the latest version of Org-mode with an Emacs launched by running make vanilla from the base of the Org-mode repo. Maybe the problem is in your configuration? If I use a command like os.system(xeyes), I see it running. In addition I don't see the Python block highlighted GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 2014-06-20 on la4 org-mode from today Debian. Python 2.7 (same with Python 3). It also happens under emacs -Q Of course I loaded Python support: (org-babel-do-load-languages 'org-babel-load-languages '((R . t) (C . t) ; … (python . t) (ruby . t) (sql . t) (sqlite . t))) Greetings, Daniel -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] Using #+NAME for single value, not table?
Aloha Rainer, Rainer M Krug rai...@krugs.de writes: Hi I use #+NAME to define some parameters for my analysis, which works quite nice for tables. but I would now like to use the same apprioach for values, e.g. a single number, but I don't manage. Is this possible? For illustration a short example: *** Species names and iespece codes #+NAME: SPECIES | | fullName| shortName | iespece | IFNName | color | |-+-+---+-+-+---| | fagus | Fagus sylvatica | fagus | 4 | fagus_sylvatica | red | | quercus | Quercus robur | quercus | 3 | quercus_robur | green | *** Random Number Definition Defines random number generator kind, normal.kind and seed (see set.seed help in R for details) #+NAME: RNGSEED 13 SPECIES works, but how do I get RNGSEED to be 13? Perhaps you could wrap it in a source code block? #+name: rngseed #+begin_src R 13 #+end_src #+results: rngseed : 13 #+header: :var x=rngseed() #+begin_src R x + 1 #+end_src #+results: : 14 hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] org-ref in action
On 2014-06-26 16:39, Matt Lundin m...@imapmail.org writes: By contrast, ox-bibtex.el runs citations through bibtex2html, which is pretty much limited to the old-fashioned bibtex formats. What would be required for bibtex2html to take biblatex input? I thought the backend format was similar or the same (as you can tell, I know nothing of biblatex). Alan -- OpenPGP Key ID : 040D0A3B4ED2E5C7 pgpj7Ur28svBy.pgp Description: PGP signature
Re: [O] results from Python block not visible
El Thu, 26 Jun 2014 12:36:47 -0400 Eric Schulte va escriure: #+BEGIN_SRC python :results output print x #+END_SRC It prints: #+RESULTS: : None I expected to see x. This worked some days ago. This works for me using the latest version of Org-mode with an Emacs launched by running make vanilla from the base of the Org-mode repo. I didn't know make vanilla. It worked fine from there, I don't know why from „emacs -Q“ it didn't. Maybe the problem is in your configuration? Exactly, it is from my configuration, because after loading my full configuration, I see the problem again and code highlighting suddenly disappears. I identified the exact lines that cause org-babel to stop failing. Bewonder: (autoload 'tramp tramp Remotely access files. t) (require 'tramp-cache) Yes! After C-x C-e on the first line, org-babel still works. After C-x C-e on the second line, it doesn't work anymore. There were some Tramp changes in latest Emacs, maybe they are bad. I'm using: GNU Emacs 24.4.50.1 (x86_64-unknown-linux-gnu, X toolkit, Xaw scroll bars) of 2014-06-20 on la4 What a strange bug…
Re: [O] org-article.cls generated empty after tangling
Aloha Onur, Onur Solmaz onursol...@gmail.com writes: I followed the instructions on this website: http://orgmode.org/worg/org-contrib/babel/examples/article-class.html and tried to tangle article-class.org to obtain the class file org-article.cls that is to be used when exporting LaTeX files. The file is weirdly empty. Does anybody have an idea why? I have tried without my emacs configuration, and also on another machine. This was written using the old exporter while Babel was under development. I haven't tried to keep it current. I'm not surprised it doesn't work for you, though I don't know exactly why it doesn't work anymore. Are you having problems tangling other files, or just this one? Most of the reasons it was developed disappeared with the new export framework in Org-mode version 8. Perhaps it is (past) time to remove this from the babel examples on Worg? All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] minor problem on major version number
Nick Dokos writes: After last night's git pull, org-version returns beta_8.3 which broke the major-version calculation above. I hardwired the org version major number above, but I was wondering if we could agree on some convention/method that will not break in the future - maybe an org-major-version function? There already is a perfectly good convention available via C-h i version-to-list, which means the tag should have been named release_8.3beta and you do not need to invent your own version parsing code. Meanwhile, put these into local.mk: --8---cut here---start-8--- GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD) ORGVERSION ?= $(subst release_,,$(shell git describe --match release\* --abbrev=0 HEAD)) --8---cut here---end---8--- I'm tempted to install that in targets.mk to avoid further breakage by malformed tags. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] minor problem on major version number
On 2014-06-26 18:14 Nick Dokos wrote: I have some backward-compat code that does this: (setq major-version (string-to-number (nth 0 (split-string (org-version) [.] It does not work in this situation, because beta_8.3 is not a valid version string, but version might be interesting for you. HTH, -- Alexander Baier
Re: [O] minor problem on major version number
Achim Gratz strom...@nexgo.de writes: Nick Dokos writes: After last night's git pull, org-version returns beta_8.3 which broke the major-version calculation above. I hardwired the org version major number above, but I was wondering if we could agree on some convention/method that will not break in the future - maybe an org-major-version function? There already is a perfectly good convention available via C-h i version-to-list, which means the tag should have been named release_8.3beta and you do not need to invent your own version parsing code. Meanwhile, put these into local.mk: GITVERSION ?= $(shell git describe --match release\* --abbrev=6 HEAD) ORGVERSION ?= $(subst release_,,$(shell git describe --match release\* --abbrev=0 HEAD)) I'm tempted to install that in targets.mk to avoid further breakage by malformed tags. OK - thanks. I modified local.mk as suggested and replaced the major-version calculation in the init file (setq major-version (nth 0 (version-to-list (org-version AFAICT, everything's fine. Thanks, Nick
[O] Add a new face for org-verbatim?
Org-verbatim syntax is '=STRING=' ,but the equal symbol makes it look
not distinguishing ('=' itself looks like it seems to be a part of
STRING). I misread them often.
So, I think maybe Org-mode can add a new face for equal symbol itself? I
mean, user can dim the face of '=' to avoid confusion.
Re: [O] org-ref in action
Alan Schmitt alan.schm...@polytechnique.org writes: On 2014-06-26 16:39, Matt Lundin m...@imapmail.org writes: By contrast, ox-bibtex.el runs citations through bibtex2html, which is pretty much limited to the old-fashioned bibtex formats. What would be required for bibtex2html to take biblatex input? I thought the backend format was similar or the same (as you can tell, I know nothing of biblatex). I don't think this is possible without some major hacking/conversion/filtering. Biblatex has many more entry types and fields than bibtex. I've found that most of the older bibtex utils (bibtools, bibtex2html) choke on my biblatex files. Even if biblatex2html did read biblatex data, its output, I believe, is limited to bibtex styles, which cannot handle more complex formats. Many scientific journals require bibtex formats. But many humanities disciplines have more complicated bibliographical requirements that bibtex cannot handle. Best, Matt
Re: [O] Orgtbl-mode in latex: escaped braces and dollars, and other arbitrary transformations
Thibaut Verron thibaut.ver...@gmail.com writes: Would changing the last lines of `orgtbl-to-latex` to something like this work as a long-term solution? (require 'ox-latex) (let* ((*orgtbl-verbatim* (plist-get params :verbatim)) (backend (if *orgtbl-verbatim* nil 'latex))) (orgtbl-to-generic table (org-combine-plists params2 params) backend The check should happen in `orgtbl-to-generic', which is responsible for translating cell contents. Or, better, backend could become a parameter, e.g., :contents, and not an optional argument anymore. Then one could override it with specific params. Also, docstrings and documentation should be updated accordingly. Regards, -- Nicolas Goaziou
[O] How to identify all headings that won't be exported?
Aloha all, Inspired by John Kitchin's org-ref, I'm working on a little function that returns all the pieces of an Org mode file that are candidates for cross referencing. The helm package lets me choose from among the candidates and then another little function inserts the chosen link. This all works for me, and I'm finding it really useful. The only slight problem is that I haven't been able to figure out how to eliminate all the headings that won't be exported. You'll see in the code below that my simple-minded approach gets all the headings tagged :noexport:, but it doesn't understand that the tag is inherited by descendants. Is there a practical way to identify descendants for my use case? (defun tsd-get-names-labels-and-headings () (interactive) (save-excursion (goto-char (point-min)) (let ((matches)) (while (re-search-forward \\#\\+\\(name\\|label\\):\\s-\\(.*\\) (point-max) t) (add-to-list 'matches (match-string-no-properties 2) t)) (dolist (heading (org-map-entries 'org-heading-components)) (when (and (nth 4 heading) (not (search noexport(nth 5 heading (add-to-list 'matches (nth 4 heading (dolist (properties (org-map-entries 'org-entry-properties)) (when (cdr (assoc CUSTOM_ID properties)) (add-to-list 'matches (format #%s (cdr (assoc CUSTOM_ID properties)) (sort matches 'string All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] refile affects kill ring
Samuel Wales samolog...@gmail.com writes: in recent maint, it seems that refiling an entry will put that entry into the kill ring. perhaps it should leave the kill ring intact? I think this has been the behavior for a very long time. E.g., I went back to a version of org-refile from 2010 and it invokes org-copy-subtree and org-paste-subtree. Best, Matt
[O] [FeatReq] New option for `org-entry-properties' WHICH argument?
Hi List, what about adding one more option for WHICH ,[ C-h f org-entry-properties RET ] | org-entry-properties is a compiled Lisp function in `org.el'. | | (org-entry-properties optional POM WHICH SPECIFIC) | [...] | If WHICH is nil or `all', get all properties. If WHICH is | `special' or `standard', only get that subclass. If WHICH | is a string only get exactly this property. SPECIFIC can be a string, the | specific property we are interested in. Specifying it can speed | things up because then unnecessary parsing is avoided. ` that would filter out all Org related properties, i.e. the properties the system itself uses, and thus return only the application related properties? E.g. option 'non-org' with semantics/implementation similar to this (there are surely cl-xxx filter-functions that can do this as one-liner): #+begin_src emacs-lisp (delq nil (mapcar (lambda (--cons) (unless (or (member (car --cons) org-default-properties) (member (car --cons) org-special-properties)) --cons)) (org-entry-properties))) #+end_src What do you think? -- cheers, Thorsten
[O] org-ref in action
Hi John, Thanks for sharing. My students and I love it. Cheers, M
Re: [O] BUG variable expansion with table
Hi Rainer, Rainer M Krug rai...@krugs.de writes: Hi there seems to be a bug in the table transfer. The org file below evaluates as shown, i.e. the TABLE_BLOCK contains one column less then it should as the first column is discarded and the second one used as the row names. This only occurs when there is a second variable defined. When the second variable is not passed, the code works (see second example below). I did not get far when debugging, only that in the function org-babel-R-assign-elisp when assigning TABLE_FILE the rownames are missing in the =value=. Rainer First example: #+PROPERTY: rownames yes #+PROPERTY: colnames yes #+NAME: TABLE | | name | description| |--+--+| | annee| year | Year of simulation | | id | ipoints_Qdiv | Point Number | | iespece | species | species number | | scenario | scenario | Type of forest | #+PROPERTY: var TABLE_FILE=TABLE #+PROPERTY: var+ float=123.45 * Data Assessment Results #+HEADERS: :var TABLE_BLOCK=TABLE #+HEADERS: :rownames yes #+HEADERS: :colnames yes #+begin_src R :results output wrap TABLE_FILE TABLE_BLOCK #+end_src #+RESULTS: :RESULTS: namedescription anneeyear Year of simulation id ipoints_Qdiv Point Number iespece species species number scenario scenario Type of forest Year.of.simulation ipoints_Qdiv Point Number species species number scenario Type of forest :END: Second example: #+PROPERTY: rownames yes #+PROPERTY: colnames yes #+NAME: TABLE | | name | description| |--+--+| | annee| year | Year of simulation | | id | ipoints_Qdiv | Point Number | | iespece | species | species number | | scenario | scenario | Type of forest | #+PROPERTY: var TABLE_FILE=TABLE #+ PROPERTY: var+ float=123.45 * Data Assessment Results #+HEADERS: :var TABLE_BLOCK=TABLE #+HEADERS: :rownames yes #+HEADERS: :colnames yes #+begin_src R :results output wrap TABLE_FILE TABLE_BLOCK #+end_src #+RESULTS: :RESULTS: namedescription anneeyear Year of simulation id ipoints_Qdiv Point Number iespece species species number scenario scenario Type of forest namedescription anneeyear Year of simulation id ipoints_Qdiv Point Number iespece species species number scenario scenario Type of forest :END: FWIW, I think that bug was reported some while back [fn:1] -- unfortunately without a fix ;-) - Andreas Footnotes: [fn:1] http://article.gmane.org/gmane.emacs.orgmode/82295/match=
Re: [O] How to identify all headings that won't be exported?
Aloha all, Answering myself ... t...@tsdye.com (Thomas S. Dye) writes: Is there a practical way to identify descendants for my use case? (defun tsd-get-names-labels-and-headings () (interactive) (save-excursion (goto-char (point-min)) (let ((matches)) (while (re-search-forward \\#\\+\\(name\\|label\\):\\s-\\(.*\\) (point-max) t) (add-to-list 'matches (match-string-no-properties 2) t)) (dolist (heading (org-map-entries 'org-heading-components)) (when (and (nth 4 heading) (not (search noexport(nth 5 heading (add-to-list 'matches (nth 4 heading (dolist (properties (org-map-entries 'org-entry-properties)) (when (cdr (assoc CUSTOM_ID properties)) (add-to-list 'matches (format #%s (cdr (assoc CUSTOM_ID properties)) (sort matches 'string Yes, use the MATCH argument to org-map-entries. Many thanks to Jonathan Leech-Pepin for pointing this out to me off list. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
[O] Fwd: Re: How to identify all headings that won't be exported?
Forwarding to list. Somehow reply-all did not actually reply to all -- Forwarded message -- From: Jonathan Leech-Pepin jonathan.leechpe...@gmail.com Date: Jun 26, 2014 4:05 PM Subject: Re: [O] How to identify all headings that won't be exported? To: Thomas S. Dye t...@tsdye.com Cc: Hello Thomas On 26 June 2014 15:09, Thomas S. Dye t...@tsdye.com wrote: Aloha all, Inspired by John Kitchin's org-ref, I'm working on a little function that returns all the pieces of an Org mode file that are candidates for cross referencing. The helm package lets me choose from among the candidates and then another little function inserts the chosen link. This all works for me, and I'm finding it really useful. The only slight problem is that I haven't been able to figure out how to eliminate all the headings that won't be exported. You'll see in the code below that my simple-minded approach gets all the headings tagged :noexport:, but it doesn't understand that the tag is inherited by descendants. Is there a practical way to identify descendants for my use case? (defun tsd-get-names-labels-and-headings () (interactive) (save-excursion (goto-char (point-min)) (let ((matches)) (while (re-search-forward \\#\\+\\(name\\|label\\):\\s-\\(.*\\) (point-max) t) (add-to-list 'matches (match-string-no-properties 2) t)) (dolist (heading (org-map-entries 'org-heading-components)) (when (and (nth 4 heading) (not (search noexport(nth 5 heading (add-to-list 'matches (nth 4 heading (dolist (properties (org-map-entries 'org-entry-properties)) (when (cdr (assoc CUSTOM_ID properties)) (add-to-list 'matches (format #%s (cdr (assoc CUSTOM_ID properties)) (sort matches 'string For the matching portion itself the following should work: (org-map-entries (lambda () (org-element-property :raw-value (org-element-at-point))) (format -%s (mapconcat 'identity org-export-exclude-tags -))) Rather than try and search for the tag afterwards, create a string that will match all non-exporting tags and have them excluded from the match itself (by default this will be -noexport but if you add test it will become -noexport-test). It also gives you the exact raw value of the element. Using just 'org-element-at-point would give you the entire element, allowing you to display the :raw-value in your output but also have the associated :begin to jump to, removing the need to search for the headline again later on. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] [FeatReq] New option for `org-entry-properties' WHICH argument?
Thorsten Jolitz tjol...@gmail.com writes: Hi List, what about adding one more option for WHICH ,[ C-h f org-entry-properties RET ] | org-entry-properties is a compiled Lisp function in `org.el'. | | (org-entry-properties optional POM WHICH SPECIFIC) | [...] | If WHICH is nil or `all', get all properties. If WHICH is | `special' or `standard', only get that subclass. If WHICH | is a string only get exactly this property. SPECIFIC can be a string, the | specific property we are interested in. Specifying it can speed | things up because then unnecessary parsing is avoided. ` that would filter out all Org related properties, i.e. the properties the system itself uses, and thus return only the application related properties? E.g. option 'non-org' [..] What do you think? +1 It would help in extracting user data when such data is interspersed with org properties (e.g., LAST_REPEAT). Matt
Re: [O] org-ref in action
Hi all off topic a bit again. im an academic (asst. prof) in Epidemiology and have been using org-mode for about a year now. i love using org but im really not very technical at all. it has always been a dream for me to ditch word and move over to Latex and even better orgmode to write my scientific publications, writing my CV etc. The problem is i cant really find a good for dummies guide on how to really get started. again im really not technical so i always give up really fast on this. Do you guys think i should give it a shot (again not very technical :)) and if so what would be the steps/guides to follow? perhaps start by drafting a CV since thats perhaps easier? kind regards Z. On Thu, Jun 26, 2014 at 9:44 PM, Matt Lundin m...@imapmail.org wrote: Alan Schmitt alan.schm...@polytechnique.org writes: On 2014-06-26 16:39, Matt Lundin m...@imapmail.org writes: By contrast, ox-bibtex.el runs citations through bibtex2html, which is pretty much limited to the old-fashioned bibtex formats. What would be required for bibtex2html to take biblatex input? I thought the backend format was similar or the same (as you can tell, I know nothing of biblatex). I don't think this is possible without some major hacking/conversion/filtering. Biblatex has many more entry types and fields than bibtex. I've found that most of the older bibtex utils (bibtools, bibtex2html) choke on my biblatex files. Even if biblatex2html did read biblatex data, its output, I believe, is limited to bibtex styles, which cannot handle more complex formats. Many scientific journals require bibtex formats. But many humanities disciplines have more complicated bibliographical requirements that bibtex cannot handle. Best, Matt
