Re: Bug: Priority Of A Task In Emacs 27.2 Cannot Be Removed With Space Key ("SPC to remove")

[Tim Cross]

Not sure how easy it would be to restore the previous behaviour. I guess
if you restricted numerical priorities to 0 .. 9 it would be reasonably
easy as you only need to check for a single key press. However, once you
go above 9 and have the situation where the value could be more than a
single key press, you have no way to know when input is finished.

It should be noted that the old behaviour using letters for priorities
still works (as does clearing wiht a space). Personally, I've always
been happy with just letters and 3 priorities. I find once you go past
about 3 or 4, priorities don't have a lot of value. YMMV of course.

"Samuel Banya"  writes:

> Thanks for confirming this as I didn't know if it was my config or something.
>
> I'd like to add if possible, if there would the ability to restore the 
> previously functionality of being able to just hit a number from 1 to 9 to 
> set the priority
> of a task as well.
>
> Didn't want to conflate things too much, but it would be great if there was a 
> config option around this before I would have to make a workaround in Elisp
> instead.
>
> On Thu, May 27, 2021, at 4:05 AM, Tim Cross wrote:
>
>  Confirmed
>
>  I can reproduce this in org 9.4.6, Emacs 27.2. Bug confirmed.
>
>  "Samuel Banya"  writes:
>
>  > Hello there,
>  >
>  > I noticed a weird bug within Emacs Org Mode as I use it often for my TODO 
> lists for both personal use and for work.
>  >
>  > I noticed that if you hit "C-c ," you are prompted nowadays to enter a 
> number from like 1 to whatever your highest priority was set to, and that
>  you have
>  > to enter in the number and THEN press enter.
>  >
>  > This behavior on a side note is a little annoying since I usually only use 
> priorities 1 through 5, and don't want to have to hit enter each time. I kind
>  of wish
>  > I could just go back to just hitting '1' or '5' and moving on. But, I 
> understand this was to make the ceiling of the highest priority be like 65 or
>  something
>  > like that, so I understand why this was included.
>  >
>  > My main point is that the "SPC to remove" option doesn't actually work.
>  >
>  > If you try doing "C-c ," then hit Space, and then press Enter, the 
> priority of the task still remains the same.
>  >
>  > Workaround:
>  > I've had to manually delete the priority number as a workaround which is a 
> bit annoying.
>  > I've used F3 as a on-the-fly macro to quickly do this across multiple todo 
> list items as well.
>  > However, it does feel a little awkward having to do this, so I'm wondering 
> if anyone has encountered this as well.
>  >
>  > Thanks,
>  >
>  > Sam
>
>  -- 
>  Tim Cross


-- 
Tim Cross

Re: Bug: Priority Of A Task In Emacs 27.2 Cannot Be Removed With Space Key ("SPC to remove")

[Samuel Banya]

Thanks for confirming this as I didn't know if it was my config or something.

I'd like to add if possible, if there would the ability to restore the 
previously functionality of being able to just hit a number from 1 to 9 to set 
the priority of a task as well.

Didn't want to conflate things too much, but it would be great if there was a 
config option around this before I would have to make a workaround in Elisp 
instead.

On Thu, May 27, 2021, at 4:05 AM, Tim Cross wrote:
> 
> Confirmed
> 
> I can reproduce this in org 9.4.6, Emacs 27.2. Bug confirmed.
> 
> "Samuel Banya" mailto:sbanya%40fastmail.com>> writes:
> 
> > Hello there,
> >
> > I noticed a weird bug within Emacs Org Mode as I use it often for my TODO 
> > lists for both personal use and for work.
> >
> > I noticed that if you hit "C-c ," you are prompted nowadays to enter a 
> > number from like 1 to whatever your highest priority was set to, and that 
> > you have
> > to enter in the number and THEN press enter.
> >
> > This behavior on a side note is a little annoying since I usually only use 
> > priorities 1 through 5, and don't want to have to hit enter each time. I 
> > kind of wish
> > I could just go back to just hitting '1' or '5' and moving on. But, I 
> > understand this was to make the ceiling of the highest priority be like 65 
> > or something
> > like that, so I understand why this was included.
> >
> > My main point is that the "SPC to remove" option doesn't actually work.
> >
> > If you try doing "C-c ," then hit Space, and then press Enter, the priority 
> > of the task still remains the same.
> >
> > Workaround:
> > I've had to manually delete the priority number as a workaround which is a 
> > bit annoying.
> > I've used F3 as a on-the-fly macro to quickly do this across multiple todo 
> > list items as well.
> > However, it does feel a little awkward having to do this, so I'm wondering 
> > if anyone has encountered this as well.
> >
> > Thanks,
> >
> > Sam
> 
> -- 
> Tim Cross
> 
> 

