Re: Empty headline titles unsupported: Bug?
David Masterson writes: > Nicolas Goaziou writes: > >> Sebastian Miele writes: > >>> Sebastian Miele writes: David Masterson writes: > Sebastian Miele writes: >> Currently org-syntax.org says that "TITLE can be made of any >> character but a new line. Though, it will match after every other >> part have been matched." This does not reflect the currently >> effective behavior that "* :t:" is a headline with title ":t:" and no >> tags. > > Can you describe what should happen in a parser grammar (ie. BNF)? If > not, I would tend toward rethinking the structure of the Org file so > that it can be described in a grammar. Having a good grammar for Org > files will promote it's acceptance beyond Emacs. > [...] However, the way I understand the above quote from org-syntax.org (which is, I think, in the end preferable) [...] > >>> To be clearer: Preferable to the way it currently is implemented. >>> >>> In the headline "* :t:", the above quote from org-syntax.org (at least >>> in my way of reading it) means TAGS ":t:" > >> This is your way of reading it, but it's unfortunately not the sole way >> to look at it. Also, I'm sympathetic to Ihor Radchenko's desire to see >> consistent code in that area. But being consistent means we favor one >> interpretation over the other. > > Is there anything wrong with that? > I don't think the question is whether there is anything wrong, but rather which interpretation to adopt. Currently, both use cases can be catered for. However, once you lock in one interpretation, the other use case is not possible. Which one should we favour? My personal preference would be to keep it simple. A value of :t: is a tag and you cannot have a heading of the format :t:, but that is just my view. >> Currently, what Org does in this situation is unimportant, because the >> behaviour is simply undefined, which is, IMO, tolerable. If we decide to >> define it, it needs to be documented. > > But having undefined behaviors is limiting on the portability of Org > because people are unwilling to pick it up and attempt to (say) create a > (partial) Org for other platforms (iPhone, Android, etc.). This is very much a secondary consideration. While making it as easy as possible to parse org files outside of Emacs is not a bad thing, it should not be a primary driver for how org works. Org is an emacs mode and I think we need to be careful when considering limiting what you can do with it based on how easily it can be formally specified for external tools to use. I think few org users would welcome a change which removed a feature or required them to modify their workflow just to support the development of non-emacs tools. -- Tim Cross
Re: Empty headline titles unsupported: Bug?
Nicolas Goaziou writes: > Sebastian Miele writes: >> Sebastian Miele writes: >>>David Masterson writes: Sebastian Miele writes: > Currently org-syntax.org says that "TITLE can be made of any > character but a new line. Though, it will match after every other > part have been matched." This does not reflect the currently > effective behavior that "* :t:" is a headline with title ":t:" and no > tags. Can you describe what should happen in a parser grammar (ie. BNF)? If not, I would tend toward rethinking the structure of the Org file so that it can be described in a grammar. Having a good grammar for Org files will promote it's acceptance beyond Emacs. >>> [...] However, the way I understand the above quote from >>> org-syntax.org (which is, I think, in the end preferable) [...] >> To be clearer: Preferable to the way it currently is implemented. >> >> In the headline "* :t:", the above quote from org-syntax.org (at least >> in my way of reading it) means TAGS ":t:" > This is your way of reading it, but it's unfortunately not the sole way > to look at it. Also, I'm sympathetic to Ihor Radchenko's desire to see > consistent code in that area. But being consistent means we favor one > interpretation over the other. Is there anything wrong with that? > Currently, what Org does in this situation is unimportant, because the > behaviour is simply undefined, which is, IMO, tolerable. If we decide to > define it, it needs to be documented. But having undefined behaviors is limiting on the portability of Org because people are unwilling to pick it up and attempt to (say) create a (partial) Org for other platforms (iPhone, Android, etc.). -- David Masterson
Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
Hi Nicolas,
Nicolas Goaziou writes:
> You can do it in the same patch.
Here is the updated patch, with the corresponding additions in the
manual and ORG-NEWS.
Best regards,
Juan Manuel
>From 987566d52cd36c990d3db3f83d2c6433254ac2e3 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Tue, 25 May 2021 22:18:06 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* doc/org-manual.org (Quote blocks in LaTeX export): manual updated
* etc/ORG-NEWS (Support quote blocks in LaTeX export): news updated
* lisp/ox-latex.el (latex): add `org-latex-default-quote-environment' to `:options-alist'
(org-latex-default-quote-environment): the default quote environment
is `quote'
(org-latex-quote-block): add two attributes: `environment' and `options'
---
doc/org-manual.org | 42 ++
etc/ORG-NEWS | 7 +++
lisp/ox-latex.el | 22 --
3 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/doc/org-manual.org b/doc/org-manual.org
index 118d97e0e..dd51df27e 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13919,6 +13919,48 @@ To eat the world’s due, by the grave and thee.
,#+END_VERSE
#+end_src
+*** Quote blocks in LaTeX export
+:PROPERTIES:
+:DESCRIPTION: Attributes specific to quote blocks.
+:END:
+
+#+cindex: quote blocks, in @LaTeX{} export
+#+cindex: @samp{ATTR_LATEX}, keyword
+#+cindex: org-latex-default-quote-environment
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=. For example, to choose the environment =quotation=,
+included as an alternative to =quote= in standard LaTeX classes:
+
+#+begin_example
+,#+ATTR_LATEX: :environment quotation
+,#+BEGIN_QUOTE
+some text...
+,#+END_QUOTE
+#+end_example
+
+To choose the =foreigndisplayquote= environment, included in the LaTeX
+package =csquotes=, with the =german= option, use this syntax:
+
+#+begin_example
+,#+LATEX_HEADER:\usepackage[autostyle=true]{csquotes}
+,#+ATTR_LATEX: :environment foreigndisplayquote :options {german}
+,#+BEGIN_QUOTE
+some text in German...
+,#+END_QUOTE
+#+end_example
+
+#+texinfo: @noindent
+which is exported to LaTeX as
+
+#+begin_example
+\begin{foreigndisplayquote}{german}
+some text in German...
+\end{foreigndisplayquote}
+#+end_example
+
** Markdown Export
:PROPERTIES:
:DESCRIPTION: Exporting to Markdown.
diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 8707222e0..c8a93c933 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -244,6 +244,13 @@ require the external LaTeX package =verse.sty=, wich is an extension
of the standard LaTeX environment. The purpose of these attributes is
explained below.
+*** Support quote blocks in LaTeX export
+
+The LaTeX export back-end accepts two attributes for quote blocks:
+=:environment=, for an arbitrary quoting environment (the default
+value is that of =org-latex-default-quote-environment=: ="quote"=) and
+=:options=.
+
*** =org-set-tags-command= selects tags from ~org-global-tags-completion-table~
Let ~org-set-tags-command~ TAB fast tag completion interface complete
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..9e2e7be47 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -121,6 +121,7 @@
(:latex-classes nil nil org-latex-classes)
(:latex-default-figure-position nil nil org-latex-default-figure-position)
(:latex-default-table-environment nil nil org-latex-default-table-environment)
+(:latex-default-quote-environment nil nil org-latex-default-quote-environment)
(:latex-default-table-mode nil nil org-latex-default-table-mode)
(:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
(:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
@@ -772,6 +773,13 @@ default we use here encompasses both."
:package-version '(Org . "8.0")
:type 'string)
+(defcustom org-latex-default-quote-environment "quote"
+ "Default environment used to `quote' blocks."
+ :group 'org-export-latex
+ :package-version '(Org . "9.5")
+ :type 'string
+ :safe t)
+
(defcustom org-latex-default-table-mode 'table
"Default mode for tables.
@@ -2895,10 +2903,19 @@ channel."
"Transcode a QUOTE-BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
+ (let ((environment
+ (or (org-export-read-attribute :attr_latex quote-block :environment)
+ (plist-get info :latex-default-quote-environment)))
+ (options
+ (or (org-export-read-attribute :attr_latex quote-block :options)
+ "")))
(org-latex--wrap-label
- quote-block (format "\\begin{quote}\n%s\\end{quote}" contents) info))
-
+ quote-block (format "\\begin{%s}%s\n%s\\end{%s}"
+ environment
+ options
+ contents
+ environment)
+ info)))
Radio Target
--
2.31.1
Re: BUG: eval macros not working anymore
Sorry, maybe I did not test thoroughly enough. I'll do, and come back if still necessary. thx Nicolas Goaziou schrieb am Di., 25. Mai 2021, 17:51: > Michael Dauer writes: > > > How do you do this with a #+macro keyword with arguments? > > As before, with "(eval ..." > > I might be able to give you a more specific answer when your question is > more specific, i.e., with an ECM. > > Regards, >
[PATCH] org-refile: Fix double slashes in the refile targets
Adding [PATCH] to the subject so that it appears on updates.orgmode.org.
Re: Org-export question from a pandoc user
Hello, Eric S Fraga writes: > On Tuesday, 25 May 2021 at 11:59, Denis Maier wrote: > > [...] > >> With pandoc you can add formatting information to your document >> metadata, but you can also use makefiles or external files that contain >> your settings. So, in the end your documents will only contain the contents: > > [...] > >> How do you do that in orgmode? Is that possible? > > It is possible through the use of #+include: and #+setupfile: directives > in the document, i.e. one line pointing to where you might have defined > all the meta information you mention. I addition to what Eric S. Fraga wrote above, I suggest to have a look at the fine Org manual, which illustrates some of these concepts. You can also declare all of your configuration in a publishing environment. Regards, -- Nicolas Goaziou
Re: Empty headline titles unsupported: Bug?
Hello, Sebastian Miele writes: > Sebastian Miele writes: >>David Masterson writes: >>> Sebastian Miele writes: Currently org-syntax.org says that "TITLE can be made of any character but a new line. Though, it will match after every other part have been matched." This does not reflect the currently effective behavior that "* :t:" is a headline with title ":t:" and no tags. >>> >>> Can you describe what should happen in a parser grammar (ie. BNF)? If >>> not, I would tend toward rethinking the structure of the Org file so >>> that it can be described in a grammar. Having a good grammar for Org >>> files will promote it's acceptance beyond Emacs. >> >> [...] However, the way I understand the above quote from >> org-syntax.org (which is, I think, in the end preferable) [...] > > To be clearer: Preferable to the way it currently is implemented. > > In the headline "* :t:", the above quote from org-syntax.org (at least > in my way of reading it) means TAGS ":t:" This is your way of reading it, but it's unfortunately not the sole way to look at it. Also, I'm sympathetic to Ihor Radchenko's desire to see consistent code in that area. But being consistent means we favor one interpretation over the other. We can do that, of course, but I can't see which one is better. The one you prefer might be more common, but it is also nicer to fix, by adding some space-like character in the headline. Fixing it the other way requires the same space after the headline. Of course it's not a big deal either way. The whole thread isn't, actually. Currently, what Org does in this situation is unimportant, because the behaviour is simply undefined, which is, IMO, tolerable. If we decide to define it, it needs to be documented. Regards, -- Nicolas Goaziou
Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
Juan Manuel Macías writes: > Thank you for your indications. Attached the updated patch. Thanks. I forgot to ask: could you add some documentation about it in the manual, too? > Do you need me to prepare another patch to document the modifications > and add them to org-NEWS? You can do it in the same patch. Regards,
Re: BUG: eval macros not working anymore
Michael Dauer writes: > How do you do this with a #+macro keyword with arguments? As before, with "(eval ..." I might be able to give you a more specific answer when your question is more specific, i.e., with an ECM. Regards,
Re: [wip-cite-new] Initial implementation of `biblatex' citation processor
On Fri, May 21, 2021 at 9:25 AM Bruce D'Arcus wrote: > > On Fri, May 21, 2021 at 9:13 AM Nicolas Goaziou wrote: > > So maybe we should try to converge first. Then, I'll happily implement > > the result! > > Will do; thanks! Denis Maier and I worked on this off-list. Below is our suggested revised biblatex and natbib mapping table, with the (long) explanation below it, the "extended" table for illustration below that, and the org file with the tables attached, | Style | Variant | NatBib Command | BibLaTeX Command | |---+--++--| | author (a)| caps-full (cf) || Citeauthor | | author (a)| full (f) | citeauthor*| citeauthor | | author (a)| caps (c) | Citeauthor | Citeauthor* | | author (a)| | citeauthor | citeauthor* | |---+--++--| | noauthor (na) | bare | citeyear | | | noauthor (na) | | citeyearpar| autocite*| |---+--++--| | locators (l) | bare-caps (bc) || Notecite | | locators (l) | bare (b) || notecite | | locators (l) | caps (bc)|| Pnotecite| | locators (l) | || pnotecite| |---+--++--| | nocite (n)| | nocite | nocite | |---+--++--| | text (t) | bare (b) | citealp| | | text (t) | caps (c) | Citep | Textcite | | text (t) | full (f) | citep* | | | text (t) | bare-caps (bc) | Citealp| | | text (t) | bare-full (bf) | citealp* | | | text (t) | caps-full (cf) | Citep* | | | text (t) | bare-caps-full (bcf) | Citealp* | | | text (t) | || textcite | |---+--++--| | (default) | caps (c) | Citep | Autocite | | (default) | bare (b) | citealp| cite | | (default) | bare-caps (bc) | Citealp| Cite | | (default) | full (f) | citep* | | | (default) | bare-full (bf) | citealp| | | (default) | caps-full (cf) | Citep* | | | (default) | bare-caps-full (bcf) | Citealp* | | | (default) | | citep | autocite | |---+--++--| The key change is we have split the one table in two, with a “core” that should definitely be included, and a separate table “extended” that could reflect later additions. The “core” table above provides a sensible superset of what’s in oc-natbib, and should be a solid starting point. This “extended” table, at the very end, is mostly to accommodate cases where biblatex users have a default note style and want to insert parenthetical citations, or vice versa. We do not think this is necessary initially, and some details are unclear about how best to do this. In particular, parencite and footcite are low-level commands, and in the core, we rely on mostly high-level "style-independent" commands. Hence, we have put those examples in the separate table. As you know, biblatex has an insane amount of options, and even more implemented in other packages like chicago, so it’s hard to know what to include, and effectively impossible to be comprehensive with this approach. It might be at some point users will want to be able to configure the mappings, but it does seem premature to worry about that ATM. Beyond the additional mappings, we also suggest two changes: 1. to rename the “year” style in both oc-natbib and oc-biblatex to the broader “noauthor”, aka “suppress author”. 2. to remove the “title” style (below we moved it to the "extended" table) Explanation: Earlier iterations of org-cite had an option to “suppress-author” on individual citation references using a minus sign. This has since been removed, with the idea this can and should be handled with the style system. In both oc-natbib and oc-biblatex, the “year” style achieves this for author-date styles. But there’s broader value in the feature, and “year” in that broader context is likely to be confusing, or simply wrong (e.g require a different
Re: Global variables in Org mode document with source blocks
Hi Greg, On 18-05-2021 19:25, Greg Minshall wrote: > Lennart, > > John's idea seems good. also, you could generate a separate RESULT for > each language, then :var each language's "failed" RESULT into your bash > block and fail if any of them are set? The main problem I see with that solution is that my code blocks print raw Org code/text, e.g. tables of results or a paragraph of text that depends on the computations done in the code blocks. I haven't tried, but passing and parsing those multiline RESULT blocks into a final 'conclusion' block is probably not very easy. I ended up going for a slightly adapted version of John's first idea: Adding a # failure-CODE line to any block that fails. That line is ignored on export to PDF, but can still be counted in a final code block that searches the buffer for matching regexps. Thanks for your input. Lennart. > > cheers, Greg > -- *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* L.C. Karssen 's-Hertogenbosch The Netherlands lenn...@karssen.org http://blog.karssen.org GPG key ID: A88F554A -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*- OpenPGP_signature Description: OpenPGP digital signature
Re: Global variables in Org mode document with source blocks
Dear John,
Thanks a lot for your quick reply. My apologies for not replying
earlier. Some urgent things came up that took my time.
I tried your suggestions and settled on a small adaptation of your first
suggestion. Because the output of my source blocks is raw Org code (i.e.
the report text that explains the failure), I can't directly print
=failure-DIGITS= or something similar. My solution to that is to append
=# failure-BLOCK= to the output text (which is ignored during export)
and use your =count-matches= suggestion to count those. The text =BLOCK=
is different for each code block and should allow me to specify which
blocks fail in the Conclusion section.
Thanks a lot!
Best regards,
Lennart.
On 18-05-2021 17:03, John Kitchin wrote:
> Given all the different languages involved, I don't think there is a way
> to use a common variable.
>
> One way might be to have each block output some kind of string if it
> fails, and then in the last block you could search for the buffer for
> that string. Something like this:
>
>
> * Section 1
>
> #+BEGIN_SRC sh
> false || echo "failed"-`date +'%s'`
> #+END_SRC
>
> #+RESULTS:
> : failed-1621348872
>
>
> #+BEGIN_SRC python
> import time
>
> if not False:
> print(f'failed-{time.time()}')
> #+END_SRC
>
> #+RESULTS:
> : failed-1621348926.125608
>
>
> * Final section
>
> #+BEGIN_SRC emacs-lisp
> (format "There were %s failed blocks" (count-matches "failed-[0-9]"
> (point-min) (point-max)))
> #+END_SRC
>
> #+RESULTS:
> : There were 2 failed blocks
>
> Some alternatives include writing/appending to a file on error, and then
> counting the number of lines.
>
> Another route is to use a :post header and search for the string there.
>
> #+BEGIN_SRC emacs-lisp
> (setq n-failures 0)
> #+END_SRC
>
> #+RESULTS:
> : 0
>
> #+name: fail-capture
> #+BEGIN_SRC emacs-lisp :var data=""
> (when (string-match "failed-[0-9]" data)
> (incf n-failures)
> (message "captured a failure in %s. n-failures=%s" data n-failures))
> #+END_SRC
>
> #+BEGIN_SRC sh :post fail-capture(*this*)
> false || echo "failed"-`date +'%s'`
> #+END_SRC
>
> #+RESULTS:
> : captured a failure in failed-1621349398. n-failures=1
>
>
> #+BEGIN_SRC python :post fail-capture(*this*)
> print('This did not fail')
> #+END_SRC
>
> #+RESULTS:
> : nil
>
> #+BEGIN_SRC python :post fail-capture(*this*)
> print('This failed-9')
> #+END_SRC
>
> #+RESULTS:
> : captured a failure in This failed-9
> : . n-failures=2
>
> All these approaches need you to handle and catch the errors. I think
> other kinds of errors would stop the export process. e.g. if a block
> errors out from division by zero or something.
>
> I don't know how easy it would be to check if a src block succeeded or
> not. If it was easy, you might use the org-babel-after-execute-hook
> variable to update something when a failure is detected. Some blocks
> create an *Org-Babel Error Output buffer somewhere, but i don't know if
> this is 100% reliable across all blocks.
>
> John
>
> ---
> Professor John Kitchin (he/him/his)
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>
>
> On Tue, May 18, 2021 at 9:58 AM Lennart C. Karssen > wrote:
>
> Dear list,
>
> I am working on a dynamic report in Org mode, where I use source blocks
> in various languages to process data. Several blocks produce text or
> tables that become part of the PDF on export.
>
> The final chapter should state whether all checks passed, or whether one
> or more failed (it is not necessary to know which step failed).
>
> In a single language environment, I would use a variable (called e.g.
> nrChecksFailed) that would be incremented for each failing check. In a
> single language Org document this could probably be done with a
> :session, but given that I mix Awk, Bash, Emacs lisp and R that doesn't
> look like the way to go. Do Org documents/source blocks have some
> concept of a (global) variable that I can pass to my SRC blocks and
> increment inside them?
>
> E.g. after somehow initialising nrChecksFailed = 0, I would like to do:
>
> #+header :var nFailed=nrChecksFailed :var someData=someData
> #+begin_src R :results raw
> do_some_check_here_on_someData
>
> if (check_results_OK) {
> cat("check A passed\n")
> } else {
> cat("check A *failed*\n")
> nFailed <- nFailed + 1
> }
> #+end_src
>
> So that in my conclusion chapter I can do for example:
>
> #+header: :var nFailed=nrChecksFailed
> #+begin_src bash :results raw
> if [[ nFailed -eq 0 ]]; then
> echo "All checks passed
> else
> echo "One or more checks *failed!*"
> fi
> #+end_src
>
>
> Best regards,
>
> Lennart.
>
> --
>
Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
Hi Nicolas,
Thank you for your indications. Attached the updated patch.
Do you need me to prepare another patch to document the modifications
and add them to org-NEWS?
Best regards,
Juan Manuel
Nicolas Goaziou writes:
> Hello,
>
> Juan Manuel Macías writes:
>
>> Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
>
> Thank you. Some comments follow.
>
>> +(defcustom org-latex-default-quote-environment "quote"
>> + "Default environment used to `quote' environment."
>
> --> Default environment used for "quote" blocks.
>
>> + :group 'org-export-latex
>> + :version "24.4"
>> + :package-version '(Org . "8.0")
>
> You can remove the :version keyword. And :package-version is wrong.
>
>> + :type 'string)
>
> You also need to add :safe t
>
>> (defcustom org-latex-default-table-mode 'table
>>"Default mode for tables.
>>
>> @@ -2895,9 +2903,17 @@ channel."
>>"Transcode a QUOTE-BLOCK element from Org to LaTeX.
>> CONTENTS holds the contents of the block. INFO is a plist
>> holding contextual information."
>> + (let* ((env (org-export-read-attribute :attr_latex quote-block
>> :environment))
>> + (opt (org-export-read-attribute :attr_latex quote-block :options))
>> + (current-env (if env env org-latex-default-quote-environment))
>> + (current-opt (if opt opt "")))
>
> We don't use global variables directly as above, but use
>
> (plist-get info :latex-default-quote-environment)
>
> instead. This could be written as
>
>
>(let ((environment
> (or (org-export-read-attribute :attr_latex quote-block :environment)
> (plist-get info :latex-default-quote-environment)))
> (options
> (or (org-export-read-attribute :attr_latex quote-block :options)
> "")))
> ...)
>
> Could you send an updated patch?
>
> Regards,
>From eea6956e1baa07c9a9753ed71be48a1e962442a9 Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias
Date: Tue, 25 May 2021 14:02:06 +0200
Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block
* lisp/ox-latex.el (latex): add `org-latex-default-quote-environment' to `:options-alist'
(org-latex-default-quote-environment): the default quote environment
is `quote'
(org-latex-quote-block): add two attributes: `environment' and `options'
---
lisp/ox-latex.el | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..c4f2c6f53 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -121,6 +121,7 @@
(:latex-classes nil nil org-latex-classes)
(:latex-default-figure-position nil nil org-latex-default-figure-position)
(:latex-default-table-environment nil nil org-latex-default-table-environment)
+(:latex-default-quote-environment nil nil org-latex-default-quote-environment)
(:latex-default-table-mode nil nil org-latex-default-table-mode)
(:latex-diary-timestamp-format nil nil org-latex-diary-timestamp-format)
(:latex-footnote-defined-format nil nil org-latex-footnote-defined-format)
@@ -772,6 +773,13 @@ default we use here encompasses both."
:package-version '(Org . "8.0")
:type 'string)
+(defcustom org-latex-default-quote-environment "quote"
+ "Default environment used to `quote' blocks."
+ :group 'org-export-latex
+ :package-version '(Org . "9.5")
+ :type 'string
+ :safe t)
+
(defcustom org-latex-default-table-mode 'table
"Default mode for tables.
@@ -2895,10 +2903,19 @@ channel."
"Transcode a QUOTE-BLOCK element from Org to LaTeX.
CONTENTS holds the contents of the block. INFO is a plist
holding contextual information."
+ (let ((environment
+ (or (org-export-read-attribute :attr_latex quote-block :environment)
+ (plist-get info :latex-default-quote-environment)))
+ (options
+ (or (org-export-read-attribute :attr_latex quote-block :options)
+ "")))
(org-latex--wrap-label
- quote-block (format "\\begin{quote}\n%s\\end{quote}" contents) info))
-
+ quote-block (format "\\begin{%s}%s\n%s\\end{%s}"
+ environment
+ options
+ contents
+ environment)
+ info)))
Radio Target
--
2.31.1
Re: Org-export question from a pandoc user
On Tuesday, 25 May 2021 at 11:59, Denis Maier wrote: [...] > With pandoc you can add formatting information to your document > metadata, but you can also use makefiles or external files that contain > your settings. So, in the end your documents will only contain the contents: [...] > How do you do that in orgmode? Is that possible? It is possible through the use of #+include: and #+setupfile: directives in the document, i.e. one line pointing to where you might have defined all the meta information you mention. I actually tend to use the autoinsert package (which comes by default with Emacs) which inserts a template suitable for most of my documents whenever I visit a new file. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4.6-542-gf72a65
Re: BUG: eval macros not working anymore
How do you do this with a #+macro keyword with arguments?
The old implementation checked the string for a "(eval" prefix.
Nicolas Goaziou schrieb am Di., 25. Mai 2021,
11:14:
> Hello,
>
> Michael Dauer writes:
>
> > at least not compatible with before.
> >
> > Probably caused by commit 8abdbbee395f284f2262a89187d662eaf40080b1.
> >
> > originally correct macro ("macroA" . "(eval
> > do-something-dynamically-at-macro-expansion)")
> >
> > How should this be achieved now? (functionp "any-string") is nil
>
> I think you need to write
>
> ("macroA" . (lambda ( _)
> (do-something-dynamically-at-macro-expansion)))
>
> Regards,
> --
> Nicolas Goaziou
>
Re: Empty headline titles unsupported: Bug?
Sebastian Miele writes: >David Masterson writes: >> Sebastian Miele writes: >>> Currently org-syntax.org says that "TITLE can be made of any >>> character but a new line. Though, it will match after every other >>> part have been matched." This does not reflect the currently >>> effective behavior that "* :t:" is a headline with title ":t:" and no >>> tags. >> >> Can you describe what should happen in a parser grammar (ie. BNF)? If >> not, I would tend toward rethinking the structure of the Org file so >> that it can be described in a grammar. Having a good grammar for Org >> files will promote it's acceptance beyond Emacs. > > [...] However, the way I understand the above quote from > org-syntax.org (which is, I think, in the end preferable) [...] To be clearer: Preferable to the way it currently is implemented. In the headline "* :t:", the above quote from org-syntax.org (at least in my way of reading it) means TAGS ":t:" (which is an "other part [to be] matched [before the TITLE]") and TITLE "" (which is matched "after every other part"). But the way Org currently is implemented is different in such cases (no TAGS, the ":t:" is the TITLE).
Re: Empty headline titles unsupported: Bug?
Hi David and all, David Masterson writes: > Sebastian Miele writes: >> Currently org-syntax.org says that "TITLE can be made of any >> character but a new line. Though, it will match after every other >> part have been matched." This does not reflect the currently >> effective behavior that "* :t:" is a headline with title ":t:" and no >> tags. > > Can you describe what should happen in a parser grammar (ie. BNF)? If > not, I would tend toward rethinking the structure of the Org file so > that it can be described in a grammar. Having a good grammar for Org > files will promote it's acceptance beyond Emacs. I do not know whether it can be expressed in a context-free grammar, although it may very well be possible. However, the way I understand the above quote from org-syntax.org (which is, I think, in the end preferable) is concisely expressible in a regular expression language that can distinguish between greedy and non-greedy matching of subexpressions, including Emacs Lisp's regular expressions: #+BEGIN_SRC elisp (rx line-start (maximal-match STARS SPACE) (maximal-match (optional KEYWORD SPACE)) (maximal-match (optional PRIORITY SPACE)) (maximal-match (optional COMMENT SPACE)) (minimal-match (optional TITLE SPACE)) (maximal-match (optional TAGS)) (maximal-match (optional SPACE)) line-end) #+END_SRC SPACE is (1+ (any " \t")). TITLE is (1+ not-newline). In the following, I concentrate on differences from org-syntax.org. The above expression contains COMMENT (matching "COMMENT") not as part of the title but as separate entity. Although this is contrary to org-syntax.org, it is how it is implemented now, e.g., in org-element-headline-parser. TAGS currently effectively is (seq ":" (1+ TAG ":")). In particular, that means a TAGS specification in a headline must define at least one tag. I suggest to change that into (seq ":" (0+ TAG ":")), i.e., to also allow TAGS specifications of zero tags (just ":"). This would enable to clearly disambuate the following ambiguity between TITLEs and TAGS: #+BEGIN_SRC org ,* :t: ,* :t: : #+END_SRC The former headline would have empty TITLE and TAGS ":t:". The latter headline would have TITLE ":t:" and TAGS ":". The following toy can be used to test some cases. It is not complete, but contains the essential. #+BEGIN_SRC elisp (defun f (x) (let ((r (rx line-start (maximal-match (group (1+ "*")) (1+ (any " \t"))) (maximal-match (group (optional "TODO" (1+ (any " \t") (minimal-match (optional (group (1+ not-newline)) (1+ (any " \t" (maximal-match (group (optional (seq ":" (0+ (any "a-z") ":") (maximal-match (optional (1+ (any " \t" line-end))) (when (let (case-fold-search) (string-match r x)) (list :stars (match-string 1 x) :todo (match-string 2 x) :title (let ((title (match-string 3 x))) (if title title "")) :tags (match-string 4 x) (f "*** :t: : ") ;(:stars "***" :todo "" :title ":t:" :tags ":") (f "***:t: ") ;(:stars "***" :todo "" :title "":tags ":t:") #+END_SRC Best wishes Sebastian
Org-export question from a pandoc user
Hi everyone, given the recent developments regarding the citation syntax I'm currently looking at orgmode as a writing environment again. One thing I don't understand currently: Do you have to have you export configuration in your source file or is there a way to keep your writing clean from these formatting instructions? That stuff causes a lot of overhead, and I was really happy to learn about pandoc after using LaTeX for a long time. Just to clarify what I mean: With pandoc you can add formatting information to your document metadata, but you can also use makefiles or external files that contain your settings. So, in the end your documents will only contain the contents: #+begin_src markdown --- author: Denis title: My article date: whenever it is done --- # Introduction The article starts here #+end_src The nice thing about this approach is that you can define different settings for different output formats and reuse them as appropriate. How do you do that in orgmode? Is that possible? Denis
Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block
Hello, Juan Manuel Macías writes: > Subject: [PATCH] ox-latex.el: add LaTeX attributes to quote block Thank you. Some comments follow. > +(defcustom org-latex-default-quote-environment "quote" > + "Default environment used to `quote' environment." --> Default environment used for "quote" blocks. > + :group 'org-export-latex > + :version "24.4" > + :package-version '(Org . "8.0") You can remove the :version keyword. And :package-version is wrong. > + :type 'string) You also need to add :safe t > (defcustom org-latex-default-table-mode 'table >"Default mode for tables. > > @@ -2895,9 +2903,17 @@ channel." >"Transcode a QUOTE-BLOCK element from Org to LaTeX. > CONTENTS holds the contents of the block. INFO is a plist > holding contextual information." > + (let* ((env (org-export-read-attribute :attr_latex quote-block > :environment)) > + (opt (org-export-read-attribute :attr_latex quote-block :options)) > + (current-env (if env env org-latex-default-quote-environment)) > + (current-opt (if opt opt ""))) We don't use global variables directly as above, but use (plist-get info :latex-default-quote-environment) instead. This could be written as (let ((environment (or (org-export-read-attribute :attr_latex quote-block :environment) (plist-get info :latex-default-quote-environment))) (options (or (org-export-read-attribute :attr_latex quote-block :options) ""))) ...) Could you send an updated patch? Regards, -- Nicolas Goaziou
Re: BUG: eval macros not working anymore
Hello,
Michael Dauer writes:
> at least not compatible with before.
>
> Probably caused by commit 8abdbbee395f284f2262a89187d662eaf40080b1.
>
> originally correct macro ("macroA" . "(eval
> do-something-dynamically-at-macro-expansion)")
>
> How should this be achieved now? (functionp "any-string") is nil
I think you need to write
("macroA" . (lambda ( _) (do-something-dynamically-at-macro-expansion)))
Regards,
--
Nicolas Goaziou
Re: reevaluating org-x11idle-exists-p with new org-clock-x11idle-program-name
Tim Cross writes: > Julien Cubizolles writes: > >> I'm using a custom python program to display x11 idle time. I've set >> org-clock-x11idle-program-name accordingly but org-x11idle-exists-p is >> still nil. I'm guessing it's defvar'ed in org-clock.el before >> org-clock-x11idle-program-name is set. Evaluating the defvar of >> org-x11idle-exists-p afterwards indeed sets it to t. >> >> I could do (setq org-x11idle-exists-p t) but there must be a better way >> to handle the definition of a new org-clock-x11idle-program-name. > > How are you setting org-clock-x11idle-program-name? In your init file or > via custom? Setting it via custom works thanks. Somehow org was loaded by some dependency before I explicitly used (require 'org). I guess I could also use some use-package configuration. -- Julien Cubizolles
Re: there are always ways to go - Re: Sad tweet
* Ypo [2021-05-25 06:09]: > I think he is the creator of the magit package. OK, it's not Org related and is not a direct post... It is just an attention seeking... Tweet. I am following emacs-devel mailing list, who wish to contribute package to Emacs is very welcome to do so, and it is very straightforward. Best way to start improvement is in my opinion with the package creation. Those who wish to make changes in the core have to discuss it with Emacs core developers, that is how it is, as newly introduced ideas are not necessarily thought well for millions of users. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/
