Re: [O] how to indent plain lists in ASCII
Hello, Samuel Wales samolog...@gmail.com writes: The old exporter indented plain lists. This does not seem to fix it: (add-to-list 'org-export-filter-plain-list-functions (lambda (plain-list back-end rest _rest) (if (eq back-end 'ascii) (replace-regexp-in-string ^plain-list) plain-list)) I don't know exactly what you mean by indented plain lists, but your code, or the following, definitely indents items. #+begin_src emacs-lisp (add-to-list 'org-export-filter-plain-list-functions (lambda (plain-list back-end rest _rest) (when (org-export-derived-backend-p back-end 'ascii) (replace-regexp-in-string ^plain-list #+end_src I don't know what a communication channel is in a filter function, however. The same as in transcoding functions. This is all explained in details within ox.el. Regards, -- Nicolas Goaziou
Re: [O] How to get === on a line by itself to be a special string
Hello, Samuel Wales samolog...@gmail.com writes: I want separators like this: === to be treated as a special string in HTML. This was the case in the old exporter. [...] I don't want them to be interpreted as code. I don't want to turn off all code just to get this one thing to work. I don't want to do ~===~. Does this mean some filter has to be used? There are a few solutions to your problem: a macro, a hook, a filter... This did not work. (add-to-list 'org-export-filter-code-functions (lambda (text back-end rest _rest) (if (eq back-end 'html) (replace-regexp-in-string ^===$ ~===~ text) text))) That's because `html' back-end never returns ^===$, but code=/code, as = is a verbatim marker. Also, the output of a filter function will appear in the final output. I doubt that you want ~===~ to appear in your HTML document. Here is one solution, with a filter: #+begin_src emacs-lisp (defun my-rule-markup (paragraph backend info) (when (and (org-export-derived-backend-p backend 'html) (string-match p\ncode=/code\n/p\n* paragraph)) hr width=\10%\ style=\width:10%;color:#000;background-color:#000;height:1px;border:none\/\n\n)) (add-to-list 'org-export-filter-paragraph-functions 'my-rule-markup) #+end_src Regards, -- Nicolas Goaziou
Re: [O] [New exporter] custom emphasis in org-emphasis-alist
Hello,
Gregor Kappler g.kapp...@gmx.net writes:
I am currently migrating my system and contribute my first stop:
custom emphasis characters that I use extensively:
- ! is used for exclamations,
- ? for questions, and
- # for in-text comments that I do not want exported.
Emphasis characters are now hard-coded. You cannot change them, though,
you can change how each back-end interprets them.
We are solidifying Org syntax for parsing purposes. Allowing variable
markup is asking for trouble. The plan is to make `org-emphasis-alist'
a defconst.
On the other hand, you may be able to parse custom markup with the help
of a filter:
#+begin_src emacs-lisp
(defun my-special-markup (text backend info)
(when (and (org-export-derived-backend-p backend 'html)
(string-match \\([('\{]\\|^\\)\\(\\([?!#]\\)\\([^
,\']\\|[^
,\'].*?\\(?:
.*?\\)\\{0,1\\}[^
,\']\\)\\3\\)\\([- .,:!?;'\)}\\]\\|$\\)
text))
(format (cond ((equal (match-string 3 text) ?)
span class=\org-question\%s/span)
((equal (match-string 3 text) #) !--%s--)
(t span class=\org-exclamation\%s/span))
(match-string 4 text
(add-to-list 'org-export-filter-plain-text-functions 'my-special-markup)
#+end_src
Regards,
--
Nicolas Goaziou
Re: [O] [New exporter] custom emphasis in org-emphasis-alist
Completing myself,
On the other hand, you may be able to parse custom markup with the help
of a filter:
#+begin_src emacs-lisp
(defun my-special-markup (text backend info)
(when (and (org-export-derived-backend-p backend 'html)
(string-match \\([ ('\{]\\|^\\)\\(\\([?!#]\\)\\([^
,\']\\|[^
,\'].*?\\(?:
.*?\\)\\{0,1\\}[^
,\']\\)\\3\\)\\([- .,:!?;'\)}\\]\\|$\\)
text))
(format (cond ((equal (match-string 3 text) ?)
span class=\org-question\%s/span)
((equal (match-string 3 text) #) !--%s--)
(t span class=\org-exclamation\%s/span))
(match-string 4 text
(add-to-list 'org-export-filter-plain-text-functions 'my-special-markup)
#+end_src
This solution will not work but in the simplest cases (no special
markup allowed within the tags).
For additional syntax, a better option would be to define a macro:
#+MACRO: excl @@html:span class=org-exclamation@@$1@@html:/span@@
Then use it within the buffer:
A paragraph and {{{excl(some *bold* text within a special
container)}}}.
This allow for some flexibility. You can even define a babel block and
call it within a paragraph for more complicated (i.e. conditional)
stuff.
Regards,
--
Nicolas Goaziou
Re: [O] compilation issues of new export framework
Nicolas Goaziou writes: Yes, I noticed this one too, but I don't know yet from where it could come from. It comes from the two autoloads, or probably only the second one as the first is later declare-function'ed anyway. If you declare these, then the defsubst get sometimes compiled as function calls and sometimes as inlined functions (the normal mode of compilation inlines them). --8---cut here---start-8--- diff --git a/lisp/org.el b/lisp/org.el index 2bfca4e..c679c5d 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -137,9 +137,6 @@ (defvar org-heading-regexp ^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$ (declare-function org-table-maybe-eval-formula org-table ()) (declare-function org-table-maybe-recalculate-line org-table ()) -(autoload 'org-element-at-point org-element) -(autoload 'org-element-type org-element) - (declare-function org-element--parse-objects org-element (beg end acc restriction)) (declare-function org-element-at-point org-element (optional keep-trail)) @@ -152,6 +149,7 @@ (defvar org-heading-regexp ^\\(\\*+\\)\\(?: +\\(.*?\\)\\)?[ \t]*$ (declare-function org-element-nested-p org-element (elem-a elem-b)) (declare-function org-element-parse-buffer org-element (optional granularity visible-only)) +(declare-function org-element-type org-element (element)) (declare-function org-element-property org-element (property element)) (declare-function org-element-put-property org-element (element property value)) --8---cut here---end---8--- If instead you really want them always replaced with the definition of the defsubst (on the assumption that this is indeed faster than a function call or permits better optimization by the bytecompiler), then these would need to be moved to org.el and their declarations removed. Alternatively the defsubsts could go into a separate file that is then required from both org.el and org-element.el None of these options solve the larger problem of the circular dependencies. PS: If compiled single, four Babel tests fail; three of them with an (invalid-function org-export-with-buffer-copy). The function it complains about is actually a macro in ox.el that is used in org-export-as before its definition. Not cool, it must be moved before org-export-as. The tests then pass with a single-compiled version of org. 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] compilation issues of new export framework
Achim Gratz strom...@nexgo.de writes: It comes from the two autoloads, or probably only the second one as the first is later declare-function'ed anyway. If you declare these, then the defsubst get sometimes compiled as function calls and sometimes as inlined functions (the normal mode of compilation inlines them). Strange, these autoloads were already there before the merge. If instead you really want them always replaced with the definition of the defsubst (on the assumption that this is indeed faster than a function call or permits better optimization by the bytecompiler), then these would need to be moved to org.el and their declarations removed. Speed is the whole point, indeed. A quick profiling with and without defsubst gives me: | defsubst | org-element-parse-buffer | 10 | 16.252699 |1.6252699 | | defun| org-element-parse-buffer | 10 | 19.812426 | 1.9812425999 | It is about 20 % faster. Alternatively the defsubsts could go into a separate file that is then required from both org.el and org-element.el None of these options solve the larger problem of the circular dependencies. Moving `org-element-type' and al. into org.el would be out of context. We may be able to require org-element from the beginning of org.el, but I think there's some serious work involved. PS: If compiled single, four Babel tests fail; three of them with an (invalid-function org-export-with-buffer-copy). The function it complains about is actually a macro in ox.el that is used in org-export-as before its definition. Not cool, it must be moved before org-export-as. The tests then pass with a single-compiled version of org. Fixed. Thank you. Regards, -- Nicolas Goaziou
[O] bug#13668: 24.2.93; strike-through in org mode
On Sun Feb 10 2013 Bastien wrote: But it appears to me that this feature could use a more sophisticated regexp matcher. Note that the 5th and 6th line are not striked through. Because the space isn't allowed within +...+ fontified constructs. There are spaces both between the 2nd and 3rd line, and between the 5th and 6th line. -- Possibly, the regexp matcher could distinguish in a smarter way between word constituents and no word constituents. (setq org-fontify-emphasized-text nil) Thanks, I'll use that. The org info node on structural markup elements does not mention such a possibility. Mhh.. yes, I'll perhaps update the manual, or just add a Worg FAQ for this. Why put this in a separate FAQ? Aren't the info pages the first source of information for such things? Roland
Re: [O] compilation issues of new export framework
Completing myself, Nicolas Goaziou n.goaz...@gmail.com writes: Speed is the whole point, indeed. A quick profiling with and without defsubst gives me: | defsubst | org-element-parse-buffer | 10 | 16.252699 |1.6252699 | | defun| org-element-parse-buffer | 10 | 19.812426 | 1.9812425999 | It is about 20 % faster. On the other hand, `org-element-type' and al. from org.el are called less often. So, it is not a problem if they are compiled as function calls. Eventually, I'd say that the situation is fine as it is. Regards, -- Nicolas Goaziou
[O] org-latex-classes with functions, incomplete doc
Hi,
the docstring for `org-latex-classes' says:
Instead of a list of sectioning commands, you can also specify
a function name. That function will be called with two
parameters, the (reduced) level of the headline, and a predicate
non-nil when the headline should be numbered. It must return
a format string in which the section title will be added.
This is wrong. The way this function is called in `org-latex-headline'
requires it to return a string with TWO format specifiers, e.g.
\section{%%s}%%s\n, the second where the CONTENT of the section is
being added. Maybe `org-latex-headline' should add %%s\n itself – as
it does for other cases?
Also, I'm using this to add an optional argument to my sections. Can I
expect this to work? (i.e. being called in a context where the variables
`info' and `headline' are defined?)
#+BEGIN_SRC emacs-lisp
(defun fb/latex-sections (level numbered)
(let* ((level (1- level))
(sec-name (nth level fb/latex-section-names))
(sec (when sec-name
(format \\%s%s%s{%%s}\n%%s
sec-name
(if numbered *)
;;
(or (when (plist-get info :toc-title)
(let ((toc-title (org-element-property
:toc-title headline)))
(when toc-title (format [%s] toc-title
)
sec))
#+END_SRC
Org-mode version 7.9.3e (7.9.3e-961-g521d47 @ /home/flo/.emacs.d/org-mode/lisp/)
--
Florian Beck
[O] bug#13668: 24.2.93; strike-through in org mode
Hi Roland, Roland Winkler wink...@gnu.org writes: There are spaces both between the 2nd and 3rd line, and between the 5th and 6th line. -- Possibly, the regexp matcher could distinguish in a smarter way between word constituents and no word constituents. Sorry I wasn't clear: by default, space is not allowed after the first * and before the second *. But yes, `org-emphasis-regexp-components' is perhaps too complex and we have been thinking of implementing this another way. Stay tuned. (setq org-fontify-emphasized-text nil) Thanks, I'll use that. The org info node on structural markup elements does not mention such a possibility. Mhh.. yes, I'll perhaps update the manual, or just add a Worg FAQ for this. Why put this in a separate FAQ? Aren't the info pages the first source of information for such things? Depends. We try to keep the info manual readable, and it's already quite long. If you can find a good place in the manual, please send a patch. Thanks, -- Bastien
Re: [O] org-latex-classes with functions, incomplete doc
Hello,
Florian Beck f...@miszellen.de writes:
the docstring for `org-latex-classes' says:
Instead of a list of sectioning commands, you can also specify
a function name. That function will be called with two
parameters, the (reduced) level of the headline, and a predicate
non-nil when the headline should be numbered. It must return
a format string in which the section title will be added.
This is wrong. The way this function is called in `org-latex-headline'
requires it to return a string with TWO format specifiers, e.g.
\section{%%s}%%s\n, the second where the CONTENT of the section is
being added. Maybe `org-latex-headline' should add %%s\n itself – as
it does for other cases?
Indeed. It's now the case. Thanks for reporting this.
Also, I'm using this to add an optional argument to my sections. Can I
expect this to work? (i.e. being called in a context where the variables
`info' and `headline' are defined?)
#+BEGIN_SRC emacs-lisp
(defun fb/latex-sections (level numbered)
(let* ((level (1- level))
(sec-name (nth level fb/latex-section-names))
(sec (when sec-name
(format \\%s%s%s{%%s}\n%%s
sec-name
(if numbered *)
;;
(or (when (plist-get info :toc-title)
(let ((toc-title (org-element-property
:toc-title headline)))
(when toc-title (format [%s] toc-title
)
sec))
#+END_SRC
Actually, the proper way to do this is to define a derived back-end with
a custom headline translation function.
#+begin_src emacs-lisp
(org-export-define-derived-backend my-latex latex
:translate-alist ((headline . fb/my-latex-headline)))
(defun fb/my-latex-headline (headline contents info)
...
Do whatever you want here)
#+end_src
Also, you can use `org-export-with-backend' as a fallback case for your
custom function.
From there you can use:
(org-export-to-buffer 'my-latex *My own export*)
or,
(org-export-to-file 'my-latex some-file.tex)
You may wrap the previous calls into an interactive command (just copy
and adapt from those in ox-latex.el). For example:
#+begin_src emacs-lisp
(defun fb/my-latex-export-to-latex
(optional async subtreep visible-only body-only ext-plist)
(interactive)
(let ((outfile (org-export-output-file-name .tex subtreep)))
(if async
(org-export-async-start
(lambda (f) (org-export-add-to-stack f 'my-latex))
`(expand-file-name
(org-export-to-file
'my-latex ,outfile ,subtreep ,visible-only ,body-only
',ext-plist)))
(org-export-to-file
'my-latex outfile subtreep visible-only body-only ext-plist
#+end_src
Optionally, you can add an entry in the dispatcher for your new command:
#+begin_src emacs-lisp
(org-export-define-derived-backend my-latex latex
:translate-alist ((headline . fb/my-latex-headline))
:menu-entry
(?l 2 ((?m With my special extension fb/my-latex-export-to-latex
#+end_src
Regards,
--
Nicolas Goaziou
[O] bug#13668: 24.2.93; strike-through in org mode
On Sun Feb 10 2013 Bastien wrote: Why put this in a separate FAQ? Aren't the info pages the first source of information for such things? Depends. We try to keep the info manual readable, and it's already quite long. If you can find a good place in the manual, please send a patch. I do not find the info nodes on Structural markup elements particularly overloaded. The node Emphasis and monospace is just one short paragraph, and org-fontify-emphasized-text could esily be mentioned there -- unless this variable also affects other things, so that it should be mentioned higher up in the node hierarchy. If such things get distributed among different places, an info manual plus a separate FAQ, they get yet more confusing, in particular for casual users of org mode. Many users will not even know (or expect) that the info manual does not give them the full story, but they need to consult other sources, too. Take the elisp manual: it's pretty big. But I like it because its authors are pretty good in making it an *efficient* and *reliable* source of information. (Here I'd like to put these words in bold, because I really appreciate this!)
[O] bug#13668: 24.2.93; strike-through in org mode
Roland Winkler wink...@gnu.org writes: I do not find the info nodes on Structural markup elements particularly overloaded. The node Emphasis and monospace is just one short paragraph, and org-fontify-emphasized-text could esily be mentioned there -- unless this variable also affects other things, so that it should be mentioned higher up in the node hierarchy. Please provide a patch. -- Bastien
[O] bug#13668: 24.2.93; strike-through in org mode
On Sun Feb 10 2013 Bastien wrote: Please provide a patch. I'd much appreciate if the org developers could do that. I have enough such things on my own emacs agenda,
[O] [Bug] Yasnippet/Org: properties messed up when expanding $1
Hi!
* Karl Voit devn...@karl-voit.at wrote:
I do face strange behavior when using yasnippet with Org-mode:
So there does not seem to be anybody who is able to fix this issue.
Is there at least somebody who can confirm this weird bug?
Thanks!
,[ Snippet «test» ]
| # name : Testing yasnippet/org issue
| # --
|
| ** Test ${1:test}
| :PROPERTIES:
| :ID: $1
| :END:
`
... results in ...
,[ test.txt with entering «foo bar» as $1 ]
| ** Test foo bar
| :PROPERTIES:
| :ID: foo bar
| :END:
`
... which is correct, when Org is not the major mode. However, when
executed with Org-mode as major mode, it results in:
,[ test.org ]
| ** Test foo bar
| :PROPERTIES:
| foo bar
| :END:
`
Therefore I guess that this is an Org-mode issue. Is somebody able
to help debug/fix this issue?
A slightly different example:
,[ snippet ]
| ** Test ${1:test}
| :PROPERTIES:
| :ID: $1-myid
| :END:
`
,[ test.org ]
| ** Test foo bar
| :PROPERTIES:
| foo bar:ID: test-myid
| :END:
`
- so the default text «test» does not get replaced by the «foo bar»
I enter as $1 and this time, the :ID: does not get removed.
Placing $1 outside of the PROPERTIES drawer, there does not seem to
be any problem.
My setup:
Org-mode version 7.9.3c (release_7.9.3c-816-g409ee8)
yasnippet (version 0.6.1b)
--
Karl Voit
Re: [O] org-latex-classes with functions, incomplete doc
Thanks for your explanations, very much appreciated.
Nicolas Goaziou n.goaz...@gmail.com writes:
the proper way to do this is to define a derived back-end with
a custom headline translation function.
Ok, I tried this. There is a problem, however. This is what I came up
with:
#+BEGIN_SRC emacs-lisp
(defun fb/org-latex-headline (headline contents info)
(let* ((full-section (org-latex-headline headline contents info))
(toc-title (if (plist-get info :toc-title)
(org-element-property :toc-title headline)))
(section-regex \\`\\(sub\\)*\\(section\\|paragraph\\){)
(new-section
(when (and toc-title
(string-match section-regex full-section))
(let ((subs (match-string 1 full-section))
(section (match-string 2 full-section))
(rest (substring full-section (match-end 0
(concat
\\ subs section [
;; replace brackets (from `org-latex-headline')
(replace-regexp-in-string
\\[ (
(replace-regexp-in-string
\\] )
toc-title))
]{ rest)
(or new-section
full-section)))
#+END_SRC
As you can see, the solution is much more convoluted.
The reason is that I have to parse the string returned by
`org-latex-headline' or am I missing something? I ran into a similar
problem while adding padding (\n - [0.4em]\n) to table
rows.
IMO, the probem is this: the translation is (mostly) application of
content to a template (a format string), but these templates are build
(mostly, sectioning is actually an exception) inside the default
translation functions. It would be much easier, when this template would
be accessible from outside, like this:
#+BEGIN_SRC emacs-lisp
(defun my-org-latex-headline (headline contents info)
(let ((sec-format
(plist-get info :sec-format))) ;; or something like that
[modify sec-format]
(plist-put info :sec-format sec-format)
(org-latex-headline)))
#+END_SRC
The same goes for other functions.
--
Florian Beck
[O] latex code block evaluation
I have this latex code block:
#+begin_src latex :file foo.pdf
\documentclass{article}
\begin{document}
...some text...
\end{document}
#+end_src
After evaluation the resulting file looks like this:
article ...some text...
I do not understand this. As far as I know it is possible to define the
latex documentclass within a code block.
--
henry; http://literaturlatenight.de
Re: [O] org-latex-classes with functions, incomplete doc
Florian Beck f...@miszellen.de writes:
Ok, I tried this. There is a problem, however. This is what I came up
with:
#+BEGIN_SRC emacs-lisp
(defun fb/org-latex-headline (headline contents info)
(let* ((full-section (org-latex-headline headline contents info))
I suggest (org-export-with-backend 'latex headline contents info) to not
depend on the actual name of the translator.
(toc-title (if (plist-get info :toc-title)
(org-element-property :toc-title headline)))
There's no :toc-title property in the communication channel. The
exhaustive list of its properties is written in ox.el, at The
Communication Channel section.
(section-regex \\`\\(sub\\)*\\(section\\|paragraph\\){)
(new-section
(when (and toc-title
(string-match section-regex full-section))
(let ((subs (match-string 1 full-section))
(section (match-string 2 full-section))
(rest (substring full-section (match-end 0
(concat
\\ subs section [
;; replace brackets (from `org-latex-headline')
(replace-regexp-in-string
\\[ (
(replace-regexp-in-string
\\] )
toc-title))
]{ rest)
(or new-section
full-section)))
#+END_SRC
As you can see, the solution is much more convoluted.
Because you're not using the proper tool. If you just want to modify the
string returned by the `latex' back-end, use a filter. You will have
access to the transcoded headline (in LaTeX format, as a string) and the
communication channel.
#+begin_src emacs-lisp
(defun fb/my-headline-transformation (headline backend info)
(when (eq backend 'latex)
;; Here HEADLINE is the output from `latex' back-end, as a string.
...
))
(add-to-list 'org-export-filter-headline-functions
'fb/my-headline-transformation)
#+end_src
What I suggest gives you access to the headline as parsed data. This is
much more powerful, but a completely different task.
IMO, the probem is this: the translation is (mostly) application of
content to a template (a format string), but these templates are build
(mostly, sectioning is actually an exception) inside the default
translation functions. It would be much easier, when this template would
be accessible from outside, like this:
There are already many ways to alter output from a back-end. It's just
a matter of using the right tool.
Regards,
--
Nicolas Goaziou
[O] comments after paragraph remove newline
If there were a blank line above the comment, the newline removal would be appropriate, but not when there is no blank line above it. === input *** test no comments one comments # test two === ascii no comments one comments two === Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
[O] internal links not being followed; instead, offer to create new heading
Hi all, I am having trouble with following internal org links. After carefully reading the documentation (especially 4.2 Internal Links http://orgmode.org/org.html#Internal-links) with the following test.org file, I would expect that C-c C-o on the link text in the bar tree would jump to the corresponding text in the foo tree. #+BEGIN_EXAMPLE * foo a string to search for * bar [[string to search]] #+END_EXAMPLE Instead, what occurs is that I get the following in the Messages buffer: #+BEGIN_QUOTE Position saved to mark ring, go back with C-c . No match - create this as a new heading? (y or n) org-link-search: No match #+END_QUOTE where the last line appears after I hit `n' in respond to the prompt. This works as expected with a minimal init loading org 6.33 that shipped with my Emacs. I have tried it with the following minimal init: #+BEGIN_SRC emacs-lisp (setq load-path (cons /home/brian/code/foreign/org-mode/lisp load-path)) (setq load-path (cons /home/brian/code/foreign/org-mode/contrib/lisp load-path)) (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-cc 'org-capture) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (setq org-directory /home/brian/docs/org) (setq org-default-notes-file ~/docs/org/inbox.org) #+END_SRC My emacs and org: Org-mode version 7.9.3e (7.9.3e-973-gba38de @ /home/brian/code/foreign/org-mode/lisp/) GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2012-08-24 on trouble, modified by Debian I don't rule out that I have misunderstood something, but the observed behaviour doesn't match (how I understand) the documented behaviour. Thanks and best, Brian vdB
Re: [O] org-latex-classes with functions, incomplete doc
Nicolas Goaziou n.goaz...@gmail.com writes: (toc-title (if (plist-get info :toc-title) (org-element-property :toc-title headline))) There's no :toc-title property in the communication channel. The exhaustive list of its properties is written in ox.el, at The Communication Channel section. Obviouly, I defined it, otherwise it wouldn't work. :options-alist ((:toc-title TOC_TITLE nil nil t) ... ) As you can see, the solution is much more convoluted. Because you're not using the proper tool. If you just want to modify the string returned by the `latex' back-end, use a filter. You will have access to the transcoded headline (in LaTeX format, as a string) and the communication channel. But not to the element properties, which is what I need. There are already many ways to alter output from a back-end. It's just a matter of using the right tool. So, which is it? I'm a bit confused right now. -- Florian Beck
Re: [O] orgstruct-mode with custom headline prefix
Christopher Schmidt christop...@ch.ristopher.com writes: Here is the patch. Now one just needs ;; Local Variables: ;; eval: (orgstruct-mode 1) ;; orgstruct-heading-prefix-regexp: ;;; ;; End: This is in master now. The commit is a3f6570. Christopher
[O] Icalendar-export, priorities missing, possible bug
Hi, When I'm exporting to icalendar, the priorities of todo items (or perhaps any items) don't get carried through correctly. It always falls back to priority 5 (the default). After doing some edebugging I found that (string-match org-priority-regexp hd) [org-icalendar.el:539] never seems to match. This might be because 'hd' is group 4 True headline from the matching done with 'org-complex-heading-regexp' whereas group 3 according to this variable's docstring should hold the Priority cookie. I guess someone who has greater knowledge of the code could see if this is really the case and fix it. I can provide more debugging output and examples if needed and if others can't reproduce this. Greetings, Anders Johansson
[O] Bug: Additional empty line in TeXinfo export of #+BEGIN_SRC ... #+END_SRC [7.9.3e (7.9.3e-957-g03e433 @ /home/fifr/.emacs.d/el-get/org-mode/lisp/)]
Consider the following minimal org-file: === One line before #+BEGIN_SRC shell Some example #+END_SRC One line after === When exporting to texi, the file contains an additional empty line before the @end example: === ... One line before @example Some example @end example One line after ... === While this makes no difference for the resulting info file when converting this file by makeinfo test.texi, it does make a difference when converting to pdf by texi2pdf test.texi: there's an extra empty line between the example and the following text. Therefore I think the exported file should not contain that empty line. Emacs : GNU Emacs 24.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10) of 2012-11-09 on lakoocha, modified by Debian Package: Org-mode version 7.9.3e (7.9.3e-957-g03e433 @ ~/.emacs.d/el-get/org-mode/lisp/)
Re: [O] Icalendar-export, priorities missing, possible bug
Hello, Anders Johansson mejlaande...@gmail.com writes: When I'm exporting to icalendar, the priorities of todo items (or perhaps any items) don't get carried through correctly. It always falls back to priority 5 (the default). After doing some edebugging I found that (string-match org-priority-regexp hd) [org-icalendar.el:539] never seems to match. This might be because 'hd' is group 4 True headline from the matching done with 'org-complex-heading-regexp' whereas group 3 according to this variable's docstring should hold the Priority cookie. I guess someone who has greater knowledge of the code could see if this is really the case and fix it. I can provide more debugging output and examples if needed and if others can't reproduce this. iCalendar export back-end has been rewritten. It is accessible from the git distribution of Org. I didn't check if that bug is still present though. Regards, -- Nicolas Goaziou
Re: [O] new exporter fails to output footnotes?
Hello, Samuel Wales samolog...@gmail.com writes: Surely this is pilot error someplace. (org-export-to-buffer 'html (get-buffer-create test) t nil t) Beware, `org-export-to-buffer' expects a string as its second argument, not a buffer. So: (org-export-to-buffer 'html test t nil t) should be enough. *** test asasdf[fn::test] *** output p asasdfsupa id=fnr.1 name=fnr.1 class=footref href=#fn.11/a/sup/p I assume you wonder why there's no footnote definition. That's because this is a body-only export. Footnote definitions belong to the global template, which is ignored when this option is active. Regards, -- Nicolas Goaziou
Re: [O] new exporter fails to output footnotes?
On 2/10/13, Nicolas Goaziou n.goaz...@gmail.com wrote: Beware, `org-export-to-buffer' expects a string as its second argument, Will fix thanks. I assume you wonder why there's no footnote definition. That's because this is a body-only export. Footnote definitions belong to the global template, which is ignored when this option is active. Why would you not want footnote definitions in a subtree body only export? I have all of my blog posts as subtrees in a single file. I want to export body only just as in the old exporter and have everything work. I cannot export HTML header, because Blogger already has its own. How do I export the subtrees with footnotes? Thanks. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] Scheduling makes link disappear
Hi, Bastien, Thanks! That fixes it and doesn't break any of the agenda views that I use. Best regards, Thomas Bastien b...@altern.org writes: Hi Thomas, Thomas Morgan t...@ziiuu.com writes: In an Org TODO list, scheduling an item that contains a link can cause the link to disappear. Thanks very for the report. Please try the attached patch and let me know if it fixes it (it should) but more importantly: if it breaks other agenda views. Best,
Re: [O] Bug: Additional empty line in TeXinfo export of #+BEGIN_SRC ... #+END_SRC [7.9.3e (7.9.3e-957-g03e433 @ /home/fifr/.emacs.d/el-get/org-mode/lisp/)]
Hello, Frank Fischer frank-fisc...@shadow-soft.de writes: Consider the following minimal org-file: === One line before #+BEGIN_SRC shell Some example #+END_SRC One line after === When exporting to texi, the file contains an additional empty line before the @end example: === ... One line before @example Some example @end example One line after ... === While this makes no difference for the resulting info file when converting this file by makeinfo test.texi, it does make a difference when converting to pdf by texi2pdf test.texi: there's an extra empty line between the example and the following text. Therefore I think the exported file should not contain that empty line. Indeed. This should now be fixed in master. Thank you for reporting this. Regards, -- Nicolas Goaziou
Re: [O] comments after paragraph remove newline
Hello, Samuel Wales samolog...@gmail.com writes: If there were a blank line above the comment, the newline removal would be appropriate, but not when there is no blank line above it. === input *** test no comments one comments # test two === ascii no comments one comments two === Blank lines below an element belong to that element, by definition. So, obviously, just add a blank line between comments and # test and it will not be removed. Regards, -- Nicolas Goaziou
Re: [O] internal links not being followed; instead, offer to create new heading
On Sun, Feb 10, 2013 at 12:53 PM, Brian van den Broek brian.van.den.br...@gmail.com wrote: Hi all, I am having trouble with following internal org links. After carefully reading the documentation (especially 4.2 Internal Links http://orgmode.org/org.html#Internal-links) with the following test.org file, I would expect that C-c C-o on the link text in the bar tree would jump to the corresponding text in the foo tree. I'd never heard of being able to do this, so I read the documentation as well and this how I parsed it: - Is link text a URL? - If yes - open url - If no, check current file - Is link text a custom ID? - If yes - go to headline with matching ID - If no, check for custom target - Is there a match between [[link text]] and an occurrence of link text (dedicated target)? - If yes - go to the dedicated target location - If no, check file type - Is this a .org file? - If yes, check for a *headline* (or possibly keywords/tags) matching the [[link text]] [1] - If no, conduct a string search for the [[link text]] [1] Quote: If no dedicated target exists, Org will search for a headline that is exactly the link text but may also include a TODO keyword and tags So, let's test this out... I created test.org with your contents and can verify that C-c C-o asks if I should create a new headline. I also created test.txt with the same contents, did =M-x org-mode= and tried the same and got the same results. So, either: 1) The documentation is incorrect (maybe), or 2) I don't know how to do C-c C-o provided by Org in a non-org file correctly (more probable) Scratch that... tried again and left Emacs in text mode (default for me when opening .txt) and manually did =M-x org-open-at-point= and the cursor moves to the first s in string to search. So, the documentation, at least from my read, does seem to describe the situation accurately. Best regards, John #+BEGIN_EXAMPLE * foo a string to search for * bar [[string to search]] #+END_EXAMPLE Instead, what occurs is that I get the following in the Messages buffer: #+BEGIN_QUOTE Position saved to mark ring, go back with C-c . No match - create this as a new heading? (y or n) org-link-search: No match #+END_QUOTE where the last line appears after I hit `n' in respond to the prompt. This works as expected with a minimal init loading org 6.33 that shipped with my Emacs. I have tried it with the following minimal init: #+BEGIN_SRC emacs-lisp (setq load-path (cons /home/brian/code/foreign/org-mode/lisp load-path)) (setq load-path (cons /home/brian/code/foreign/org-mode/contrib/lisp load-path)) (add-to-list 'auto-mode-alist '(\\.org\\' . org-mode)) (global-set-key \C-cl 'org-store-link) (global-set-key \C-cc 'org-capture) (global-set-key \C-ca 'org-agenda) (global-set-key \C-cb 'org-iswitchb) (setq org-directory /home/brian/docs/org) (setq org-default-notes-file ~/docs/org/inbox.org) #+END_SRC My emacs and org: Org-mode version 7.9.3e (7.9.3e-973-gba38de @ /home/brian/code/foreign/org-mode/lisp/) GNU Emacs 23.2.1 (x86_64-pc-linux-gnu, GTK+ Version 2.20.1) of 2012-08-24 on trouble, modified by Debian I don't rule out that I have misunderstood something, but the observed behaviour doesn't match (how I understand) the documented behaviour. Thanks and best, Brian vdB
Re: [O] org-latex-classes with functions, incomplete doc
Florian Beck f...@fbeck.net writes: Nicolas Goaziou n.goaz...@gmail.com writes: (toc-title (if (plist-get info :toc-title) (org-element-property :toc-title headline))) There's no :toc-title property in the communication channel. The exhaustive list of its properties is written in ox.el, at The Communication Channel section. Obviouly, I defined it, otherwise it wouldn't work. :options-alist ((:toc-title TOC_TITLE nil nil t) ... ) As you can see, the solution is much more convoluted. Because you're not using the proper tool. If you just want to modify the string returned by the `latex' back-end, use a filter. You will have access to the transcoded headline (in LaTeX format, as a string) and the communication channel. But not to the element properties, which is what I need. There are already many ways to alter output from a back-end. It's just a matter of using the right tool. So, which is it? I'm a bit confused right now. I now get what you intend to do (or so I think). I didn't implement this feature in ox-latex.el, mainly because a proper implementation needs to be done at the ox.el level. Anyway, we're back to step one: if you want to handle headlines differently (i.e. by adding your own properties), you need to fork `latex' back-end, as explained before. If you encounter problems, you can post back here. Regards, -- Nicolas Goaziou
Re: [O] Icalendar-export, priorities missing, possible bug
Hi, 2013-02-10 20:31, Nicolas Goaziou skrev: Hello, Anders Johansson mejlaande...@gmail.com writes: When I'm exporting to icalendar, the priorities of todo items (or perhaps any items) don't get carried through correctly. It always falls back to priority 5 (the default). After doing some edebugging I found that (string-match org-priority-regexp hd) [org-icalendar.el:539] never seems to match. This might be because 'hd' is group 4 True headline from the matching done with 'org-complex-heading-regexp' whereas group 3 according to this variable's docstring should hold the Priority cookie. I guess someone who has greater knowledge of the code could see if this is really the case and fix it. I can provide more debugging output and examples if needed and if others can't reproduce this. iCalendar export back-end has been rewritten. It is accessible from the git distribution of Org. I didn't check if that bug is still present though. Regards, Oh, that looks completely different. Taking a look at the newest git source, priority is now found like this (ox-icalendar.el) 705 (let ((pri (or (org-element-property :priority entry) 706 org-default-priority))) and assuming this is consistent with the new framework it should of course work, but I haven't tested yet. Funny that I found this problem now, using the less than a week old ELPA-package (20130204), when the new export framework was moved into core (commit 8dd2bf) just three days ago. Greetings, Anders Johansson
Re: [O] new exporter fails to output footnotes?
Samuel Wales samolog...@gmail.com writes: On 2/10/13, Nicolas Goaziou n.goaz...@gmail.com wrote: I assume you wonder why there's no footnote definition. That's because this is a body-only export. Footnote definitions belong to the global template, which is ignored when this option is active. Why would you not want footnote definitions in a subtree body only export? I didn't say I didn't want them in. I was merely describing facts. I have all of my blog posts as subtrees in a single file. I want to export body only just as in the old exporter and have everything work. I cannot export HTML header, because Blogger already has its own. How do I export the subtrees with footnotes? That's an interesting question. For now, you can't, but that's a problem. I think the framework needs a step before the template function, in order to add some persistent data, even in case of a body-only export. Perhaps an :inner-template filter, or a `body' transcoding function. Regards, -- Nicolas Goaziou
Re: [O] new exporter fails to output footnotes?
On 2/10/13, Nicolas Goaziou n.goaz...@gmail.com wrote: For now, you can't, but that's a problem. I think the framework needs a step before the template function, in order to add some persistent data, even in case of a body-only export. Thank you for the answer. Is there a way to run the old exporter then? I'd hate to have to downgrade Org for an indefinite period of time just to get footnotes back. Samuel -- The Kafka Pandemic: http://thekafkapandemic.blogspot.com The disease DOES progress. MANY people have died from it. ANYBODY can get it. There is no hope without action.
Re: [O] internal links not being followed; instead, offer to create new heading
On 10 February 2013 16:21, John Hendy jw.he...@gmail.com wrote: On Sun, Feb 10, 2013 at 12:53 PM, Brian van den Broek brian.van.den.br...@gmail.com wrote: Hi all, I am having trouble with following internal org links. After carefully reading the documentation (especially 4.2 Internal Links http://orgmode.org/org.html#Internal-links) with the following test.org file, I would expect that C-c C-o on the link text in the bar tree would jump to the corresponding text in the foo tree. I'd never heard of being able to do this, so I read the documentation as well and this how I parsed it: - Is link text a URL? - If yes - open url - If no, check current file - Is link text a custom ID? - If yes - go to headline with matching ID - If no, check for custom target - Is there a match between [[link text]] and an occurrence of link text (dedicated target)? - If yes - go to the dedicated target location - If no, check file type - Is this a .org file? - If yes, check for a *headline* (or possibly keywords/tags) matching the [[link text]] [1] - If no, conduct a string search for the [[link text]] [1] Quote: If no dedicated target exists, Org will search for a headline that is exactly the link text but may also include a TODO keyword and tags snip 1) The documentation is incorrect (maybe), or 2) I don't know how to do C-c C-o provided by Org in a non-org file correctly (more probable) snip Hi John, Thanks for the reply. This prodded me to investigate more thoroughly (and to learn how to use git bisect). I had observed that org 6.33 behaved as I expected from looking at the documentation. Bisecting led to: commit a84c8a2cba8c510acfa0c14487f6c993f664a406 Author: Carsten Dominik carsten.domi...@gmail.com Date: Fri Aug 6 08:34:33 2010 +0200 Make internal links in Org files search for an exact headline match * lisp/org.el (org-link-search-must-match-exact-headline): New option. (org-link-search-inhibit-query): New variable. (org-link-search): Search for exact headline match in Org files * doc/org.texi (Internal links): Document the changes in internal links. Internal links used to do a fuzzy text search for the link text. This patch changes the behavior for Org files. Here a link [[My Target]] now searches for an exact headline match, i.e. for a headline that does look like * My Target, optionally with TODO keyword, priority cookie and tags. The new option `org-link-search-must-match-exact-headline' is `query-to-create' by default. This means that a failed link search will offer to create the headline as a top-level headline at the end of the buffer. This corresponds to a wiki-like behavior where missing targets are automatically created. If you do not like this behavior, change the option to t. The commit alters the docs, evidently intending them to be read as you (John) read them. I'd argue that this wasn't entirely pulled off, as the passage Links such as ‘[[My Target]]’ or ‘[[My Target][Find my target]]’ lead to a text search in the current file combined with my memory of how org used to work gave me a different expectation. At any rate, to my cursory testing, (setq org-link-search-must-match-exact-headline nil) in my .emacs appears to make org behave as I expect it to. Thanks and best, Brian vdB
Re: [O] internal links not being followed; instead, offer to create new heading
On Sun, Feb 10, 2013 at 4:28 PM, Brian van den Broek brian.van.den.br...@gmail.com wrote: On 10 February 2013 16:21, John Hendy jw.he...@gmail.com wrote: On Sun, Feb 10, 2013 at 12:53 PM, Brian van den Broek brian.van.den.br...@gmail.com wrote: Hi all, I am having trouble with following internal org links. After carefully reading the documentation (especially 4.2 Internal Links http://orgmode.org/org.html#Internal-links) with the following test.org file, I would expect that C-c C-o on the link text in the bar tree would jump to the corresponding text in the foo tree. I'd never heard of being able to do this, so I read the documentation as well and this how I parsed it: - Is link text a URL? - If yes - open url - If no, check current file - Is link text a custom ID? - If yes - go to headline with matching ID - If no, check for custom target - Is there a match between [[link text]] and an occurrence of link text (dedicated target)? - If yes - go to the dedicated target location - If no, check file type - Is this a .org file? - If yes, check for a *headline* (or possibly keywords/tags) matching the [[link text]] [1] - If no, conduct a string search for the [[link text]] [1] Quote: If no dedicated target exists, Org will search for a headline that is exactly the link text but may also include a TODO keyword and tags snip 1) The documentation is incorrect (maybe), or 2) I don't know how to do C-c C-o provided by Org in a non-org file correctly (more probable) snip Hi John, Thanks for the reply. This prodded me to investigate more thoroughly (and to learn how to use git bisect). I had observed that org 6.33 behaved as I expected from looking at the documentation. Bisecting led to: commit a84c8a2cba8c510acfa0c14487f6c993f664a406 Author: Carsten Dominik carsten.domi...@gmail.com Date: Fri Aug 6 08:34:33 2010 +0200 Make internal links in Org files search for an exact headline match * lisp/org.el (org-link-search-must-match-exact-headline): New option. (org-link-search-inhibit-query): New variable. (org-link-search): Search for exact headline match in Org files * doc/org.texi (Internal links): Document the changes in internal links. Internal links used to do a fuzzy text search for the link text. This patch changes the behavior for Org files. Here a link [[My Target]] now searches for an exact headline match, i.e. for a headline that does look like * My Target, optionally with TODO keyword, priority cookie and tags. The new option `org-link-search-must-match-exact-headline' is `query-to-create' by default. This means that a failed link search will offer to create the headline as a top-level headline at the end of the buffer. This corresponds to a wiki-like behavior where missing targets are automatically created. If you do not like this behavior, change the option to t. The commit alters the docs, evidently intending them to be read as you (John) read them. I'd argue that this wasn't entirely pulled off, as the passage Links such as ‘[[My Target]]’ or ‘[[My Target][Find my target]]’ lead to a text search in the current file combined with my memory of how org used to work gave me a different expectation. Nice digging! I saw that as well... one interpretation could be that it should fall back to a full text search of the document. Another interpretation is that if it's not a URL it falls back to a text search in which text = a unique ID, dedicated target or headline. Definitely not clear, though. At any rate, to my cursory testing, (setq org-link-search-must-match-exact-headline nil) in my .emacs appears to make org behave as I expect it to. Awesome, and at the end of the day, having the functionality you *are* looking for is what really matters. Glad you found that variable! John Thanks and best, Brian vdB
Re: [O] LaTeX export: Theorem with an author
Hi, There's no right way at the moment: I forgot to implement this. Anyway, since this feature was LaTeX only, what do you think about the following syntax (which doesn't work yet): #+attr_latex: :options [Newton] #+begin_theorem Blah. #+end_theorem It is heavier but it seems more consistent to me. It does seem more consistent with things like fig captions and so on - thanks for implementing! A little bit more verbose but that's fine ... and I agree that the previous #+begin_theorem Somebody felt a bit vague. How about a middle ground like this ? #+begin_theorem :options [Him] slkdfj #+end_theorem Regards, -- Nicolas Goaziou
Re: [O] Problem with org-html-format-latex
thanks for reporting this and for the patch, I've push a slightly different fix. Please test and let me know. Sounds good to me, thanks! /v Best, -- Bastien
Re: [O] Problem with org-html-format-latex
thanks for reporting this and for the patch, I've push a slightly different fix. Please test and let me know. Sounds good to me, thanks! ... well it did sound good to me, but it still fails. Put this in *scratch*, (org-html-format-latex x 'mathjax) and C-x C-e. Within org-format-latex, file-name-nondirectory is still called on the first argument (prefix) which your patch sets to nil. The error occurs one layer deeper in the tree but still does. My patch kind of fixed that by accident, but it should be safe at least in the case of mathjax which AFAICT will never create files anywhere - so simply testing on the value of processing-type would work better, maybe? /v /v Best, -- Bastien
[O] hlines in babel output
Hi, I have the following Org document where I would like to add some extra hlines to the output. I'm using babel. I tried the ascii package but couldn't find anything giving me extra hlines. I'd also prefer to stick to just babel. Here's the example: #+begin_src org #+TITLE:hline test * Some R code I have the following R code and I want to add hlines to the final output since it is exported and needs to look good. In particular, it is desired that the last line is separated with an hline. I could do it by exporting directly to LaTeX, but I would rather export to an Org table. #+NAME:budget-dta #+begin_src R :colnames yes tt - textConnection( account p rent110 food50) ee - read.table(tt, header = TRUE) close(tt) cc - 4 ## a complicated number generated with R ee$p - ee$p * cc ee - rbind(ee, data.frame(p=sum(ee$p),account=c(total))) ee #+end_src * Actual output: #+RESULTS: budget-dta | account | p | |-+-| | rent| 440 | | food| 200 | | total | 640 | * Minimally desired output | account | p | |-+-| | rent| 440 | | food| 200 | |-+-| | total | 640 | * Most desired output |-+-| | account | p | |-+-| | rent| 440 | | food| 200 | |-+-| | total | 640 | |-+-| #+end_src -- . . . The proofs are technical in nature and provides no real understanding.
Re: [O] Fwd: Re: Bug? in texinfo exporter
Aloha Jon,
Jonathan Leech-Pepin jonathan.leechpe...@gmail.com writes:
-- Forwarded message --
From: Jonathan Leech-Pepin jonathan.leechpe...@gmail.com
Date: Feb 9, 2013 8:57 AM
Subject: Re: [O] Bug? in texinfo exporter
To: Thomas S. Dye t...@tsdye.com
Cc:
Just realized I hit reply not reply-all
If Nick's fix fixes it do much the better.com but I'm pretty sure the comma
isn't the culprit.
Yes, I believe you are right. The commas are not the culprits.
Apologies for the red herring.
Perhaps Nicolas should revert the commit? Could you check if this is
the right thing to do?
I *have* found a bug/limitation of the texinfo exporter. If a link is
split between two lines the exporter doesn't handle it correctly. A
split link is exported like @ref{A-split-link}, when it should be @ref{A
split link}, I think.
If this is a limitation, please let me know so I can put all the links
on one line.
All the best,
Tom
--
Thomas S. Dye
http://www.tsdye.com
[O] org-element-paragraph-parser fails
Remove the spaces before #+name OR take out the '- item' and org-export-dispatch succeeds. As is, it fails with org-element-paragraph-parser: Invalid search bound (wrong side of point) , | * export dispatcher | | - item | | #+name: xyz | #+BEGIN_SRC emacs-lisp | (pwd) | #+END_SRC `
[O] colorg: Weekly report
Hi, Org friends. Here is my weekly report on colorg development. colorg is a tool for real-time collaborative edition meant for Org files in the long run, and located at https://github.com/pinard/colorg. There is a client in Emacs Lisp and a server in Python. There were no change at all on the client this week, as it did its work for my tests. The effort rather went into the server to address modification clashes between collaborators. The code I want is now essentially in place. My testing has been rather minimal, so surely, bugs remain. Next weekend, I plan more careful re-reading and testing. There are a few things I know I want to improve. For example: the server might be over-cautious when deletes and inserts clash, it might better guess users' intents. François
Re: [O] Fwd: Re: Bug? in texinfo exporter
t...@tsdye.com (Thomas S. Dye) writes:
Aloha Jon,
[...]
Yes, I believe you are right. The commas are not the culprits.
Apologies for the red herring.
Perhaps Nicolas should revert the commit? Could you check if this is
the right thing to do?
My fix isn't about the comma. Didn't it work?
I *have* found a bug/limitation of the texinfo exporter. If a link is
split between two lines the exporter doesn't handle it correctly. A
split link is exported like @ref{A-split-link}, when it should be @ref{A
split link}, I think.
If this is a limitation, please let me know so I can put all the links
on one line.
There's no such limitation. Could you provide an ECM for that?
Regards,
--
Nicolas Goaziou
Re: [O] LaTeX export: Theorem with an author
Vincent Beffara vbeffara...@gmail.com writes: It does seem more consistent with things like fig captions and so on - thanks for implementing! A little bit more verbose but that's fine ... and I agree that the previous #+begin_theorem Somebody felt a bit vague. How about a middle ground like this ? #+begin_theorem :options [Him] slkdfj #+end_theorem This isn't future-proof. If, for example, we need to add options for the HTML back-end, there will be a syntax conflict. The rule is the following: - If the toggle are global, allow them on the block opening string (i.e. src-block and code toggles) - For back-end specific value, use attributes. Regards, -- Nicolas Goaziou
Re: [O] new exporter fails to output footnotes?
Samuel Wales samolog...@gmail.com writes: On 2/10/13, Nicolas Goaziou n.goaz...@gmail.com wrote: For now, you can't, but that's a problem. I think the framework needs a step before the template function, in order to add some persistent data, even in case of a body-only export. Thank you for the answer. Is there a way to run the old exporter then? I'd hate to have to downgrade Org for an indefinite period of time just to get footnotes back. Of course. Just switch to maint branch. It will use old export framework until 8.0 is out. Then you will have to keep using 7.9 /ad vitam aeternam/. Hopefully, fixing the problem is a matter of days, if not hours. I think I'm going to split template in inner-template and outer-template, the sole difference being that inner-template will always be applied, whereas outer-template will stack only unless exporting to body-only. Footnotes in HTML export should go in inner-template. Regards, -- Nicolas Goaziou
