[O] Latex class files in async export?
I have the following definition in my org-mode file:
(add-to-list 'org-latex-classes ;;
https://emacs.stackexchange.com/questions/29694/spacemacs-and-org-mode-configuration-problem
'("koma-article"
"\\documentclass{scrartcl}"
("\\section{%s}" . "\\section*{%s}")
("\\subsection{%s}" . "\\subsection*{%s}")
("\\subsubsection{%s}" . "\\subsubsection*{%s}")
("\\paragraph{%s}" . "\\paragraph*{%s}")
("\\subparagraph{%s}" . "\\subparagraph*{%s}"
Yet it doesn’t seem to be visible when I do an async export to PDF. When I try
an async export to PDF, I get “Process ‘org-export-process’ exited abnormally”.
The PDF is not altered.
I’m no longer getting an export stack buffer, but when I was, it was
complaining about the class ‘koma-article’, to me indicating it couldn’t be
found. I don’t know why that buffer is no longer being generated.
Many thanks,
Ed B.
[O] [RFC PATCH] ox-extra: Merge sections from ignored headlines
Hello, I'd like to apply the following patch to maint. It solves an issue that results from using ox-extra's "ignore headlines" feature along with ox-texinfo. org-export-ignore-headlines transforms the tree to remove headlines with the "ignore" tag, moving the ignored headline's content to the previous element. This can result in a headline having multiple sections, which in turn results in ox-texinfo generating multiple menu entries. I described the problem in a bit more detail here: https://github.com/magit/magit/pull/2914#issuecomment-294663336 A couple questions: * ox-texinfo is correct in assuming the one headline to one section mapping, right? I think so, but I wasn't able to find any specific documentation on this. * Does this patch seem like a reasonable approach? I wasn't able to think of a way to modify org-export-ignore-headlines so that it doesn't create multiple sections in the first place. Thanks. -- >8 -- Subject: [RFC PATCH] ox-extra: Merge sections from ignored headlines * contrib/lisp/ox-extra.el (org-extra--merge-sections): New function. (org-export-ignore-headlines): Merge multiple sections that result from removing ignored headlines. Prevent org-export-ignore-headlines from violating the one headline to one section mapping that is relied on by at least one export backend, ox-texinfo. (ox-texinfo uses each section to generate the menu.) --- contrib/lisp/ox-extra.el | 19 +++ 1 file changed, 19 insertions(+) diff --git a/contrib/lisp/ox-extra.el b/contrib/lisp/ox-extra.el index 85dae471f..cc01edf54 100644 --- a/contrib/lisp/ox-extra.el +++ b/contrib/lisp/ox-extra.el @@ -150,8 +150,27 @@ (defun org-export-ignore-headlines (data backend info) (org-element-contents object))) (org-element-extract-element object))) info nil) + (org-extra--merge-sections data backend info) data) +(defun org-extra--merge-sections (data _backend info) + (org-element-map data 'headline +(lambda (hl) + (let ((sections + (cl-loop + for el in (org-element-map (org-element-contents hl) +'(headline section) #'identity info) + until (eq (org-element-type el) 'headline) + collect el))) +(when (and sections + (> (length sections) 1)) + (apply #'org-element-adopt-elements + (car sections) + (cl-mapcan (lambda (s) (org-element-contents s)) +(cdr sections))) + (mapc #'org-element-extract-element (cdr sections) +info)) + (defconst ox-extras '((latex-header-blocks org-latex-header-blocks-filter org-export-before-parsing-hook) (ignore-headlines org-export-ignore-headlines org-export-filter-parse-tree-functions)) -- 2.12.2
Re: [O] org-src--contents-for-write-back : preserve original major-mode, and avoid mixing tabs and spaces in org-mode buffers
On Sat, Apr 29, 2017 at 2:59 AM, Nicolas Goaziou wrote: > Hello, > > Brent Goodrick writes: > >> I do not understand what is meant by "tailored for the source" which >> is the Org buffer. All of the indentation changes being made here are >> within the temporary buffer created by with-temp-buffer, which is >> using fundamental-mode which is not the same as either emacs-lisp-mode >> or org-mode. That is the wrong mode to be in when running `indent-line-to` >> function since it is that particular editing mode that the user has >> control over the `indent-tabs-mode` variable (typically from mode hook >> functions). So I conclude that the temporary buffer, at that point in >> execution, has to be in the mode of the language used when indenting. > > This is not necessary. `org-src--contents-for-write-back' merely adds up > indentation to the existing one. Agreed. > In particular, it doesn't re-indent > lines. The indentation being added depends on Org mode (was the block in > a list? Is it a src block where special indentation rules apply...), not > on the major mode from the edit buffer. > > However, you have a point, as we need to somehow retain the values of > `indent-tabs-mode' and `tab-width' from Org source buffer, since those > may differ from the ones used in the temporary buffer. > > Also, calling `org-mode' again in the temporary buffer, in addition to > being slow, Yes, I wondered about the performance impact. Agreed. > wouldn't preserve, e.g., local values from the source > buffer. So I think the best thing to do is to store `indent-tabs-mode' > and `tab-width' from source buffer and apply them back into the > temporary buffer. > > I committed a change along those lines, along with tests, in the maint > branch. Does it fix the issues you were encountering? It works splendidly! Thanks Nicolas. --Brent
Re: [O] [PATCH] Honor the :python header argument in python src-blocks
Hello, Nathaniel Nicandro writes: > Below is a patch that should fix the problem where a python session was > being initiated without first checking the :python header argument. > > --- PATCH --- > > From a721c97924b5b965179a2dd90e54d63c7de00317 Mon Sep 17 00:00:00 2001 > From: Nathaniel Nicandro > Date: Thu, 27 Apr 2017 18:16:41 -0500 > Subject: [PATCH] Honor the :python header argument in python src-blocks > > * lisp/ob-python.el (org-babel-execute:python): > `org-babel-python-command` should be set before calling > `org-babel-python-initiate-session`. > > TINYCHANGE Applied. Thank you. Regards, -- Nicolas Goaziou
Re: [O] No explicit way to add blank lines to the beginning or end of example or source blocks
Hello, Li DebugFan writes: > No explicit way to add blank lines to the beginning or end of example or > source blocks. > For example: describing HTTP header: > --- > HTTP header consists of colon-separated name-value pairs, > and terminated by a CRLF character sequence, e.g.: > > #+BEGIN_EXAMPLE > GET / HTTP/1.1 > Host: www.example.com > > #+END_EXAMPLE > > This is line break at the end of HTTP header. > --- > But the blank line at end of example block is not exported, and neither in > src block, > I check the source, and found it maybe because of the function > `org-split-string', > its description as follow: > (defun org-split-string (string &optional separators) > "Splits STRING into substrings at SEPARATORS. > No empty strings are returned if there are matches at the beginning > and end of string." > ...) > It means `org-split-string' will ignore all blank lines at the beginning > and the end, > but what if I need some blank lines in the beginning or the end? Fixed. Thank you. Regards, -- Nicolas Goaziou
Re: [O] Bug: Canceling a TODO state change does not revert the heading [9.0.5 (9.0.5-elpa @ /home/laurence/.emacs.d/elpa/org-20170210/)]
Hello, Laurence Rochfort writes: > I notice that supplying an empty message with C-c C-k results in no > logbook entry at all. Is that intended behaviour too? C-c C-k is supposed to cancel note taking, so I guess it is. Regards, -- Nicolas Goaziou0x80A93738
Re: [O] org-src--contents-for-write-back : preserve original major-mode, and avoid mixing tabs and spaces in org-mode buffers
Hello, Brent Goodrick writes: > I do not understand what is meant by "tailored for the source" which > is the Org buffer. All of the indentation changes being made here are > within the temporary buffer created by with-temp-buffer, which is > using fundamental-mode which is not the same as either emacs-lisp-mode > or org-mode. That is the wrong mode to be in when running `indent-line-to` > function since it is that particular editing mode that the user has > control over the `indent-tabs-mode` variable (typically from mode hook > functions). So I conclude that the temporary buffer, at that point in > execution, has to be in the mode of the language used when indenting. This is not necessary. `org-src--contents-for-write-back' merely adds up indentation to the existing one. In particular, it doesn't re-indent lines. The indentation being added depends on Org mode (was the block in a list? Is it a src block where special indentation rules apply...), not on the major mode from the edit buffer. However, you have a point, as we need to somehow retain the values of `indent-tabs-mode' and `tab-width' from Org source buffer, since those may differ from the ones used in the temporary buffer. Also, calling `org-mode' again in the temporary buffer, in addition to being slow, wouldn't preserve, e.g., local values from the source buffer. So I think the best thing to do is to store `indent-tabs-mode' and `tab-width' from source buffer and apply them back into the temporary buffer. I committed a change along those lines, along with tests, in the maint branch. Does it fix the issues you were encountering? Regards, -- Nicolas Goaziou