Re: Bug: Priority Of A Task In Emacs 27.2 Cannot Be Removed With Space Key ("SPC to remove")

[Tim Cross]

Confirmed

I can reproduce this in org 9.4.6, Emacs 27.2. Bug confirmed.

"Samuel Banya"  writes:

> Hello there,
>
> I noticed a weird bug within Emacs Org Mode as I use it often for my TODO 
> lists for both personal use and for work.
>
> I noticed that if you hit "C-c ," you are prompted nowadays to enter a number 
> from like 1 to whatever your highest priority was set to, and that you have
> to enter in the number and THEN press enter.
>
> This behavior on a side note is a little annoying since I usually only use 
> priorities 1 through 5, and don't want to have to hit enter each time. I kind 
> of wish
> I could just go back to just hitting '1' or '5' and moving on. But, I 
> understand this was to make the ceiling of the highest priority be like 65 or 
> something
> like that, so I understand why this was included.
>
> My main point is that the "SPC to remove" option doesn't actually work.
>
> If you try doing "C-c ," then hit Space, and then press Enter, the priority 
> of the task still remains the same.
>
> Workaround:
> I've had to manually delete the priority number as a workaround which is a 
> bit annoying.
> I've used F3 as a on-the-fly macro to quickly do this across multiple todo 
> list items as well.
> However, it does feel a little awkward having to do this, so I'm wondering if 
> anyone has encountered this as well.
>
> Thanks,
>
> Sam

-- 
Tim Cross

Re: Empty headline titles unsupported: Bug?

[Ihor Radchenko]

David Masterson  writes:

> Could an extensible pre-hook that runs a list of functions take care of
> the inconsistencies where each function recognizes one change to the
> standard grammar and adjusts the input accordingly?

Could you elaborate? For now, this sounds like unnecessary
over-complication. Why would we need to introduce deviations from
grammar in different functions?

Best,
Ihor

Re: [BUG] org-compile-prefix-format regexp change breaks eval forms [9.4.6 (9.4.6-gf72a65)]

[Ihor Radchenko]

Radon Rosborough  writes:

