Re: [O] what settings would make original export to pdf as good as pandoc conversion?

[Samuel Wales]

[never mind the comment below..  if i use \\ instead of \, it doesn't
error, but produces default packages on the first page.  then the
document starts on the second page.]

On 3/18/18, Samuel Wales  wrote:
> On 3/13/18, Eric S Fraga  wrote:
>> Could you post a minimal example that illustrates this?
>
> here is the minimal example.  [btw, it turns out that pandoc erros
> now, so i have to either get your direct export code to work, or fix
> pandoc's export.]
>
> *** NEXTKA fixing pdf to have better paragraphs
> SCHEDULED: <2018-03-21 Wed>
> #+begin_src emacs-lisp
> (add-to-list 'org-latex-classes
>  '("article"
>   "
>\\documentclass{scrartcl}
>% alpha is the single \ for these three erroneous?  but with \\ it
> errors.
>\[DEFAULT-PACKAGES]
>\[PACKAGES]
>\[EXTRA]
>\\setlength{\\parindent}{0pt}
>\\setlength{\\parskip}{6pt}
> "
>("\\section{%s}" . "\\section*{%s}")
>("\\subsection{%s}" . "\\subsection*{%s}")
>("\\subsubsection{%s}" .
> "\\subsubsection*{%s}")
>("\\paragraph{%s}" . "\\paragraph*{%s}")
>("\\subparagraph{%s}" .
> "\\subparagraph*{%s}")))
> #+end_src
>


-- 
The Kafka Pandemic: 

The disease DOES progress. MANY people have died from it. And ANYBODY
can get it at any time.

"You’ve really gotta quit this and get moving, because this is murder
by neglect." ---
.

[O] does this pandoc error look familiar to anybody?

[Samuel Wales]

exporting to html, then converting to pdf errors.  it worked ok
before.  just wondering if anybody has seen this before and can guess
if i did something wrong at the org level?

thanks.

===
pandoc -o sickly--pdf-from-pandoc.pdf sickly--html.html
! LaTeX Error: Too deeply nested.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...

l.1358   \begin{itemize}

pandoc: Error producing PDF from TeX source
===

Re: [O] what settings would make original export to pdf as good as pandoc conversion?

[Samuel Wales]

On 3/13/18, Eric S Fraga  wrote:
> Could you post a minimal example that illustrates this?

here is the minimal example.  [btw, it turns out that pandoc erros
now, so i have to either get your direct export code to work, or fix
pandoc's export.]

*** NEXTKA fixing pdf to have better paragraphs
SCHEDULED: <2018-03-21 Wed>
#+begin_src emacs-lisp
(add-to-list 'org-latex-classes
 '("article"
  "
   \\documentclass{scrartcl}
   % alpha is the single \ for these three erroneous?  but with \\ it errors.
   \[DEFAULT-PACKAGES]
   \[PACKAGES]
   \[EXTRA]
   \\setlength{\\parindent}{0pt}
   \\setlength{\\parskip}{6pt}
"
                   ("\\section{%s}" . "\\section*{%s}")
                   ("\\subsection{%s}" . "\\subsection*{%s}")
                   ("\\subsubsection{%s}" . "\\subsubsection*{%s}")
                   ("\\paragraph{%s}" . "\\paragraph*{%s}")
                   ("\\subparagraph{%s}" . "\\subparagraph*{%s}")))
#+end_src

[O] [PATCH v2 1/3] ob-table: Fix org-sbe's handling of quotes in cell values

[Vladimir Panteleev]

* ob-table.el (org-sbe): org-sbe did the wrong thing when given a
reference to a cell containing quotes or backslashes, because it would
simply wrap any $-prefixed value in quotes, without any escaping. Fix
this by using "%S" (instead of "\"%s\"").

* test-ob-table.el: Add test.
---
 lisp/ob-table.el  |  2 +-
 testing/lisp/test-ob-table.el | 22 ++
 2 files changed, 23 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-table.el b/lisp/ob-table.el
index f6a5c88e4..105aca5e2 100644
--- a/lisp/ob-table.el
+++ b/lisp/ob-table.el
@@ -112,7 +112,7 @@ as shown in the example below.
  (prog1 nil (setq quote t))
