Re: [O] [PATCH] ob-shell
Hi Achim, I was wondering how it would behave if the string that is put into a variable contains newlines, backslashes and other things that bash (and other shells) treats specially. The trick with cat and BABEL_TABLE is resistant to this. As in many cases (when I use it at least) the variable come from other parts of the org file and are computed through another language (python in my case) I have such cases that would break. Also, I think the test coverage for such things is limited for ob-shell.el in the org test suite. We should probably add some test cases for this, and then make sure it works with your implementation as well. --paf On Sun, Jun 22, 2014 at 2:50 PM, Eric Schulte schulte.e...@gmail.com wrote: If this maintains existing functionality, please go ahead and apply it. Thanks, Achim Gratz strom...@nexgo.de writes: Achim Gratz writes: Sebastien Vauban writes: I just ran `make test' and got the same error for `ob-shell/bash-uses-assoc-arrays'. Yes, that's because not all versions of bash that have associative arrays can parse the bizarre quoting style that goes through a sub-process and here-document that is used to fill in the parameters. Here's a patch that implements the suggestion and tested to work correctly with Cygwin and Linux. From a79aff65d562e59ed4e01e550224eb96a665c1ae Mon Sep 17 00:00:00 2001 From: Achim Gratz strom...@stromeko.de Date: Thu, 19 Jun 2014 21:23:28 +0200 Subject: [PATCH] ob-shell: stratify shell variable quoting * lisp/ob-shell.el: Remove unused defcustom `org-babel-sh-var-quote-fmt'. (org-babel-variable-assignments:bash_array): (org-babel-variable-assignments:bash_assoc): Remove superfluous `mapcar' and double quotes around parameters. (org-babel-sh-var-to-sh): Single-quote the whole string and escape all single quotes in the original string. --- lisp/ob-shell.el | 42 ++ 1 file changed, 18 insertions(+), 24 deletions(-) diff --git a/lisp/ob-shell.el b/lisp/ob-shell.el index 474a8f2..7d87026 100644 --- a/lisp/ob-shell.el +++ b/lisp/ob-shell.el @@ -45,12 +45,6 @@ (defcustom org-babel-sh-command shell-file-name :group 'org-babel :type 'string) -(defcustom org-babel-sh-var-quote-fmt - $(cat 'BABEL_TABLE'\n%s\nBABEL_TABLE\n) - Format string used to escape variables when passed to shell scripts. - :group 'org-babel - :type 'string) - (defcustom org-babel-shell-names '(sh bash csh ash dash ksh mksh posh) List of names of shell supported by babel shell code blocks. @@ -113,28 +107,26 @@ (defun org-babel-variable-assignments:sh-generic (defun org-babel-variable-assignments:bash_array (varname values optional sep hline) Returns a list of statements declaring the values as a bash array. - (format unset %s\ndeclare -a %s=( \%s\ ) - varname varname - (mapconcat 'identity - (mapcar - (lambda (value) (org-babel-sh-var-to-sh value sep hline)) - values) - \ \))) + (format unset %s\ndeclare -a %s=( %s ) + varname varname + (mapconcat +(lambda (value) (org-babel-sh-var-to-sh value sep hline)) +values + ))) (defun org-babel-variable-assignments:bash_assoc (varname values optional sep hline) Returns a list of statements declaring the values as bash associative array. (format unset %s\ndeclare -A %s\n%s varname varname -(mapconcat 'identity - (mapcar -(lambda (items) - (format %s[\%s\]=%s -varname -(org-babel-sh-var-to-sh (car items) sep hline) -(org-babel-sh-var-to-sh (cdr items) sep hline))) -values) - \n))) +(mapconcat + (lambda (items) + (format %s[%s]=%s +varname +(org-babel-sh-var-to-sh (car items) sep hline) +(org-babel-sh-var-to-sh (cdr items) sep hline))) + values + \n))) (defun org-babel-variable-assignments:bash (varname values optional sep hline) Represents the parameters as useful Bash shell variables. @@ -163,8 +155,10 @@ (defun org-babel-sh-var-to-sh (var optional sep hline) Convert an elisp value to a shell variable. Convert an elisp var into a string of shell commands specifying a var of the same value. - (format org-babel-sh-var-quote-fmt - (org-babel-sh-var-to-string var sep hline))) + (concat ' (replace-regexp-in-string +' '\'\' +(org-babel-sh-var-to-string var sep hline)) + ')) (defun org-babel-sh-var-to-string (var optional sep hline) Convert an elisp value to a string. -- 2.0.0 Regards, Achim. -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw) -- --paf
[O] Latest Speed Keys D and U behavior
Hi, In the past speed key D (analog U) on a headline moved the whole subtree down. In the latest org-mode version the effect of speed key D is to move the headline (and only just the headline) down. BTW this change of behavior is due to a change in `org-shiftmetadown' AFAICT. Is the user who wants the old behavior back supposed to configure `org-speed-commands-user' with `org-metadown'? Personal note: I used those keys a lot as I can clearly observe since their functionality changed. And I vote for giving the speed keys D and U back their old functionality. Best regards, Marco -- Marco Wahl -- Freelancer
Re: [O] [PATCH] -for review- Tangling with variable transfer of variables
Charles C. Berry ccbe...@ucsd.edu writes:
On Fri, 20 Jun 2014, Rainer M Krug wrote:
Attached please find =the reworked patch.
1) uses local() and closes connection
2) does not leave a variable cal;led file behind
Seems to work on a few test cases.
I'd move the strings to defconsts.
Putting a newline before each `%S' will outdent the first line of
:var value when it is echoed in the session log so it will be easier to
view.
Done
===
With Eric's input on this:
Would you also change this at the end of org-babel-R-assign-elisp:
res}) name file header row-names max
-(format %s - %s name (org-babel-R-quote-tsv-field value
+(format %s - %S name
+ (if (stringp value) value (prin1-to-string value)
Good idea - done. but as far as I understand the help for the function
format %S
,
| %S means print any object as an s-expression (using `prin1').
`
the second line is redy=undant, as the function format is doing it
anyway?
I'll leave the second line out and replace it with =value= instead, but
please correct meif I am missing something here.
Thanks,
Rainer
??
I think this is innocuous for plain strings with no internal quotes, but
allows almost anything to be passed to R as a string.
So
:var x=[1 2 3 4 5]
will be passed to R as x - [1 2 3 \4\ 5]
instead of x - [1 2 3 4 5] which throws an error.
And this just works:
#+NAME: latex-capt
#+BEGIN_SRC latex
\begin{math}
y = X\beta,
\mbox{where } \beta = %beta%
\end{math}
#+END_SRC
#+BEGIN_SRC R :var ytxt=latex-capt :results raw :wrap latex
beta - 1.234
sub(%beta%,beta,ytxt)
#+END_SRC
HTH,
Chuck
--
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
pgp7cKpKLik5z.pgp
Description: PGP signature
Re: [O] [PATCH] -for review- Tangling with variable transfer of variables
One more question concerning the variable transfer of tables:
,
| (let ((file (orgtbl-to-tsv value '(:fmt org-babel-R-quote-tsv-field)))
| (header (if (or (eq (nth 1 value) 'hline) colnames-p)
| TRUE FALSE))
| (row-names (if rownames-p 1 NULL)))
| (if (= max min)
| (format %s - local({
| con - textConnection(
| %S
| )
| res - read.table(
| con,
| header= %s,
| row.names = %s,
| sep = \\\t\,
| as.is = TRUE
| )
| close(con)
| res
| }) name file header row-names)
| (format %s - local({
|con - textConnection(
| %S
|)
|res - read.table(
| con,
| header= %s,
| row.names = %s,
| sep = \\\t\,
| as.is = TRUE,
| fill = TRUE,
| col.names = paste(\V\, seq_len(%d), sep =\\)
|)
|close(con)
|res
|}) name file header row-names max
`
It seems that the two variable transfer routines only differ slightly:
1. routine: =header= is present (TRUE) and defined in table when passed
as =colnames= while
2. routine: =header= is not present (FALSE) and =colnames= is generated
as V1 .. Vn
This generation is actually not needed as this is the R default value
which is used when =colnames= is not supplied.
Also: I do not undestand why the argument =fill= is TRUE in the second
routine. From R:
,
| fill: logical. If ‘TRUE’ then in case the rows have unequal length,
| blank fields are implicitly added. See ‘Details’.
`
If I understands tables in org correctly, this is not needed as the rows
always have equal length?
so if I am not mistaken the following lines could be deleted:
,
|row.names = %s,
|sep = \\\t\,
|as.is = TRUE,
| - fill = TRUE,
| - col.names = paste(\V\, seq_len(%d), sep =\\)
`
Or am I missing something here?
Cheers,
Rainer
Charles C. Berry ccbe...@ucsd.edu writes:
On Fri, 20 Jun 2014, Rainer M Krug wrote:
Attached please find =the reworked patch.
1) uses local() and closes connection
2) does not leave a variable cal;led file behind
Seems to work on a few test cases.
I'd move the strings to defconsts.
Putting a newline before each `%S' will outdent the first line of
:var value when it is echoed in the session log so it will be easier to
view.
===
With Eric's input on this:
Would you also change this at the end of org-babel-R-assign-elisp:
res}) name file header row-names max
-(format %s - %s name (org-babel-R-quote-tsv-field value
+(format %s - %S name
+ (if (stringp value) value (prin1-to-string value)
??
I think this is innocuous for plain strings with no internal quotes, but
allows almost anything to be passed to R as a string.
So
:var x=[1 2 3 4 5]
will be passed to R as x - [1 2 3 \4\ 5]
instead of x - [1 2 3 4 5] which throws an error.
And this just works:
#+NAME: latex-capt
#+BEGIN_SRC latex
\begin{math}
y = X\beta,
\mbox{where } \beta = %beta%
\end{math}
#+END_SRC
#+BEGIN_SRC R :var ytxt=latex-capt :results raw :wrap latex
beta - 1.234
sub(%beta%,beta,ytxt)
#+END_SRC
HTH,
Chuck
--
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
pgpz3VqNs_wPq.pgp
Description: PGP signature
Re: [O] [patch, ox-latex] org-latex-logfiles-extensions
Hello, Rasmus ras...@gmx.us writes: The attached patch adds more extensions to `org-latex-logfiles-extensiosn' that shows up when using latexmk and beamer. Applied. Thank you. [...] Note: while I personally very much like this feature the default non-nil value of org-latex-remove-logfiles may slow down compilation-time. Since we have ox async export it's probably OK to ignore this, but when not using async it could be annoying since Emacs is locked. I think non-nil is fine as a default value. Regards, -- Nicolas Goaziou
Re: [O] [Bug] element cache problem with repeating timestamps
Hello, Matt Lundin m...@imapmail.org writes: A recent git pull broke logging with repeating todos. I'm guessing this has something to do with one of the recent changes to the org element cache, since setting org-element-use-cache to nil solves the problem. Recipe to replicate: 1. /usr/bin/emacs -Q -l ~/minimal.el Here is minimal.el: (add-to-list 'load-path ~/org-mode/lisp) (setq org-log-into-drawer t) 2. Open a file containing the following: * TODO Repeating task SCHEDULED: 2014-06-23 Mon 20:00 .+1d :LOGBOOK: - State DONE from TODO [2014-06-22 Sun 23:01] :END: :PROPERTIES: :LAST_REPEAT: [2014-06-22 Sun 23:01] :END: 3. Hit org-todo on the headline. The buffer then looks like this: * TODO Repeating task 2014-06-23 Mon 20:00 .+1d SCHEDULED: :LOGBOOK: - State DONE from TODO [2014-06-22 Sun 23:10] - State DONE from TODO [2014-06-22 Sun 23:10] - State DONE from TODO [2014-06-22 Sun 23:01] :END: :PROPERTIES: :LAST_REPEAT: [2014-06-22 Sun 23:10] :END: It should be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
Re: [O] [PATCH] -for review- Tangling with variable transfer of variables
Charles C. Berry ccbe...@ucsd.edu writes:
V On Fri, 20 Jun 2014, Rainer M Krug wrote:
Attached please find =the reworked patch.
1) uses local() and closes connection
2) does not leave a variable cal;led file behind
Seems to work on a few test cases.
I'd move the strings to defconsts.
Putting a newline before each `%S' will outdent the first line of
:var value when it is echoed in the session log so it will be easier to
view.
===
With Eric's input on this:
Would you also change this at the end of org-babel-R-assign-elisp:
res}) name file header row-names max
-(format %s - %s name (org-babel-R-quote-tsv-field value
+(format %s - %S name
+ (if (stringp value) value (prin1-to-string value)
??
I think this is innocuous for plain strings with no internal quotes, but
allows almost anything to be passed to R as a string.
So
:var x=[1 2 3 4 5]
will be passed to R as x - [1 2 3 \4\ 5]
instead of x - [1 2 3 4 5] which throws an error.
And this just works:
#+NAME: latex-capt
#+BEGIN_SRC latex
\begin{math}
y = X\beta,
\mbox{where } \beta = %beta%
\end{math}
#+END_SRC
#+BEGIN_SRC R :var ytxt=latex-capt :results raw :wrap latex
beta - 1.234
sub(%beta%,beta,ytxt)
#+END_SRC
OK - attached please find two patches:
0001-lisp-ob-R.el-Fix-tangling-with-tables.patch
0002-Make-transfer-of-values-from-R-type-aware.patch
The first one fixes tangling with tables including discussed
suggestions, the second one moves the definition of the R code into
defconst and introduces type awareness for the transfer of *values*, but
not tables. I reworked your suggestion and now integer are transferred
to R as integers (L) and float as double.
This already worked for tables.
Could you please check the second patch? In my checks everything worked
as expected.
Cheers,
Rainer
HTH,
Chuck
--
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
From 38c029b38c85d9f9d35d0867b332eebc3daf1aca Mon Sep 17 00:00:00 2001
From: Rainer M. Krug r.m.k...@gmail.com
Date: Fri, 20 Jun 2014 22:19:59 +0200
Subject: [PATCH 1/2] lisp/ob-R.el: Fix tangling with tables
* lisp/ob-R.el (org-babel-R-assign-elisp): Fix variable transfer of
tables by using text connections in R instead of files. Variable
transfer of tables does not depend on files anymore, i.e. works also
when tangling.
---
lisp/ob-R.el | 52
1 file changed, 32 insertions(+), 20 deletions(-)
diff --git a/lisp/ob-R.el b/lisp/ob-R.el
index a3ae1ec..c77a103 100644
--- a/lisp/ob-R.el
+++ b/lisp/ob-R.el
@@ -190,32 +190,44 @@ This function is called by `org-babel-execute-src-block'.
(if (listp value)
(let* ((lengths (mapcar 'length (org-remove-if-not 'sequencep value)))
(max (if lengths (apply 'max lengths) 0))
- (min (if lengths (apply 'min lengths) 0))
- (transition-file (org-babel-temp-file R-import-)))
+ (min (if lengths (apply 'min lengths) 0)))
;; Ensure VALUE has an orgtbl structure (depth of at least 2).
(unless (listp (car value)) (setq value (list value)))
-(with-temp-file transition-file
- (insert
- (orgtbl-to-tsv value '(:fmt org-babel-R-quote-tsv-field))
- \n))
- (let ((file (org-babel-process-file-name transition-file 'noquote))
+ (let ((file (orgtbl-to-tsv value '(:fmt org-babel-R-quote-tsv-field)))
(header (if (or (eq (nth 1 value) 'hline) colnames-p)
TRUE FALSE))
(row-names (if rownames-p 1 NULL)))
(if (= max min)
- (format %s - read.table(\%s\,
- header=%s,
- row.names=%s,
- sep=\\\t\,
- as.is=TRUE) name file header row-names)
- (format %s - read.table(\%s\,
- header=%s,
- row.names=%s,
- sep=\\\t\,
- as.is=TRUE,
- fill=TRUE,
- col.names = paste(\V\, seq_len(%d), sep =\\))
- name file header row-names max
+ (format %s - local({
+con - textConnection(
+ %S
+)
+res - read.table(
+ con,
+ header= %s,
+ row.names = %s,
+ sep = \\\t\,
+ as.is = TRUE
+)
+close(con)
+res
+}) name file header row-names)
+ (format %s - local({
+
Re: [O] [PATCH] -for review- Tangling with variable transfer of variables
Aaron Ecay aarone...@gmail.com writes: Hi Rainer, 2014ko ekainak 21an, Charles C. Berry-ek idatzi zuen: On Fri, 20 Jun 2014, Rainer M Krug wrote: Attached please find =the reworked patch. 1) uses local() and closes connection 2) does not leave a variable cal;led file behind Seems to work on a few test cases. I'd move the strings to defconsts. Putting a newline before each `%S' will outdent the first line of :var value when it is echoed in the session log so it will be easier to view. +1 to both of the above suggestions but otherwise the patch looks good and I think it should be applied. Thanks - a second patch has been send with the additional suggestions. 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 pgpR9pZQV5Uyo.pgp Description: PGP signature
Re: [O] [Bug] element cache problem with repeating timestamps
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Matt Lundin m...@imapmail.org writes: A recent git pull broke logging with repeating todos. I'm guessing this has something to do with one of the recent changes to the org element cache, since setting org-element-use-cache to nil solves the problem. It should be fixed. Thank you for reporting it. Thanks! Works fine now. Matt
Re: [O] Latest Speed Keys D and U behavior
marcowahls...@gmail.com writes: Hi, In the past speed key D (analog U) on a headline moved the whole subtree down. In the latest org-mode version the effect of speed key D is to move the headline (and only just the headline) down. BTW this change of behavior is due to a change in `org-shiftmetadown' AFAICT. Is the user who wants the old behavior back supposed to configure `org-speed-commands-user' with `org-metadown'? Personal note: I used those keys a lot as I can clearly observe since their functionality changed. And I vote for giving the speed keys D and U back their old functionality. I can confirm this bug. I consider it an undesired change since when one is on a headline, one rarely wants to move only the headline up and down. E.g., turning... * TODO Headline :LOGBOOK: CLOCK: [2014-06-23 Mon 09:34]--[2014-06-23 Mon 09:35] = 0:01 :END: ...into... :LOGBOOK: * TODO Headline CLOCK: [2014-06-23 Mon 09:34]--[2014-06-23 Mon 09:35] = 0:01 :END: ...does not make much sense. Below is a patch to fix it. Best, Matt From faf34bdedcae517e68c50ae9a77ee8086588dfe3 Mon Sep 17 00:00:00 2001 From: Matt Lundin m...@imapmail.org Date: Mon, 23 Jun 2014 09:17:54 -0500 Subject: [PATCH] Fix speedkeys to move subtrees up and down * lisp/org.el: (org-speed-commands-default) Org speed keys were not updated to reflect the recent changes to org-shiftmetaup and org-shiftmetadown. As a result the default bindings for speedkeys U and D were destructive, since they moved only single lines. Binding them to org-metaup and org-metadown fixes the problem. Thanks to Marco Wahl for reporting the problem: http://permalink.gmane.org/gmane.emacs.orgmode/87873 --- lisp/org.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lisp/org.el b/lisp/org.el index c82fd06..2b57fc0 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -19523,8 +19523,8 @@ boundaries. (s . org-narrow-to-subtree) (= . org-columns) (Outline Structure Editing) -(U . org-shiftmetaup) -(D . org-shiftmetadown) +(U . org-metaup) +(D . org-metadown) (r . org-metaright) (l . org-metaleft) (R . org-shiftmetaright) -- 2.0.0
Re: [O] Latest Speed Keys D and U behavior
Hi Matt, Matt Lundin m...@imapmail.org writes: I can confirm this bug. Applied in master, with a slightly modified changelog, thanks -- Bastien
Re: [O] Latest Speed Keys D and U behavior
Hi Marco, marcowahls...@gmail.com writes: Is the user who wants the old behavior back supposed to configure `org-speed-commands-user' with `org-metadown'? Nope -- reporting weird new behavior like you did will do :) Thanks for this, -- Bastien
[O] Source blocks with captions
Hello org-moders! I just tried to put a caption under/on/above (or anywhere for that matter) my source code block. When exporting to latex, I didn't see any caption belonging to my code block. Other backends have not been tried. How can I achieve this? For reference, I run Org-mode version 8.2.6 (release_8.2.6 @ /home/delexi/.emacs.d/ext/org-mode/lisp/) and this is the org file: * Test #+CAPTION: Test #BEGIN_SRC java // some code #END_SRC Thanks in advance, -- Alexander Baier
Re: [O] Source blocks with captions
Alexander Baier alexander.ba...@mailbox.org writes: Hello org-moders! I just tried to put a caption under/on/above (or anywhere for that matter) my source code block. When exporting to latex, I didn't see any caption belonging to my code block. Other backends have not been tried. How can I achieve this? For reference, I run Org-mode version 8.2.6 (release_8.2.6 @ /home/delexi/.emacs.d/ext/org-mode/lisp/) and this is the org file: * Test #+CAPTION: Test #BEGIN_SRC java // some code #END_SRC shouldn't that be , | #+NAME: Test ` instead of , | #+CAPTION: Test ` ? -- cheers, Thorsten
Re: [O] [Babel] [possible bug] Empty src block prevents other block to expand
Nicolas Girard girard.nicolas at gmail.com writes: The empty src block at the beginning of the following file prevents capture-tmpl to expand when tangling. I think the diagnosis is incorrect. The empty source block has no effect. Adding ':noweb yes' to `capture's header args fixes things. org-version: 8.3-8-gce2359 Chuck [snip] #+name: capture #+begin_src emacs-lisp :tangle no Add `:noweb yes' to the previous line (C Capture entry capture-tmpl) #+end_src #+begin_src emacs-lisp :noweb yes (add-to-list 'org-capture-templates ' capture 'append) #+end_src ---8--- [snip]
Re: [O] [Babel] [possible bug] Empty src block prevents other block to expand
2014-06-23 17:56 GMT+02:00 Charles Berry ccbe...@ucsd.edu: Nicolas Girard girard.nicolas at gmail.com writes: I think the diagnosis is incorrect. The empty source block has no effect. Adding ':noweb yes' to `capture's header args fixes things. Charles, thanks for your feedback. I've always been under the assumption that, when block A references B and B references C, then :noweb yes was only needed for block A. At least, but perhaps I should double check, I'm pretty sure it's the way I've been writing all my literal programming code until now. So, in this specific example, :noweb yes shouldn't be necessary but for the latest code block in the file. Am I wrong ? Cheers, Nicolas
Re: [O] [PATCH] ob-shell
Pascal Fleury writes: I was wondering how it would behave if the string that is put into a variable contains newlines, backslashes and other things that bash (and other shells) treats specially. Exactly like it does with the earlier method, except it doesn't fork and doesn't require certain versions of bash. The trick with cat and BABEL_TABLE is resistant to this. I don't think so, some older versions of bash had a parsing bug that made it croak on single quotes in here documents. Single quoting the variable content only reuires special handling of single quotes. While that is tedious and error prone to do by hand, we're doing it with elisp anyway so this doesn't pose a problem. Also, it works for just about any shell, not only those that know about $( ) command substitution and implement here documents within the substitution correctly. As in many cases (when I use it at least) the variable come from other parts of the org file and are computed through another language (python in my case) I have such cases that would break. If you have an example, please show it. Also, I think the test coverage for such things is limited for ob-shell.el in the org test suite. We should probably add some test cases for this, and then make sure it works with your implementation as well. By all means, please add such tests. While you're at it, you might want to double quote the variable expansions, which will show you that the shell is wholly capable of returning a list and even a table to Org, with or without associative arrays. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] [PATCH] -for review- Tangling with variable transfer of variables
On Mon, 23 Jun 2014, Rainer M Krug wrote:
One more question concerning the variable transfer of tables:
,
| (let ((file (orgtbl-to-tsv value '(:fmt org-babel-R-quote-tsv-field)))
| (header (if (or (eq (nth 1 value) 'hline) colnames-p)
| TRUE FALSE))
| (row-names (if rownames-p 1 NULL)))
| (if (= max min)
| (format %s - local({
| con - textConnection(
| %S
| )
| res - read.table(
| con,
| header= %s,
| row.names = %s,
| sep = \\\t\,
| as.is = TRUE
| )
| close(con)
| res
| }) name file header row-names)
| (format %s - local({
|con - textConnection(
| %S
|)
|res - read.table(
| con,
| header= %s,
| row.names = %s,
| sep = \\\t\,
| as.is = TRUE,
| fill = TRUE,
| col.names = paste(\V\, seq_len(%d), sep =\\)
|)
|close(con)
|res
|}) name file header row-names max
`
It seems that the two variable transfer routines only differ slightly:
1. routine: =header= is present (TRUE) and defined in table when passed
as =colnames= while
2. routine: =header= is not present (FALSE) and =colnames= is generated
as V1 .. Vn
This generation is actually not needed as this is the R default value
which is used when =colnames= is not supplied.
Also: I do not undestand why the argument =fill= is TRUE in the second
routine. From R:
,
| fill: logical. If ‘TRUE’ then in case the rows have unequal length,
| blank fields are implicitly added. See ‘Details’.
`
If I understands tables in org correctly, this is not needed as the rows
always have equal length?
so if I am not mistaken the following lines could be deleted:
,
|row.names = %s,
|sep = \\\t\,
|as.is = TRUE,
| - fill = TRUE,
| - col.names = paste(\V\, seq_len(%d), sep =\\)
`
Or am I missing something here?
You need not pass a table - this
#+BEGIN_SRC R :var x='(1 2 3)(4 5))
will produce a data.frame with two rows with is.na(x[2,2]) being TRUE.
Re col.names, from help(read.table)
The number of data columns is determined by looking at the first
five lines of input (or the whole file if it has less than five
lines), or from the length of 'col.names' if it is specified and
is longer. This could conceivably be wrong if 'fill' or
'blank.lines.skip' are true, so specify 'col.names' if necessary
(as in the 'Examples').
This block
#+BEGIN_SRC R :var x=(append (make-vector 10 '(1 2)) '((1 2 3)))
x
#+END_SRC
makes an 11 by 3 data.frame with all(is.na(x[,1:10]))
but taking away the col.names arg will cause it to make a 12 by 2
data.frame with x[12,1]==3 and is.na(x[12,2]).
so leave the col.names as is, I think.
Without fill, read.table will throw an error in that block
Chuck
[rest deleted]
Re: [O] [PATCH] -for review- Tangling with variable transfer of variables
On Mon, 23 Jun 2014, Rainer M Krug wrote: Charles C. Berry ccbe...@ucsd.edu writes: V On Fri, 20 Jun 2014, Rainer M Krug wrote: Attached please find =the reworked patch. 1) uses local() and closes connection 2) does not leave a variable cal;led file behind [deleted] OK - attached please find two patches: 0001-lisp-ob-R.el-Fix-tangling-with-tables.patch 0002-Make-transfer-of-values-from-R-type-aware.patch The first one fixes tangling with tables including discussed suggestions, the second one moves the definition of the R code into defconst and introduces type awareness for the transfer of *values*, but not tables. I reworked your suggestion and now integer are transferred to R as integers (L) and float as double. This already worked for tables. Could you please check the second patch? In my checks everything worked as expected. I think these are good to go. I checked several cases and all seemed to work as expected. Some comments on this and your recent posts in this thread: I see you took the suggestion to use (prin1-to-string value) on the 'left-over' objects. With that stuff like :var x=[1 2 3] will work. :-) The only failure I could trigger was with this block: #+BEGIN_SRC R :session :var x=(org-export-get-backend 'latex) x #+END_SRC which triggered 'Eval buffer', added a bunch of ^G's to my session log, and hung until I ran C-g (keyboard-quit). When run with :session none, it works. I suspected the long string tripped over a limitation or bug in iESS-mode or comint-mode, but this runs: #+BEGIN_SRC R :session :var x=(append (make-vector 1 '(1 2)) '((1 2 3))) :results output summary(x) #+END_SRC so I am not sure what gives. Chuck
Re: [O] Source blocks with captions
On 2014-06-23 17:43 Thorsten Jolitz wrote: Alexander Baier alexander.ba...@mailbox.org writes: Hello org-moders! I just tried to put a caption under/on/above (or anywhere for that matter) my source code block. When exporting to latex, I didn't see any caption belonging to my code block. Other backends have not been tried. How can I achieve this? For reference, I run Org-mode version 8.2.6 (release_8.2.6 @ /home/delexi/.emacs.d/ext/org-mode/lisp/) and this is the org file: * Test #+CAPTION: Test #BEGIN_SRC java // some code #END_SRC shouldn't that be , | #+NAME: Test ` instead of , | #+CAPTION: Test ` ? This does not work for me - I still see no caption or a similar thing in the vicinity of my code block. Does #+NAME work for you? Regards, -- Alexander Baier
Re: [O] [PATCH] ob-shell: honor the specified shell for :session
Eric Schulte writes: I thought that `org-babel-sh-command' was still used if code blocks used the keyword shell as the language. If that's not the case and there really is no more use for `org-babel-sh-command', then please go ahead and apply this patch. Done on master. In the case you mention above shell-file-name is used. Which means that if you change it in a running emacs session, then it will be picked up for shell blocks (as one might reasonably expect), whereas you would have had to change org-babel-sh-command before. None of that was documented anyway (and still isn't). 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] Source blocks with captions
Aloha Alexander,
Alexander Baier alexander.ba...@mailbox.org writes:
On 2014-06-23 17:43 Thorsten Jolitz wrote:
Alexander Baier alexander.ba...@mailbox.org writes:
Hello org-moders!
I just tried to put a caption under/on/above (or anywhere for that
matter) my source code block. When exporting to latex, I didn't see any
caption belonging to my code block. Other backends have not been
tried. How can I achieve this?
For reference, I run Org-mode version 8.2.6 (release_8.2.6 @
/home/delexi/.emacs.d/ext/org-mode/lisp/) and this is the org file:
* Test
#+CAPTION: Test
#BEGIN_SRC java
// some code
#END_SRC
shouldn't that be
,
| #+NAME: Test
`
instead of
,
| #+CAPTION: Test
`
?
This does not work for me - I still see no caption or a similar thing in
the vicinity of my code block. Does #+NAME work for you?
Regards,
There are two errors in your Org mode file on the BEGIN_SRC and END_SRC
lines.
With this code:
* Test
#+CAPTION: Test
#+BEGIN_SRC java
// some code
#+END_SRC
I get a figure with a caption when exporting to LaTeX:
\section{Test}
\label{sec-1}
\begin{figure}[H]
\begin{verbatim}
// some code
\end{verbatim}\caption{Test}
\end{figure}
You don't need to name the source code block, although it is typically a
good idea to do so.
hth,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] [ANN] ox-extras
Hello,
Aaron Ecay aarone...@gmail.com writes:
you will be able to use blocks of the following form:
#+header: :header yes
#+begin_latex
\foo{}
\bar{}
#+end_latex
These will be transformed so that the begin/end wrapper is removed and
each line is prepended with #+latex_header: on export. They can be
edited as latex code with the usual org-edit-special function (C-c ').
Actually that's rather different than the suggestion in this thread,
which was to introduce a new type of block.
This could be implemented in core, but it should use #+attr_latex
instead of #+header since this is latex related.
Regards,
--
Nicolas Goaziou
Re: [O] [PATCH] ob-shell
[re-sent, sorry if you get this twice] Eric Schulte writes: If this maintains existing functionality, please go ahead and apply it. Done on master. The tests are left untouched, I will not have time to do anything there for the next few days. Any helping hand is welcome. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
[O] impossible to have footnote touching verbatim
Hi, I'm writing a document in which I use footnotes to hold references to many tools. One often wants the tool name in tt font, and the footnote to be touching the tool name (i.e. =tool=[fn:1] ). Unfortunately currently Org-mode doesn't fontify or export tool in the above as tt. Is there a way around this? Thanks, Eric -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] impossible to have footnote touching verbatim
Hello, Eric Schulte schulte.e...@gmail.com writes: I'm writing a document in which I use footnotes to hold references to many tools. One often wants the tool name in tt font, and the footnote to be touching the tool name (i.e. =tool=[fn:1] ). Unfortunately currently Org-mode doesn't fontify or export tool in the above as tt. Is there a way around this? You could probably tweak `org-emphasis-regexp-components' in order to allow square brackets as postmatch. Regards, -- Nicolas Goaziou
[O] unattractive list spacing in ox-html export
Hi, When the lists with spaces in some (but not all) elements are exported to HTML, they result in unattractive spacing. This is due to the use of paragraph tags in some list elements, which cause large spaces between some list elements but no spaces between others. I believe something should be done to ensure consistent spacing in the HTML export of list elements. I'd suggest that every list element should be wrapped in a paragraph tag, but maybe a different solution is more appropriate. For example, the following Org-mode. 1. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. 2. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. 3. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. exports to the following html ol class=org-ol liLorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus p Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. /p /li liLorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. /li liLorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. /li /ol Thanks, Eric -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] helm and org-refile
On 6/17/14 12:20 PM, Eric Abrahamsen wrote: Hi there, I just started using helm, with some ambivalence. Turning on helm mode stompled all over my emacs, but for just that reason I suppose it might be worth trading my ido muscle memory for helm muscle memory. Anyhoo... The only thing it doesn't work well with is org-refile and friends. It can complete the filename, but not the subtree path. My org-refile-use-outline-path is set to 'file. I found this: http://permalink.gmane.org/gmane.emacs.orgmode/70751 In the replies to that was a patch for making a 'helm option for org refile, but my guess is that's well and truly out of date. Is anyone using helm and org, and have a good solution for refiling? It's actually preventing me from using refile and goto, at the moment... Have a look at the variable `org-outline-path-complete-in-steps' and its documentation. Try setting it to nil.
Re: [O] impossible to have footnote touching verbatim
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Schulte schulte.e...@gmail.com writes: I'm writing a document in which I use footnotes to hold references to many tools. One often wants the tool name in tt font, and the footnote to be touching the tool name (i.e. =tool=[fn:1] ). Unfortunately currently Org-mode doesn't fontify or export tool in the above as tt. Is there a way around this? You could probably tweak `org-emphasis-regexp-components' in order to allow square brackets as postmatch. Should this be done personally or in master? Thanks, Regards, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] unattractive list spacing in ox-html export
Hello, Eric Schulte schulte.e...@gmail.com writes: When the lists with spaces in some (but not all) elements are exported to HTML, they result in unattractive spacing. This is due to the use of paragraph tags in some list elements, which cause large spaces between some list elements but no spaces between others. I believe something should be done to ensure consistent spacing in the HTML export of list elements. I'd suggest that every list element should be wrapped in a paragraph tag, but maybe a different solution is more appropriate. Actually, there's a special case in ox-html.el (see line 2960) that prevents the first paragraph in an item to get p tag. I guess that this rule is meant for short lists, e.g., - item 1 - item 2 where you do not want a new paragraph for each item. So, the special case could be extended to also check if there's another element in the item before ignoring the tags. Regards, -- Nicolas Goaziou
Re: [O] [ANN] ox-extras
Aloha all,
Nicolas Goaziou m...@nicolasgoaziou.fr writes:
Hello,
Aaron Ecay aarone...@gmail.com writes:
you will be able to use blocks of the following form:
#+header: :header yes
#+begin_latex
\foo{}
\bar{}
#+end_latex
These will be transformed so that the begin/end wrapper is removed and
each line is prepended with #+latex_header: on export. They can be
edited as latex code with the usual org-edit-special function (C-c ').
Actually that's rather different than the suggestion in this thread,
which was to introduce a new type of block.
This could be implemented in core, but it should use #+attr_latex
instead of #+header since this is latex related.
+1.
My use case is the one Ken mentioned earlier--customizing biblatex with
Org mode header lines. I do this by googling and then experimenting
with the code chunks I discover (I don't want to be a biblatex
programmer). I format the code chunks now with a keyboard macro, which
works but is more complex than I like. A construct like the one Aaron
has implemented is handy in this situation.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
Re: [O] unattractive list spacing in ox-html export
Eric Schulte writes: I believe something should be done to ensure consistent spacing in the HTML export of list elements. I'd suggest that every list element should be wrapped in a paragraph tag, but maybe a different solution is more appropriate. Setting the spacing for paragraphs within a list in the CSS seems much easier. Besides, the content of a list item is conceptually a paragraph (the first one if there are more), so it shouldn't need to be wrapped anyway. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Waldorf MIDI Implementation additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Re: [O] impossible to have footnote touching verbatim
Eric Schulte schulte.e...@gmail.com writes: Should this be done personally or in master? I can't think of a case where it could lead to confusion, so I'd say it can go in master, at least until someone complains, if ever. BTW, as a reminder, I'm all for thinking again how emphasis/verbatim markup is defined in Org but I doubt changing it by small touches will do any good. IMO, it needs to be discussed as a whole. I think a good markup should - not need to be customizable, - allow any number of (non-consecutive) newline characters, - allow escaping markup in verbatim objects. For example, much like radio links, bold object could be defined as 1. anything but an alphanumeric character (including nothing), 2. / character, 3. an alphanumeric character, 4. anything excepted 2 or more consecutive newline characters (non-greedy), 5. an alphanumeric character, 6. / character, 7. anything but an alphanumeric character (including nothing). For simplicity, I ignore the special case /a/ for the moment. The verbatim would be the same, with a slight change in 4th element: 4. the same, with \= treated as = Regards, -- Nicolas Goaziou
Re: [O] unattractive list spacing in ox-html export
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Eric Schulte schulte.e...@gmail.com writes: When the lists with spaces in some (but not all) elements are exported to HTML, they result in unattractive spacing. This is due to the use of paragraph tags in some list elements, which cause large spaces between some list elements but no spaces between others. I believe something should be done to ensure consistent spacing in the HTML export of list elements. I'd suggest that every list element should be wrapped in a paragraph tag, but maybe a different solution is more appropriate. Actually, there's a special case in ox-html.el (see line 2960) that prevents the first paragraph in an item to get p tag. I guess that this rule is meant for short lists, e.g., - item 1 - item 2 where you do not want a new paragraph for each item. So, the special case could be extended to also check if there's another element in the item before ignoring the tags. This sounds like the best approach. The attached patch implements this change, if it looks good I'll go ahead and apply it to master. Thanks, Eric From 9af2b1c96e2062b1501cb930a1e1f95ab8c0882e Mon Sep 17 00:00:00 2001 From: Eric Schulte schulte.e...@gmail.com Date: Mon, 23 Jun 2014 17:33:18 -0400 Subject: [PATCH 1/2] inhibit p wraps in list for all or none * lisp/ox-html.el (org-html-paragraph): Extend the special case of inhibiting p wrappers to only perform such inhibition when *every* element of the list is a single element long. Otherwise unsightly spacing results. --- lisp/ox-html.el | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/lisp/ox-html.el b/lisp/ox-html.el index 762e1dc..d95ce79 100644 --- a/lisp/ox-html.el +++ b/lisp/ox-html.el @@ -2956,7 +2956,17 @@ the plist used as a communication channel. (cond ((and (eq (org-element-type parent) 'item) (= (org-element-property :begin paragraph) - (org-element-property :contents-begin parent))) + (org-element-property :contents-begin parent)) + ;; every subsequent list element is a single element long + (let ((gp (org-export-get-parent parent)) + (all-singles t)) + (org-element-map gp 'item + (lambda (object) + (let ((num-children (length (org-element-contents object + (unless (= 1 num-children) + (setq all-singles nil + info nil 'item) + all-singles)) ;; Leading paragraph in a list item have no tags. contents) ((org-html-standalone-image-p paragraph info) -- 2.0.0 -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] unattractive list spacing in ox-html export
Achim Gratz strom...@nexgo.de writes: Eric Schulte writes: I believe something should be done to ensure consistent spacing in the HTML export of list elements. I'd suggest that every list element should be wrapped in a paragraph tag, but maybe a different solution is more appropriate. Setting the spacing for paragraphs within a list in the CSS seems much easier. I disagree, editing CSS shouldn't be required for reasonable default list spacing on HTML export. Best, Eric Besides, the content of a list item is conceptually a paragraph (the first one if there are more), so it shouldn't need to be wrapped anyway. Regards, Achim. -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] impossible to have footnote touching verbatim
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Eric Schulte schulte.e...@gmail.com writes: Should this be done personally or in master? I can't think of a case where it could lead to confusion, so I'd say it can go in master, at least until someone complains, if ever. Done. Thanks -- Eric -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
Re: [O] helm and org-refile
Michael Bach pha...@gmail.com writes: On 6/17/14 12:20 PM, Eric Abrahamsen wrote: Hi there, I just started using helm, with some ambivalence. Turning on helm mode stompled all over my emacs, but for just that reason I suppose it might be worth trading my ido muscle memory for helm muscle memory. Anyhoo... The only thing it doesn't work well with is org-refile and friends. It can complete the filename, but not the subtree path. My org-refile-use-outline-path is set to 'file. I found this: http://permalink.gmane.org/gmane.emacs.orgmode/70751 In the replies to that was a patch for making a 'helm option for org refile, but my guess is that's well and truly out of date. Is anyone using helm and org, and have a good solution for refiling? It's actually preventing me from using refile and goto, at the moment... Have a look at the variable `org-outline-path-complete-in-steps' and its documentation. Try setting it to nil. Will try that, thank you!
Re: [O] unattractive list spacing in ox-html export
Eric Schulte schulte.e...@gmail.com writes: +;; every subsequent list element is a single element long You need to start with a capital and a final period. Also, it could be merged with the comment below. E.g., Paragraphs have no tag when any item in current list is either empty or consist of a single paragraph. +(let ((gp (org-export-get-parent parent)) Since you only use it once, you don't need to bind it. Just use it in `org-element-map': (org-element-map (org-export-get-parent parent) 'item ...) + (all-singles t)) + (org-element-map gp 'item +(lambda (object) + (let ((num-children (length (org-element-contents object +(unless (= 1 num-children) + (setq all-singles nil +info nil 'item) This is not sufficient, as an item could contain a single center block with many paragraphs within. IOW you also need to check the type of the single element. We also need to accept empty items. Moreover, the item could contain another element not exported (i.e. a comment), but I guess that would go a bit too far. Also, note that `org-element-map' has a mechanism to exit early (argument FIRST-MATCH), so you can avoid mapping over all items if you already know that one of them doesn't contain a single paragraph. I think the following should do the job: (not (org-element-map (org-export-get-parent parent) 'item (lambda (item) (let ((contents (org-element-contents item))) (and contents (or (cdr contents) (not (eq (org-element-type (car contents)) 'paragraph)) info 'first-match 'item)) ;; Leading paragraph in a list item have no tags. See above. Regards, -- Nicolas Goaziou
Re: [O] unattractive list spacing in ox-html export
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Eric Schulte schulte.e...@gmail.com writes: + ;; every subsequent list element is a single element long You need to start with a capital and a final period. Also, it could be merged with the comment below. E.g., Paragraphs have no tag when any item in current list is either empty or consist of a single paragraph. + (let ((gp (org-export-get-parent parent)) Since you only use it once, you don't need to bind it. Just use it in `org-element-map': (org-element-map (org-export-get-parent parent) 'item ...) + (all-singles t)) + (org-element-map gp 'item + (lambda (object) + (let ((num-children (length (org-element-contents object + (unless (= 1 num-children) + (setq all-singles nil + info nil 'item) This is not sufficient, as an item could contain a single center block with many paragraphs within. IOW you also need to check the type of the single element. We also need to accept empty items. Moreover, the item could contain another element not exported (i.e. a comment), but I guess that would go a bit too far. Also, note that `org-element-map' has a mechanism to exit early (argument FIRST-MATCH), so you can avoid mapping over all items if you already know that one of them doesn't contain a single paragraph. I think the following should do the job: (not (org-element-map (org-export-get-parent parent) 'item (lambda (item) (let ((contents (org-element-contents item))) (and contents (or (cdr contents) (not (eq (org-element-type (car contents)) 'paragraph)) info 'first-match 'item)) ;; Leading paragraph in a list item have no tags. See above. Applied with your changes. Thanks for initial pointer and the code review. Best, Eric Regards, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D (see https://u.fsf.org/yw)