> Hello,
>
> In commit 0260d2fcf603f30210e2b95d37727edd832c12e9 of 2021-04-26, the
> regexp used in `org-agenda-prefix-format' was updated to use a
> non-greedy regexp, in order to allow multiple %(expression) instances
> in `org-agenda-prefix-format'. Unfortunately, this change breaks the
> ability to use nested forms in %(expression) instances. For example, I
> use the following setting for `org-agenda-prefix-format':

Confirmed.

Sorry, I noticed this problem after sending the patch, but I do not know
an easy way to solve it. To handle sexps properly, we need to do
something more complex than just a simple regexp. Probably, using
org-element--parse-paired-brackets or similar code.

Fixing this is (down) in my todo-list, but patches are welcome.

Best,
Ihor

bug#48676: Arbitrary code execution in Org export macros

[Greg Minshall]

Glenn,

thanks for the report.

i guess my take is that macro-evaluation, and that of other forms,
should be subject to the same restrictions as that of source block
evaluation.  i.e., prompting for permission to execute, subject to
=org-confirm-babel-evaluate= (or, more specific variables).

cheers, Greg

> Package: emacs,org-mode
> Version: 28.0.50
> Severity: important
> Tags: security
> 
> emacs -Q hello.org, where hello.org contains:
> 
> #+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
> Hello. {{{hello}}}
> 
> Then:
> M-x org-export-dispatch
> t A
> 
> -> now /tmp/HELLO exist, with no prompting.
> 
> This seems contrary to normal Emacs practice for risky local variables,
> and to the section "Code Evaluation and Security Issues" in the Org manual
> (which does not mention macros).

Bug: Priority Of A Task In Emacs 27.2 Cannot Be Removed With Space Key ("SPC to remove")

[Samuel Banya]

Hello there,

I noticed a weird bug within Emacs Org Mode as I use it often for my TODO lists 
for both personal use and for work.

I noticed that if you hit "C-c ," you are prompted nowadays to enter a number 
from like 1 to whatever your highest priority was set to, and that you have to 
enter in the number and THEN press enter.

This behavior on a side note is a little annoying since I usually only use 
priorities 1 through 5, and don't want to have to hit enter each time. I kind 
of wish I could just go back to just hitting '1' or '5' and moving on. But, I 
understand this was to make the ceiling of the highest priority be like 65 or 
something like that, so I understand why this was included.

My main point is that the "SPC to remove" option doesn't actually work.

If you try doing "C-c ," then hit Space, and then press Enter, the priority of 
the task still remains the same.

*Workaround:*
I've had to manually delete the priority number as a workaround which is a bit 
annoying.
I've used F3 as a on-the-fly macro to quickly do this across multiple todo list 
items as well.
However, it does feel a little awkward having to do this, so I'm wondering if 
anyone has encountered this as well.

Thanks,

Sam

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Wed, May 26, 2021 at 8:47 PM Bruce D'Arcus  wrote:

> BTW, I did get it all setup, and do seem to have run into a bug.
>
> Input:
>
> [cite/noauthor:@latexcompanion p23]
>
> Output (not position of the locator label):
>
> (p 1993, 23)

Hmm ... experimenting some more, these work correctly.

[cite/noauthor:@latexcompanion page 23]
[cite/noauthor:@latexcompanion p. 23]
[cite/noauthor:@latexcompanion p.23]

Still not sure why the above with the p at the front though.

Bruce

[PATCH] ox-latex.el/org-latex--make-option-string: Surround option string with braces if it includes brackets

[Markus Huber]

lisp/ox-latex.el (`org-latex--make-option-string'): If `value' of a `pair' from 
`options' contains a bracket
the whole `value' is surrounded by braces.

In case of LaTeX export using listings the dialect of a language (e.g. 
[LaTeX]TeX) is surrounded by brackets. For inline
source blocks all options end as optional argument to \lstinline between 
brackets which breaks the LaTeX parser.
TINYCHANGE
---
 lisp/ox-latex.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index b9ecf070a..2f7bbdf15 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1486,7 +1486,7 @@ nil."
   (pcase-let ((`(,keyword ,value) pair))
 (concat keyword
 (and (> (length value) 0)
- (concat "=" value)
+ (concat "=" (if (string-match-p "\\[\\|\\]" 
value) (format "{%s}" value) value))
 options
 ","))
 
-- 
2.31.1

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

On Wed, May 26, 2021 at 6:07 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> "Bruce D'Arcus"  writes:
>
> > What if a developer has the idea to hook up one of the new, very fast,
> > csl libraries: either the haskell version associated with pandoc, or
> > the rust-based version associated with Zotero?
> >
> > Possible reasons they might want to do that: performance and/or
> > compliance/features.
> >
> > Could you make sure this module is coded in such a way that it should
> > be relatively straightforward to do that?
>
> The citation processor is pretty much centered around the API provided
> by the Emacs Citeproc library. I don't know what interface the other
> libraries you mention do provide, but if they are not close to each
> other, some work will be required.

They are close, but 

> Fortunately, barring constants and defcustoms, that's roughly 300 locs.
> At this size, doing anything is (or should be) "relatively
> straightforward" in Elisp.

... 300 LOC is indeed pretty compact.

BTW, I did get it all setup, and do seem to have run into a bug.

Input:

[cite/noauthor:@latexcompanion p23]

Output (not position of the locator label):

(p 1993, 23)

BTW, I mentioned on the citeproc-el issue tracker that it should be
pretty straightforward to add support for both the "author" and "text"
styles there, and then in turn here:

https://github.com/andras-simonyi/citeproc-el/issues/15

This is because "text" is basically just "author/bare" + "noauthor".

Bruce

Re: Empty headline titles unsupported: Bug?

[David Masterson]

Tim Cross  writes:

> David Masterson  writes:

>> 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.

Could it be done via a secondary parser?  That is, define a base level
language for Org that fits into a BNF (or..?) grammar and then a package
that could be a pre-hook to the parser that rewrites improper tidbits
into a grammatically correct form?  I'm thinking, if the grammar is well
defined, the secondary parser won't be that complex.

-- 
David Masterson

[BUG] org-compile-prefix-format regexp change breaks eval forms [9.4.6 (9.4.6-gf72a65)]

[Radon Rosborough]

Hello,

In commit 0260d2fcf603f30210e2b95d37727edd832c12e9 of 2021-04-26, the
regexp used in `org-agenda-prefix-format' was updated to use a
non-greedy regexp, in order to allow multiple %(expression) instances
in `org-agenda-prefix-format'. Unfortunately, this change breaks the
ability to use nested forms in %(expression) instances. For example, I
use the following setting for `org-agenda-prefix-format':

(setf (alist-get 'agenda org-agenda-prefix-format)
  "  %(format-time-string \"%a\" (org-get-deadline-time (point)))  ")

When running `org-agenda', I now receive the error
`org-compile-prefix-format: End of file during parsing'. This is
because of the updated regexp match, which stops at the first closing
parenthesis:

ELISP> myfmt
"  %(format-time-string \"%a\" (org-get-deadline-time (point)))  "
ELISP> (and (string-match "%\\(\\?\\)?\\([-+]?[0-9.]*\\)\\([
.;,:!?=|/<>]?\\)\\([cltseib]\\|(.+?)\\)" myfmt) (match-string 4
myfmt))
"(format-time-string \"%a\" (org-get-deadline-time (point)"

With the previous regexp, it works fine:

ELISP> (and (string-match "%\\(\\?\\)?\\([-+]?[0-9.]*\\)\\([
.;,:!?=|/<>]?\\)\\([cltseib]\\|(.+)\\)" myfmt) (match-string 4 myfmt))
"(format-time-string \"%a\" (org-get-deadline-time (point)))"

Thanks,
Radon Rosborough

Re: Empty headline titles unsupported: Bug?

[David Masterson]

Ihor Radchenko  writes:

> Nicolas Goaziou  writes:
>
>> 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.
>
> I agree that currently there is no urgent need to decide on this, but
> there (hopefully) will be in the future.
>
> I am trying to implement storage of heading elements in
> org-element-cache and reusing them later in org.el functions when
> getting tags, properties, schedules, etc. This, among other things,
> requires consistency between org.el and org-element.el when parsing
> headlines.

Could an extensible pre-hook that runs a list of functions take care of
the inconsistencies where each function recognizes one change to the
standard grammar and adjusts the input accordingly?

-- 
David Masterson

Re: bug#48676: Arbitrary code execution in Org export macros

[Tim Cross]

Glenn Morris  writes:

> Package: emacs,org-mode
> Version: 28.0.50
> Severity: important
> Tags: security
>
> emacs -Q hello.org, where hello.org contains:
>
> #+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
> Hello. {{{hello}}}
>
> Then:
> M-x org-export-dispatch
> t A
>
> -> now /tmp/HELLO exist, with no prompting.
>
> This seems contrary to normal Emacs practice for risky local variables,
> and to the section "Code Evaluation and Security Issues" in the Org manual
> (which does not mention macros).

I'm not quite sure if this is the same as the concern with risky local
file variables. The big difference is that with the local file
variables, without the default behaviour of asking for permission to
evaluate, the code would be evaluated simply by loading the file. With
the org file, nothing is evaluated when you load the file. The user has
to actively request for evaluation (via export or tangling).

I would agree the org manual should make it very clear that exporting
and tangling can result in macro evaluation, which could involve
evaluation of arbitrary code and the risks that can introduce. 

-- 
Tim Cross

Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block

[Juan Manuel Macías]

Nicolas Goaziou writes:

> I cannot apply it on top of master however. On what commit did you base
> it?

I'm sorry, it's my fault. It's already fixed. I think the patch attached
here should apply well...

> [...]
> I don't know if this example is a good illustration because you can
> currently achieve the same with:
>
>   #+attr_latex: :options {german}
>
>   #+begin_foreigndisplayquote
>   some text in German...
>   #+end_foreigndisplayquote
>
> Are there use cases that would be better than using special blocks as in
> the example above?

I think I have not explained well about the rationale for this patch,
sorry. The advantage (IMHO) of being able to choose between several
LaTeX environments to the export of the quote blocks has more to do with
the consistency between various output formats (and a single origin). Of
course, quotation, quoting, foreigndisplayquote and a few more can be
obtained using special blocks. But for LaTeX they are just different
styles and ways to create a quote environment. At the end of the day
they are all 'quote'. It's ok that Org has only one single quote block
that is exported indistinctly to LaTeX, html, odt, etc. (Org tends to be
format agnostic and focuses more on the logical structure of the text).
But in the case of LaTeX it would be nice if the user could choose
between several ways or formats to do quotes (in LaTeX), without
resorting to special blocks. On the other hand, the standard LaTeX
`quote' environment is already far exceeded by other more powerful
options, like the csquotes package.