(prog1
(cond
-(quote (format "\"%s\"" el))
+(quote (format "%S" el))
 ((stringp el) (org-no-properties el))
 (t el))
  (setq quote nil
diff --git a/testing/lisp/test-ob-table.el b/testing/lisp/test-ob-table.el
index da136cbee..3d9b1d160 100644
--- a/testing/lisp/test-ob-table.el
+++ b/testing/lisp/test-ob-table.el
@@ -30,6 +30,28 @@
 ;;   (org-test-at-id "6d2ff4ce-4489-4e2a-9c65-e3f71f77d975"
 ;; (should (= 2 (sbe take-sqrt (n "4"))
 
+(ert-deftest test-ob-table/sbe-quote ()
+  "Test that `org-sbe' can correctly handle cell values containing quotes."
+  (org-test-table-target-expect
+   "
+#+name: identity
+#+begin_src emacs-lisp :eval yes
+  x
+#+end_src
+
+| a\"b\"c | replace |
+"
+   "
+#+name: identity
+#+begin_src emacs-lisp :eval yes
+  x
+#+end_src
+
+| a\"b\"c | a\"b\"c |
+"
+   1
+   "#+TBLFM: $2 = '(org-sbe identity (x $$1))"))
+
 (provide 'test-ob-table)
 
 ;;; test-ob-table.el ends here
-- 
2.16.2

[O] [PATCH v2 2/3] ob-table: Fix org-sbe's handling of list arguments

[Vladimir Panteleev]

* ob-table.el (org-sbe): Add an explicit case for handling list
arguments. This avoids doing the wrong thing (%s-formatting a list,
thus losing syntax like double-quotes). This enables passing org-table
ranges through org-sbe in a simple and correct manner.

* test-ob-table.el: Add test.
---
 lisp/ob-table.el  | 17 +++--
 testing/lisp/test-ob-table.el | 23 +++
 2 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-table.el b/lisp/ob-table.el
index 105aca5e2..17810dd74 100644
--- a/lisp/ob-table.el
+++ b/lisp/ob-table.el
@@ -132,12 +132,17 @@ as shown in the example below.
  "("
  (mapconcat
   (lambda (var-spec)
-(if (> (length (cdr var-spec)) 1)
-(format "%S='%S"
-(car var-spec)
-(mapcar #'read (cdr var-spec)))
-  (format "%S=%s"
-  (car var-spec) (cadr var-spec
+(cond
+((> (length (cdr var-spec)) 1)
+ (format "%S='%S"
+ (car var-spec)
+ (mapcar #'read (cdr var-spec
+((stringp (cadr var-spec))
+ (format "%S=%s"
+  (car var-spec) (cadr var-spec)))
+(t
+ (format "%S=%S"
+  (car var-spec) (cadr 
var-spec)
   ',variables ", ")
  ")")
(org-babel-execute-src-block
diff --git a/testing/lisp/test-ob-table.el b/testing/lisp/test-ob-table.el
index 3d9b1d160..fb6d05796 100644
--- a/testing/lisp/test-ob-table.el
+++ b/testing/lisp/test-ob-table.el
@@ -52,6 +52,29 @@
1
"#+TBLFM: $2 = '(org-sbe identity (x $$1))"))
 
+(ert-deftest test-ob-table/sbe-list ()
+  "Test that `org-sbe' can correctly handle ranges as lists."
+  (org-test-table-target-expect
+   "
+#+name: concat
+#+begin_src emacs-lisp :eval yes
+  (mapconcat #'identity x \"\")
+#+end_src
+
+| foo | bar | replace |
+"
+   "
+#+name: concat
+#+begin_src emacs-lisp :eval yes
+  (mapconcat #'identity x \"\")
+#+end_src
+
+| foo | bar | foobar |
+"
+   1
+   "#+TBLFM: $3 = '(org-sbe concat (x   (list $1..$2)))"
+   "#+TBLFM: $3 = '(org-sbe concat (x $ (list $1..$2)))"))
+
 (provide 'test-ob-table)
 
 ;;; test-ob-table.el ends here
-- 
2.16.2

[O] [PATCH v2 0/3] org-sbe fixes

[Vladimir Panteleev]

OK, here is v2 with table-based tests.

Vladimir Panteleev (3):
  ob-table: Fix org-sbe's handling of quotes in cell values
  ob-table: Fix org-sbe's handling of list arguments
  ob-table: Mention passing ranges as lists in org-sbe's documentation

 lisp/ob-table.el  | 21 +---
 testing/lisp/test-ob-table.el | 45 +++
 2 files changed, 59 insertions(+), 7 deletions(-)

-- 
2.16.2

[O] [PATCH v2 3/3] ob-table: Mention passing ranges as lists in org-sbe's documentation

[Vladimir Panteleev]

* ob-table.el (org-sbe): Add documentation note.
---
 lisp/ob-table.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lisp/ob-table.el b/lisp/ob-table.el
index 17810dd74..d11df9abc 100644
--- a/lisp/ob-table.el
+++ b/lisp/ob-table.el
@@ -89,6 +89,8 @@ NOTE: By default, string variable names are interpreted as
 references to source-code blocks, to force interpretation of a
 cell's value as a string, prefix the identifier a \"$\" (e.g.,
 \"$$2\" instead of \"$2\" or \"$@2$2\" instead of \"@2$2\").
+This will not work with a range; instead, pass it as a list,
+e.g. (org-sbe fun (r (list $1..$2))).
 
 NOTE: It is also possible to pass header arguments to the code
 block.  In this case a table cell should hold the string value of
-- 
2.16.2

Re: [O] [PATCH 1/3] ob-table: Fix org-sbe's handling of quotes in arguments

[Nicolas Goaziou]

Vladimir Panteleev  writes:

> Ah! Well, thanks for the clarification, and apologies for the
> confusion.

Well, thanks for bearing with me.

>> I consider it to be a bug if you need to write $"string" instead of
>> "string" in any `org-sbe' call. We should not test such a mis-feature,
>> which should be removed.
>
> Agreed completely, but, wouldn't this be a breaking change? So far
> I've tried to avoid breaking any meaningful existing uses of org-sbe.

We probably need to break `org-sbe' so as to improve it. In particular,
its syntax ought to evolve, as you pointed out. However, such changes
would obviously go into master branch, not in maint.

> No problem. To clarify, would you prefer tests which still use
> $-prefixing, but with a table cell reference to get the value in the
> cell (i.e. $$2), or tests which do not use $-prefixing in order to
> interpret the string in the table cell as a reference to another block
> in the org-mode document?

At the moment, both are features described in `org-sbe' docstring, so
I think they should be both tested, if appropriate. However, I had the
former in mind when I suggested to change tests; the latter sounds very
much like over-engineering.

[O] [Bug] org-global-tags-completion-table does not include tags from buffers

[Matt Lundin]

If org-tags-alist is customized by the user, the value returned by
org-global-tags-completion-table does not include any tags from agenda
buffers and files.

This behavior contradicts the docstring of
org-global-tags-completion-table, which claims to return the list of all
tags in all agenda buffer/files.

I believe this bug was introduced with commit
4743d43dd8e448b6c440b1e4988bcd353de60cc7 in April 2016. Before that
commit, Org mode appended tags in org-tags-alist to tags gathered from
the buffer. After the commit, Org mode no longer gathers buffer tags if
org-tags-alist is defined.

Line 13731 is the key line:

(or org-current-tag-alist (org-get-buffer-tags)))

AFAICT, org-current-tag-alist only includes tags defined in
org-tag-alist and org-tag-persistent-alist. So if these are defined, the
function will never gather the buffer tags.

As an aside, this bug makes filtering the agenda by filetags or tags in
org buffers impossible due to commit
404ac42ee51f0ac0d9cfb8fbefaefbbe96c61017, which requires a match for tag
completion when hitting "/ [TAB]" in the agenda. Since
org-global-tags-completion-table does not actually return the tags in
buffers, it is impossible to filter by them.

I can reproduce this with emacs -Q (emacs 25.3 and Org mode from git).

Best,
Matt

Re: [O] [PATCH 1/3] ob-table: Fix org-sbe's handling of quotes in arguments

[Vladimir Panteleev]

Hi,

On 2018-03-18 22:24, Nicolas Goaziou wrote:

We're clearly mis-communicating. I know the difference between a symbol
and a string, and how `read' operates. I think what puzzles me is some
design choices made in `org-sbe', and the fact that the second note of
its docstring is clear as mud.


Ah! Well, thanks for the clarification, and apologies for the confusion.


I consider it to be a bug if you need to write $"string" instead of
"string" in any `org-sbe' call. We should not test such a mis-feature,
which should be removed.


Agreed completely, but, wouldn't this be a breaking change? So far I've 
tried to avoid breaking any meaningful existing uses of org-sbe.



Let me insist on this. $"string" (or $ "string") is very wrong. Please
do not write your tests on top of this. IIUC, `org-sbe' is about passing
table fields into source blocks. Let's test that instead, with a table,
and a source block. I don't mind superfluous coverage.

It is just a matter of tests. Your changes sound good. So, would you
mind adjusting your tests so we can move forward?


No problem. To clarify, would you prefer tests which still use 
$-prefixing, but with a table cell reference to get the value in the 
cell (i.e. $$2), or tests which do not use $-prefixing in order to 
interpret the string in the table cell as a reference to another block 
in the org-mode document?


--
Best regards,
 Vladimir

Re: [O] [PATCH 1/3] ob-table: Fix org-sbe's handling of quotes in arguments

[Nicolas Goaziou]

Hello,

Vladimir Panteleev  writes:

> On 2018-03-14 15:00, Nicolas Goaziou wrote:

>> I disagree. You are testing an implementation detail here: the fact that
>> "$" is not necessarily a prefix. According to the docstring, it should
>> be, so the test should use that, too. What if we rewrite `org-sbe' at
>> some point?
>
> I'm sorry if I didn't explain it properly in my previous messages.
> I'll try again.
>
> The fact that $"foo" and $ "foo" mean the same thing is not an
> implementation detail of org-sbe. It is a consequence of Emacs Lisp
> grammar.

[...]

> So, whether the test case has a space between $ and "a\"b\"c" is as
> relevant as whether it has comments, or uses tabs instead of spaces
> for indentation.
>
> I hope this explanation can put this issue to rest.

We're clearly mis-communicating. I know the difference between a symbol
and a string, and how `read' operates. I think what puzzles me is some
design choices made in `org-sbe', and the fact that the second note of
its docstring is clear as mud.

> org-sbe's docstring is misleading:

I agree.

> $ is not a way to quote just table references, but any string literals
> in general. Had it been otherwise (i.e. $-prefixing being part of the
> table reference syntax), there would be no way to pass a string
> literal (which isn't an interpolated table cell value) to the
> indicated function. The doc string should probably be improved in this
> regard.

I consider it to be a bug if you need to write $"string" instead of
"string" in any `org-sbe' call. We should not test such a mis-feature,
which should be removed.

> Adding a test which uses a table reference instead of a string literal
> won't hurt, but it would be testing several layers at once, and,
> assuming cell value interpolation into emacs lisp table formulas is
> already tested somewhere else, superfluous.

Let me insist on this. $"string" (or $ "string") is very wrong. Please
do not write your tests on top of this. IIUC, `org-sbe' is about passing
table fields into source blocks. Let's test that instead, with a table,
and a source block. I don't mind superfluous coverage.

It is just a matter of tests. Your changes sound good. So, would you
mind adjusting your tests so we can move forward?

Regards,

-- 
Nicolas Goaziou

Re: [O] org-return does not work in magit's git-commit-setup-hook

[kadal]

OK. Thanks. I've switched to Orgalist.

On 03/17/2018 02:21 AM, Nicolas Goaziou wrote:

Hello,

kadal  writes:


I have the line (add-hook 'git-commit-setup-hook 'orgstruct++-mode)
but (org-return) does not work when edting the commit message.


`orgstruct-mode' does not exist anymore in master branch (i.e., yet to
be released Org 9.2). I suggest to just remove this hook.

Regards,

Re: [O] About the assignment of FSF papers

[Nicolas Goaziou]

Hello,

stardiviner  writes:

> Here is the PDF paper where has my name. How to assign this paper?

Isn't it written on the file?

> BTW, this paper is old. 
>
> #+begin_src shell :dir "Data"
> ls -l assignment.pdf
> #+end_src
>
> #+RESULTS[<2018-03-18 01:48:36> 3c6dfd290d7adb1dab0192c0cbf97104dc0668f1]:
> : -rw-r--r-- 1 stardiviner users 307016 Apr 28 2016 assignment.pdf
>
> Does it still work? If not I need to request a new one.

The process hasn't changed for a while, so it should be fine.

> About assignment the paper, how can I assign on the PDF paper?

> And no need to send real paper to US or somewhere, right? Only digital
> paper need.

It depends on your country. Back in the days, I had to send it through
snail mail. You may want to ask to ass...@gnu.org.

Regards,

-- 
Nicolas Goaziou

Re: [O] [RFC] Add new export backend for Jekyll

[Grant Rettke]

On Sat, Mar 17, 2018 at 4:45 PM, Łukasz Stelmach  wrote:

> This is kind of work-in-progress version. "Kind of" because it satisfies
> my needs and I would like to ask what others think or need.
>
> How to test this module?
>
> Please comment.


That looks great.

Best way to start is to put it on GitHub so others can try it out.

Also be sure to search melpa.org/#/ and GitHub (and the Internet) for
anything to do with Org-Mode and Jekyll. If there is similar work, it might
be a good opportunity for collaboration.

Re: [O] How to keep correct filepaths when using the #+INCLUDE derivative?

[Nicolas Goaziou]

Hello,

"Daniel P. Gomez"  writes:

> I've fixed the implementation of `org-export--prepare-file-contents`
> so
> that links are relative to the included file. A patch is attached.
>
> I've also created two org files in the test examples directory:
> "includer-with-links.org" and "subdir/includee-with-links.org". My
> goal
> was to add a test in "test-ox.el" `test-org-export/expand-include`
> that
> checks whether, after exporting the "includer-with-links.org" file to
> Org, the headings *Source and *Target are the same.
>
> I did not figure out how to do this cleanly, so any help implementing
> the test itself would be greatly appreciated.

I applied your patch and wrote a few tests. Let me know if it works for
you.

BTW, what's your status wrt FSF papers? I don't remember if you have
signed them already.

Thank you!

Regards,

-- 
Nicolas Goaziou0x80A93738

[O] Defining the export height of a babel-generated image

[Karl Voit]

Hi!

Some babel blocks generate image files as output. Orgmode does link
them so that exporting the corresponding heading also includes the
image.

For example:

#+BEGIN_SRC plantuml :file "foobar.svg"
(*) --> "step1"
--> "step2"
--> (*)
#+END_SRC

#+RESULTS:
[[foobar.svg]]

Is is possible to define a height attribute for the result file
which is used for LaTeX/PDF export?

So far, I tried with a header argument but failed: 
   :prologue "#+ATTR_LATEX: :height 10cm"

Do you have an idea?

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: [O] mktemp for orgmode

[Karl Voit]

* John Kitchin  wrote:
>
> Can you do something like:
>
> #+BEGIN_SRC some-lang :results output org drawer :file (make-temp-file
> "prefix-")
> 
> #+END_SRC

Awesome!

I was looking in the wrong direction.

#+BEGIN_SRC plantuml :file (make-temp-file "2018-03-18-testprefix-" nil ".svg")
(*) --> "step1"

--> "step2"

--> (*)
#+END_SRC

... works as expected and even defines the correct file extension.

Thanks!

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: [O] Link abbreviations: include abbreviation table and linkwords with spaces

[ST]

Thank you!

Unfortunately my (lack of) elisp knowledge doesn't allow me to implement
this feature myself. I'll wait until somebody finds it useful enough...

On Fri, 2018-03-16 at 22:57 +0100, Nicolas Goaziou wrote:
> Hello,
> 
> ST  writes:
> 
> > to those engineers, who are responsible for adding new features: does this 
> > case
> > of enabling linkwords with spaces (see below) qualifies as a new feature
> > request?
> 
> I have no objection, but it needs to be tested carefully.
> 
> > If yes - where should I file it?
> 
> It is already filed here, on the ML. However, I suggest to give it a go,
> as it may be faster that waiting for someone to implement it.
> 
> Regards,
>