Best regards,

Juan Manuel 

>From c2e39f5f3046d7a8e90878351b35c89656dacdfc Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Wed, 26 May 2021 23:58:05 +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

[BUG] New error: (void-function org-url-p) when exporting to LaTeX [9.4.6 (9.4.6-gc5573b @ /Users/stanton/.emacs.d/straight/build/org/)]

[Richard Stanton]

Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.


Everything worked fine until yesterday, but today when I try to export an org 
file that contains the line

#+SETUPFILE: 
https://fniessen.github.io/org-html-themes/org/theme-readtheorg.setup 


I get the following error:

Debugger entered--Lisp error: (void-function org-url-p)
  org-url-p("https://fniessen.github.io/org-html-themes/org/the...";)
  org--collect-keywords-1(("SETUPFILE" "FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" 
"COLUMNS" "CONSTANTS" "LINK" "OPTIONS" "PRIORITIES" "PROPERTY" "SEQ_TODO" 
"STARTUP" "TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" "COLUMNS" "PRIORITIES") nil 
nil nil)
  org-collect-keywords(("FILETAGS" "TAGS" "ARCHIVE" "CATEGORY" "COLUMNS" 
"CONSTANTS" "LINK" "OPTIONS" "PRIORITIES" "PROPERTY" "SEQ_TODO" "STARTUP" 
"TODO" "TYP_TODO") ("ARCHIVE" "CATEGORY" "COLUMNS" "PRIORITIES"))
  org-set-regexps-and-options()
  org-mode()
  org-export--prepare-file-contents("/Users/stanton/.org/setup" nil 0 1 1 
# 
"/Users/stanton/teaching/MFE230I/mfe230i.org")
  org-export-expand-include-keyword()
  org-export-as(latex nil nil nil (:output-file "mfe230i.tex"))
  org-export-to-file(latex "mfe230i.tex" nil nil nil nil nil 
#f(compiled-function (file) #))
  org-latex-export-to-pdf(nil nil nil nil)
  org-export-dispatch(nil)
  funcall-interactively(org-export-dispatch nil)
  call-interactively(org-export-dispatch nil nil)
  command-execute(org-export-dispatch)

Thanks for any suggestions.


Emacs  : GNU Emacs 27.2 (build 1, x86_64-apple-darwin20.3.0, Carbon Version 164 
AppKit 2022.3)
 of 2021-04-06
Package: Org mode version 9.4.6 (9.4.6-gc5573b @ 
/Users/stanton/.emacs.d/straight/build/org/)

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> What if a developer has the idea to hook up one of the new, very fast,
> csl libraries: either the haskell version associated with pandoc, or
> the rust-based version associated with Zotero?
>
> Possible reasons they might want to do that: performance and/or
> compliance/features.
>
> Could you make sure this module is coded in such a way that it should
> be relatively straightforward to do that?

The citation processor is pretty much centered around the API provided
by the Emacs Citeproc library. I don't know what interface the other
libraries you mention do provide, but if they are not close to each
other, some work will be required.

Fortunately, barring constants and defcustoms, that's roughly 300 locs.
At this size, doing anything is (or should be) "relatively
straightforward" in Elisp.

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `csl' citation processor

[Bruce D'Arcus]

Hi Nicolas,

I'll take a close look at this and test it over the coming days, but
in the meantime, on two more general points:

On Wed, May 26, 2021 at 4:39 PM Nicolas Goaziou  wrote:

First, names:

> I called it `csl' instead of `citeproc'. It is a bit ambiguous, but it
> is shorter, and "org-cite-csl" prefix sounds less redudant than
> "org-cite-citeproc...".  But I know this is a weak argument, so if you think 
> "citeproc"
> is still more appropriate, I can revisit this.

>From my perspective, that's totally fine, and arguably better: csl
export processor for citeproc library.

The citeproc name is just a convention for the processors that's
developed over time I think mostly because people couldn't be bothered
to come up with better names. I actually wrote the very first one, in
XSLT, called citeproc-xsl.

I think CSL would be more widely known among users though.

And this processor doesn't actually do the formatting, so it makes sense.

Second, this:

> Also, I don't expect a different CSL-based citation processor any time soon, 
> so it should be fine.

Well, I'll ask you the same question I asked Andras recently:

What if a developer has the idea to hook up one of the new, very fast,
csl libraries: either the haskell version associated with pandoc, or
the rust-based version associated with Zotero?

Possible reasons they might want to do that: performance and/or
compliance/features.

Could you make sure this module is coded in such a way that it should
be relatively straightforward to do that?

Bruce

Re: [PATCH] ox-latex.el: add LaTeX attributes to quote block

[Nicolas Goaziou]

Hello,

Juan Manuel Macías  writes:

> Here is the updated patch, with the corresponding additions in the
> manual and ORG-NEWS.

Thanks.

I cannot apply it on top of master however. On what commit did you base
it?

There are also some nits, but I can fix them when applying your patch.
> +#+cindex: quote blocks, in @LaTeX{} export
> +#+cindex: @samp{ATTR_LATEX}, keyword

This is not related to your patch (it can be encountered elsewhere), but
the index entry above is too generic to be useful. Maybe 

  #+cindex: @samp{ATTR_LATEX}, in quote blocks

would be better.

> +#+cindex: org-latex-default-quote-environment

This should be #+vindex: ...

> +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

~org-latex-default-quote-environment~ and ~"quote"~ since they both
refer to Lisp code, not Org syntax.

> +=: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

Note that you can currently write, perhaps more elegantly,

  #+begin_quotation
  some text...
  #+end_quotation

> +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

I don't know if this example is a good illustration because you can
currently achieve the same with:

  #+attr_latex: :options {german}
  #+begin_foreigndisplayquote
  some text in German...
  #+end_foreigndisplayquote

Are there use cases that would be better than using special blocks as in
the example above?

Regards,
-- 
Nicolas Goaziou

[wip-cite-new] Initial implementation of `csl' citation processor

[Nicolas Goaziou]

Hello,

I just pushed a Citeproc-based citation processor. As such, Citeproc
library must be available in the load path. For a better experience,
your also need to download styles, and possibly locales definitions, as
pointed in the commentary section pasted below.

I called it `csl' instead of `citeproc'. It is a bit ambiguous, but it
is shorter, and "org-cite-csl" prefix sounds less redudant than
"org-cite-citeproc...". Also, I don't expect a different CSL-based
citation processor any time soon, so it should be fine. But I know this
is a weak argument, so if you think "citeproc" is still more
appropriate, I can revisit this.

As pointed out in the commentary section, this is, for a large part,
a port of András Simonyi's Citeproc Org library. Thanks!

There are some differences between the two libraries, however. For
example, Org Cite CSL does not support Org Ref links. It also provides
less customization options. OTOH, it supports ".bib", ".bibtex" and
".json" bibliography files. It also handles author suppression and
global affixes in citations.

This patch adds two files in a new "etc/csl/" directory. They are both
licensed under CC BY-SA 3.0 terms. So I assume this is fine to
distribute them with Org.

Here is the full commentary. Feedback welcome!

--8<---cut here---start->8---
This library registers the `csl' citation processor, which provides
the "export" capability for citations.  You may activate it globally with

   (setq org-cite-export-processor '(csl))

or at the document level, with

   #+cite_export: csl

The processor relies on the external Citeproc Emacs library, which must be
available prior to loading this library.

By default, citations are rendered in Chicago author-date CSL style.  You can
use another style file by specifying it in `org-cite-export-processor'

   (setq org-cite-export-processor '(csl "/path/to/style-file.csl")

or from within the document by adding the file name to "cite_export" keyword

   #+cite_export: csl /path/to/style-file.csl
   #+cite_export: csl "/path/to/style-file.csl"

Styles can be downloaded, for instance, from the Zotero Style Repository
().  Dependent styles (which are not "unique"
in the Zotero Style Repository terminology) are not supported.

The processor uses the "en-US" CSL locale file shipped with Org for rendering
localized dates and terms in the references, independently of the language
settings of the Org document.  Additional CSL locales can be made available
by setting `org-cite-csl-locales-dir' to a directory containing the locale
files in question (see 
for such files).  The directory must contain at least the "en-US" CSL locale.

Bibliography is defined with the "bibliography" keyword.  It supports files
with ".bib", ".bibtex", and ".json" extensions.  References are exported using
the "print_bibliography" keyword.

The library supports the following citation styles:

- noauthor (na), including bare (b) variant,
- default style, including bare (b) variant.

CSL styles recognize "locator" in citation references' suffix.  For example,
in the citation

[cite:see @Tarski-1965 chapter 1, for an example]

"chapter 1" is the locator.  The whole citation is rendered as

(see Tarski 1965, chap. 1 for an example)

in the default CSL style.

The locator starts with a locator term, among "bk.", "bks.", "book", "chap.",
"chaps.", "chapter", "col.", "cols.", "column", "figure", "fig.", "figs.",
"folio", "fol.", "fols.", "number", "no.", "nos.", "line", "l.", "ll.",
"note", "n.", "nn.", "opus", "op.", "opp.", "page", "p.", "pp.", "paragraph",
"para.", "paras.", "¶", "¶¶", "§", "§§", "part", "pt.", "pts.", "section",
"sec.", "secs.", "sub verbo", "s.v.", "s.vv.", "verse", "v.", "vv.",
"volume", "vol.", and "vols.".  It ends with the last comma or digit in the
suffix, whichever comes last, or runs till the end of the suffix.

The part of the suffix before the locator is appended to reference's prefix.
If no locator term is used, but a number is present, then "page" is assumed.

This library was heavily inspired by and borrows from András Simonyi's
Citeproc Org () library.
Many thanks to him!
--8<---cut here---end--->8---

Regards,
-- 
Nicolas Goaziou

Re: [wip-cite-new] Initial implementation of `biblatex' citation processor

[Nicolas Goaziou]

Hello,

"Bruce D'Arcus"  writes:

> Denis Maier and I worked on this off-list.

Thank you for this work!

> 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,

I implemented "core" table in "oc-natbib.el" and "oc-biblatex.el".

Regards,
-- 
Nicolas Goaziou

Re: BUG: eval macros not working anymore

[Michael Dauer]

Hi,

I can confirm that macros work a little bit differently (incompatible with
some custom code) in 9.4.6 than 9.4.5, but still fine and better.

The #+marco keyword behaviour seems unchanged. For programmatically added
macros the proposed lambda form works fine.

Please excuse my false report.

Thanks,
Michael

Am Di., 25. Mai 2021 um 20:32 Uhr schrieb Michael Dauer <
mick.da...@gmail.com>:

> 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,
>>
>

bug#48676: Arbitrary code execution in Org export macros

[Tom Gillespie]

Hi Glenn,
 The definition for local variables doesn't cover things like org
macros, though the spirit of the policy is something worth keeping in
mind. Running M-x org-export-dispatch and hitting two keys means that
the user has to do something to trigger code execution, much like they
would have to intentionally accept certain risky local variables.

That said, the fact that many org operations can run arbitrary code is
definitely something that needs clearer documentation. It might make
sense to add a setting to detect closures that appear in org files to
ask for permission before running, but it likely should not be on by
default.

For a fairly extensive discussion of code execution in org see this
thread from Nov 2020.
https://orgmode.org/list/robi94$ma$1...@ciao.gmane.io/#t
Best,
Tom

Re: bug#48676: Arbitrary code execution in Org export macros

[Timothy]

Thanks for reporting this.

Glenn Morris  writes:

> This seems contrary to normal Emacs practice for risky local variables,

Hmm, correct me if I'm wrong but the issue with risky local variables is
that they affect Emacs before the user sees them in the file? If this is
an important distinction, it means this particular type of concern does
not apply to Org #+macro statements, as they are not executed when the
user opens the file.

That said, if one were making say an automated Org file exporter or
something, I could see this being problematic. Perhaps a var set to
allow macros by default could be a good idea.

> and to the section "Code Evaluation and Security Issues" in the Org manual
> (which does not mention macros).

Looks like this should be updated regardless of the above.

--
Timothy

bug#48676: Arbitrary code execution in Org export macros

[Glenn Morris]

Package: emacs,org-mode
Version: 28.0.50
Severity: important
Tags: security

emacs -Q hello.org, where hello.org contains:

#+macro: hello (eval (shell-command-to-string "touch /tmp/HELLO"))
Hello. {{{hello}}}

Then:
M-x org-export-dispatch
t A

-> now /tmp/HELLO exist, with no prompting.

This seems contrary to normal Emacs practice for risky local variables,
and to the section "Code Evaluation and Security Issues" in the Org manual
(which does not mention macros).

Re: there are always ways to go - Re: Sad tweet

[Matt Price]

I am not an emacs contributor, but I think Jonas is saying, "I love emacs
and I am the primary author of one of the two most important emacs
packages. If contributing to emacs is frustrating even for me, think how
many people will give up. We need to change our culture." I would be very
careful about describing him as "attention-seeking." He is a very diligent
and responsive package maintainer who works *constantly* to improve an
important piece of emacs infrastructure.

On Tue., May 25, 2021, 2:53 a.m. Jean Louis,  wrote:

> * 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/
>
>

Re: Empty headline titles unsupported: Bug?

[Ihor Radchenko]

Nicolas Goaziou  writes:

> 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.

I agree that currently there is no urgent need to decide on this, but
there (hopefully) will be in the future.

I am trying to implement storage of heading elements in
org-element-cache and reusing them later in org.el functions when
getting tags, properties, schedules, etc. This, among other things,
requires consistency between org.el and org-element.el when parsing
headlines.

Best,
Ihor

Re: reevaluating org-x11idle-exists-p with new org-clock-x11idle-program-name

[Julien Cubizolles]

Julien Cubizolles  writes:

> 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.

Actually it doesn't… Even with org-clock-x11idle-program-name set via
custom, org-x11idle-exists-p is still nil at startup. And
custom-set-variables is set at the very beginning of my init file. I'll
file an issue.


-- 
Julien Cubizolles

Re: What's up with ob-template.el? It seems heavily outdated

[dalanicolai]

Because of the image in that repo the link does not jump exactly to the
right location... anyway the tips are just below that image/animation.
Also, for some reason the link to my repo failed... so here
 it is again (well it just
links to the same page as the tips link)

On Wed, 26 May 2021 at 14:07, dalanicolai  wrote:

> Ha! Well not too much response here...
>
> Anyway @Pedro:
> So I do not have too much time to work on an updated template. But I have
> added a somewhat updated template file to my emacs-lisp repo here along
> with some handy tips
> .
> Then of course you can further just check out examples of other ob-el
> files. Hope this is useful.
>
>

Re: What's up with ob-template.el? It seems heavily outdated

[dalanicolai]

Ha! Well not too much response here...

Anyway @Pedro:
So I do not have too much time to work on an updated template. But I have
added a somewhat updated template file to my emacs-lisp repo here
 along with some handy tips
.
Then of course you can further just check out examples of other ob-el
files. Hope this is useful.