Re: 9.5: coping with loss of ditaa.jar

[Eric S Fraga]

On Sunday,  3 Oct 2021 at 07:25, Jarmo Hurri wrote:
> 1. I am running Fedora 34, where ditaa is available as a
>package. However, just pointing org-ditaa-jar-path to the correct
>location /usr/share/java/ditaa.jar is not sufficient, because doing
>so leads to errors when trying to execute a ditaa babel block:

On Debian 11 (bullseye, most recent stable version), this works just
fine for me.  I didn't need to feed any parameters, as you have
suggested being necessary.  I don't know why, mind you.  It could be a
different version of ditaa.jar?  On Debian 11, the version installed is
0.10+ds1-1.2.

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df
: Latest paper written in org: https://arxiv.org/abs/2106.05096

[SOLVED] (was: how to pull from the git org repo)

[Uwe Brauer]

> On Mon, Oct 04, 2021 at 12:47:58PM +0200, Uwe Brauer wrote:

> It seems that some letsencrypt root certificate has
> changed from under the Intratubes. Perhaps updating
> your OS will fix that (if it's Debian, updating the
> ca-cacert might do the trick).
I tried that

> The error message suggests otherwise. Can you access
> that URL from your browser?

I found out that using 

git://git.sv.gnu.org/emacs/org-mode.git

Worked, problem solved for me

thanks


smime.p7s
Description: S/MIME cryptographic signature

Re: 9.5: coping with loss of ditaa.jar

[Eric S Fraga]

I should have added, to my previous response, that, at least on my
system, the jar file is installed in /usr/share/ditaa/ditaa.jar, not
/usr/share/java/ditaa.jar.  I don't know if this is relevant at all.

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df
: Latest paper written in org: https://arxiv.org/abs/2106.05096

master-->main?

[Uwe Brauer]

Hi

I did a git pull and obtained 

from git://git.sv.gnu.org/emacs/org-mode
 * [new branch]  bugfix -> origin/bugfix
   dd9105d..fedcb49  emacs-sync -> origin/emacs-sync
 * [new branch]  main   -> origin/main
 * [new tag] release_9.5 -> release_9.5
Your configuration specifies to merge with the ref 'refs/heads/master'
from the remote, but no such ref was fetched.


So I set in my config 

merge = refs/heads/master

To 

merge = refs/heads/main

Was master «renamed» main, I mean is the default branch now main instead of 
master?

Regards

Uwe Brauer 

Some broken links in pages under https://orgmode.org/worg/org-contrib/babel

[Mandar Mitra]

Not sure if this is the right place to report this, but I was trying to learn 
about Org-Babel, and encountered some broken links. Below are a few (not a 
comprehensive list, of course, just some that I happened to encounter).


* https://orgmode.org/worg/org-contrib/babel/intro.html
*** ... relevant section in the 
[[https://orgmode.org/manual/Literal-examples.html][Org manual]] ...
*** please have a look at the 
[[https://orgmode.org/manual/Literal-examples.html][Org-mode manual]] before 
proceeding
*** blocks located in the 
[[https://orgmode.org/worg/org-contrib/babel/library-of-babel.html][Library of 
Babel]] file – raw file at

* https://orgmode.org/worg/org-contrib/babel/uses.html
*** 
[[https://orgmode.org/worg/org-contrib/babel/examples/org-check.html][Checking 
Your Org Mode Configuration]]
*** 
[[https://orgmode.org/worg/org-contrib/babel/examples/data-collection-analysis.html][Data
 Collection and Analysis]]

Re: Citation in footnote not expanded/exported to LaTeX (using Org-ref-cite)

[Bruce D'Arcus]

On Mon, Oct 4, 2021 at 10:11 AM Bruce D'Arcus  wrote:
>
> On Sun, Oct 3, 2021 at 6:23 PM Nicolas Goaziou  wrote:
> >
> > Hello,
> >
> > Elias Bounatirou  writes:
> >
> > > Just to clarify the BUG:
> > > Citations in a footnote in the following environment are not exported to
> > > LaTeX: when the footnote follows two or more citations, of which one has a
> > > suffix, i.e. for instance in
> > >
> > > Body text with a citation: [cite:@low2001; @mcneill2011 with a
> > > suffix][fn:3].
> >
> > I cannot reproduce the problem. With the following document:
> >
> > --8<---cut here---start->8---
> > #+bibliography: foo.bibtex
> > #+cite_export: biblatex authoryear
>
> Can you try with a note-based style like verbose?

Now I'm not sure.

Input:


#+language: en
#+bibliography: test.bib
#+cite_export: biblatex verbose

Body text with a citation: [cite:@low2001; @mcneill2011; with a suffix][fn:1].

#+print_bibliography:

* Footnotes

[fn:1] Third commentary, and then a citation: [cite:@low2001].
---

LaTeX output:

---
Body text with a citation: \autocites(with a
suffix){low2001}[][]{mcneill2011}\relax[1].

\printbibliography



Footnotes
─

[1] Third commentary, and then a citation: \autocite{low2001}.
---

But the PDF leaves off the last citation, in the footnote.

Bruce

[patch] ox-html.el: add html attribute (verse numbers) to verse blocks

[Juan Manuel Macías]

Hi all,

I believe that an html attribute to display marginal verse numbers in
sequence could be useful for certain content, as philological texts
(like here:
https://en.wikisource.org/wiki/The_Iliad_and_Odyssey_of_Homer_(Cowper)/Volume_2/The_Odyssey/Book_I)

The `lines' property must be a digit that is equivalent to the verse
numbers sequence:

#+ATTR_HTML: :lines 5
#+begin_verse
some verses...
#+end_verse

Best regards,

Juan Manuel 

>From 9f1bbef52989532e16873a1f75331af0c7b0401f Mon Sep 17 00:00:00 2001
From: Juan Manuel Macias 
Date: Sun, 3 Oct 2021 22:12:44 +0200
Subject: [PATCH] ox-html.el: add verse numbers html attribute to verse blocks

* lisp/ox-html.el (org-html-verse-block): add `lines' html attribute
---
 lisp/ox-html.el | 45 +++--
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index a150b1fdb..4889bbe45 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -281,6 +281,7 @@ property on the headline itself.")
   .underline { text-decoration: underline; }
   #postamble p, #preamble p { font-size: 90%; margin: .2em; }
   p.verse { margin-left: 3%; }
+  .versenum {float:right;}
   pre {
 border: 1px solid #e6e6e6;
 border-radius: 3px;
@@ -3754,20 +3755,36 @@ information."
 
  Verse Block
 
-(defun org-html-verse-block (_verse-block contents info)
-  "Transcode a VERSE-BLOCK element from Org to HTML.
-CONTENTS is verse block contents.  INFO is a plist holding
-contextual information."
-  (format "\n%s"
-	  ;; Replace leading white spaces with non-breaking spaces.
-	  (replace-regexp-in-string
-	   "^[ \t]+" (lambda (m) (org-html--make-string (length m) ""))
-	   ;; Replace each newline character with line break.  Also
-	   ;; remove any trailing "br" close-tag so as to avoid
-	   ;; duplicates.
-	   (let* ((br (org-html-close-tag "br" nil info))
-		  (re (format "\\(?:%s\\)?[ \t]*\n" (regexp-quote br
-	 (replace-regexp-in-string re (concat br "\n") contents)
+(defun org-html-verse-block (verse-block contents info)
+"Transcode a VERSE-BLOCK element from Org to HTML.
+CONTENTS is verse block contents.  INFO is a plist holding
+contextual information."
+(let* ((lin (org-export-read-attribute :attr_html verse-block :lines))
+	   (versenum (if lin 0 ""))
+	   (seqverse (if lin (string-to-number lin) ""))
+	   (contents (if lin
+			 (with-temp-buffer
+			   (insert contents)
+			   (save-excursion
+			 (goto-char (point-min))
+			 (while (re-search-forward "^.+" nil t seqverse)
+			   (re-search-forward "$" nil t)
+			   (replace-match (concat ""
+		  (number-to-string
+		   (setf versenum (+ versenum seqverse)))
+		  ""
+			   (buffer-string))
+		   contents)))
+  (format "\n%s"
+	  ;; Replace leading white spaces with non-breaking spaces.
+	  (replace-regexp-in-string
+	   "^[ \t]+" (lambda (m) (org-html--make-string (length m) ""))
+	   ;; Replace each newline character with line break.  Also
+	   ;; remove any trailing "br" close-tag so as to avoid
+	   ;; duplicates.
+	   (let* ((br (org-html-close-tag "br" nil info))
+		  (re (format "\\(?:%s\\)?[ \t]*\n" (regexp-quote br
+		 (replace-regexp-in-string re (concat br "\n") contents))
 
 
 ;;; Filter Functions
-- 
2.32.0

Re: "Unknown processor biblatex"

[Max Nikulin]

On 04/10/2021 18:11, Eric S Fraga wrote:


#+cite_export: natbib plain


Is it serious security flaw to load backend when such instruction is parsed?


#+begin_src emacs-lisp
   (require 'oc-basic)
   (require 'oc-csl)
   (require 'oc-natbib)
#+end_src


There is (defcustom org-modules) and (defcusom org-export-backends) with 
list of modules. Maybe oc-* options should be added to org-modules or to 
a dedicated variable.

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi Tom,

> From time to time I encounter random patterns that I don’t want to be
> reformatted during a fill operation. Maybe a custom variable like
> org-fill-paragraph-skip-regexp or similar that could be set by the user?
> For Timothy’s use case he would set it to the regexp provided in the
> original patch? Not sure how much of the implementation in the patch
> is dependent on that particular regexp, but a general solution that
> could even be set per org file might be a very useful new feature.

Hmmm, that’s an interesting idea. I suppose you could have something like a list
of cons cells where the car is a regexp matching the start of the “don’t touch”
region and the cdr a regexp matching the end.

All the best,
Timothy

Re: Org lint and named source blocks

[Timothy]

Hi Tom,

> The issue for me is that I don’t have the bandwidth to get started
> with a full tree sitter implementation, especially because it is going
> to need a custom scanner, and because you’re effectively on your
> own when it comes to reconstructing the output of the AST into the
> actual internal representation of an Org file. I also have no idea how
> to deal with nested parsers in tree sitter. I have some ideas about
> how it might be done, but nothing concrete (see the linked issue
> for more on that).

orgmode.nvim is developing a tree-sitter parser, perhaps a dialog with them
could be productive?

All the best,
Timothy

Re: [BUG] Citations: exporting with csl crashes [9.5 (9.5-g0a86ad @ /home/quintus/.emacs.d/elpa/org-9.5/)]

[Nicolas Goaziou]

Hello,

Marvin Gülker  writes:

> I've been trying to use the new citation facilities in the just-released
> 9.5 version of org for a simple test document with my preferred CSL
> style (the one usually used in German law discipline in one way or
> another), but did not have luck with it so far. That being said,
> exporting with the default "bare" citation processor appears to be fine.
> With the "csl" processor, I receive this error when I export to LaTeX
> with `org-latex-export-as-latex':
>
> Debugger entered--Lisp error: (wrong-type-argument sequencep splice)
>   citeproc-rt--cquote-pstns-1(splice 15)

It looks like the issue is in the Citeproc library, not in the Org
wrapper. You may want to report it upstream.

Regards,
-- 
Nicolas Goaziou

Re: Org lint and named source blocks

[Ihor Radchenko]

Tom Gillespie  writes:

>> Should we allow syntax like #+KEYWORD:value to be correct or do we
>> require a whitespace/space after colon all the time?
>
> The spec as written is ambiguous/silent on this issue. In my work on
> laundry tokenizer and grammar I have found keyword syntax to be a
> thorny issue, and I strongly suggest that for the time being we either
> make no ruling on this or we state that the colon that ends the
> keyword should be followed by a space as a precautionary measure.
> The safe thing to do is to always require whitespace after the colon
> because it guarantees correct interpretation.

By the way, wouldn't it be better to use tree-sitter rather than
something else for the format grammar? At least, there is some work on
integrating tree-sitter into Emacs core [1,2].

[1] https://lists.gnu.org/archive/html/emacs-devel/2021-08/msg00268.html
[2] https://archive.casouri.cat/note/2021/emacs-tree-sitter/#Feedback

Best,
Ihor

Re: "Unknown processor biblatex"

[Colin Baxter]

> Bruce D'Arcus  writes:

> On Sun, Oct 3, 2021 at 4:57 PM autofrettage  
wrote:
>> 
>> Hi all,
>> 
>> I have really seen forward to the release of org mode 9.5 with
>> its new and shiny support for citations. The initial frenzy of
>> experimentation has lead to mixed results.
>> 
>> Right now I am trying to use the biblatex processor, but I only
>> get "Unknown processor biblatex". How is that even possible, when
>> that should be one of the processors provided by org mode 9.5?
>> 
>> Are there more packages, like citeproc.el, on which org-cite
>> depends, and I have to install manually? Is there some mandatory
>> set-up I have failed to notice?
>> 
>> I have tried to read
>> https://blog.tecosaur.com/tmio/2021-07-31-citations.html and the
>> manual page for the citations, but I am at my wits' end now.
>> 
>> Any pointer would be appreciated.

> You have to load oc-biblatex, say using use-package, and also set
> org-cite-export-processors, like:

> (setq org-cite-export-processors '((latex biblatex) (t csl)))

Great, but what about old timers like me who insist on using bibtex?

I sympathise with the op in not getting this new org-cite to
work. It has beaten me despite repeated efforts.

Best wishes,

Colin Baxter.

[PATCH] The align of time is not beautiful as 9.4 when I update to org 9.5.

[Ihor Radchenko]

tumashu  writes:

> Hello:
>
>
> When I update to org 9.5,  I find that  the align of time like "7:00" has 
> been changed.
>
> I think the new style is not beautiful as old style.
>  
> 1. New style look like not align to  the first char, for the width of 9 looks 
> like > 1
> 2. the old style is align ":"

The attached patch should fix the issue. Please, test it though. I do
not use time grid regularly.

Best,
Ihor

>From df5c35bd84e1d343c52c605c2c77393fb11ad590 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Mon, 4 Oct 2021 15:45:16 +0800
Subject: [PATCH] org-agenda: Make sure that time grid is aligned when hour <10

* lisp/org-agenda.el (org-agenda-format-item): Make sure that hour
part of begin time in time grid always occupy 5 chars

Fixes https://list.orgmode.org/orgmode/3afe1bba.2f48.17c350d0a41.coremail.tuma...@163.com/
---
 lisp/org-agenda.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-agenda.el b/lisp/org-agenda.el
index 354f40867..e20d0225f 100644
--- a/lisp/org-agenda.el
+++ b/lisp/org-agenda.el
@@ -6765,7 +6765,7 @@ (defvar level) (defvar tag) (defvar time))
 	(setq duration (- (org-duration-to-minutes s2)
 			  (org-duration-to-minutes s1
   ;; Format S1 and S2 for display.
-	  (when s1 (setq s1 (org-get-time-of-day s1 'overtime)))
+	  (when s1 (setq s1 (format "%05s" (org-get-time-of-day s1 'overtime
 	  (when s2 (setq s2 (org-get-time-of-day s2 'overtime
 	(when (string-match org-tag-group-re txt)
 	  ;; Tags are in the string
-- 
2.32.0

Re: Org lint and named source blocks

[Ihor Radchenko]

Ihor Radchenko  writes:

> This one is tricky. The linter (org-lint-duplicate-name) expects that
> NAME keyword must have space before value. However, the actual Org
> parser (org-element--collect-affiliated-keywords) does not care about
> space. My intuition says that the parser behaviour is
> unintentional. However, not requiring a whitespace may also be a valid
> syntax.

For the time being, let's prefer what org-element does over the linter.
I have pushed the fix to bugfix as bd0493eda.

Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Timothy]

Hi All,

Given the way the conversation has evolved I think it may be worth revisiting
another viewpoint to see if anybody has any nice ideas.

As things are, regardless of the complexities of parsing and inline vs.
block elements etc., just considering the user experience when running
org-fill on an example like the one below, the behaviour isn't /nice/.

Might there be some way we could allow for people who are used to LaTeX
and/or like \[ ... \] to have fill behaviour that leaves \[ ... \]
blocks alone? My original idea was changing how org-fill works for
everyone, the discussion has gone on to changing \[ ... \] to a block
element -- both of these seem to have rather significant issues.

Ihor came up with the idea of making org-fill something more
customisable by the user, so that someone could have this behaviour
without making Org behave un-idiomatically for everyone. I proposed
maybe just having a setting could be a halfway house between my original
patch and his idea.

Does anybody have any other thoughts?

> If you’re wondering why I’m so opposed to the current behaviour, that is 
> probably
> best explained by a more realistic demo that what I have in the commit 
> message.
>
> ┌
> │ Since \(\cos\) is an even function, we can negate the numerator of the 
> argument
> │ without changing the result, giving
> │ \[
> │   \cos \left( \pi \frac{C_1-x}{2C_1+D} \right) \ , \quad C_1 = \frac{D}{2}.
> │ \]
> │ this will be positive over \(x \in (0,D)\), and so we can rewrite 
> \(\tilde{y}\) as,
> │ \[
> │   \tilde{y}(x) = \frac{2D}{\pi} \log \cos \left( \pi 
> \frac{\frac{D}{2}-x}{2D} \right) + C_2.
> │ \]
> │ Once again considering that \(y(0)=y(D)=0\), it is clear that
> │ \[
> │   C_2 = - \frac{2D}{\pi} \log \cos \left( \frac{\pi}{4} \right) = - 
> \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = \frac{D}{\pi} \log 2.
> │ \]
> │ The complete solution for \(\tilde{y}\) is hence,
> │ \[
> │   \tilde{y} = \frac{2D}{\pi} \log \cos \left( \pi \frac{D-2x}{4D} \right) + 
> \frac{D}{\pi} \log 2.
> │ \]
> └
> is currently filled to
> ┌
> │ Since \(\cos\) is an even function, we can negate the numerator of the 
> argument
> │ without changing the result, giving \[ \cos \left( \pi \frac{C_1-x}{2C_1+D}
> │ \right) \ , \quad C_1 = \frac{D}{2}. \] this will be positive over \(x \in 
> (0,D)\),
> │ and so we can rewrite \(\tilde{y}\) as, \[ \tilde{y}(x) = \frac{2D}{\pi} 
> \log \cos \left( \pi
> │ \frac{\frac{D}{2}-x}{2D} \right) + C_2. \] Once again considering that
> │ \(y(0)=y(D)=0\), it is clear that \[ C_2 = - \frac{2D}{\pi} \log \cos \left(
> │ \frac{\pi}{4} \right) = - \frac{2D}{\pi} \log 2^{-\frac{1}{2}} = 
> \frac{D}{\pi} \log 2.
> │ \] The complete solution for \(\tilde{y}\) is hence, \[ \tilde{y} = 
> \frac{2D}{\pi} \log \cos
> │ \left( \pi \frac{D-2x}{4D} \right) + \frac{D}{\pi} \log 2. \]
> └

--
Timothy

Re: Debbugs Usage

[Bastien]

Hi Daniel,

Daniel Fleischer  writes:

> Hi, is debbugs org-mode being used?

No, Org bugs reports created with M-x org-submit-bug-report are sent
to this list.  When they are confirmed by someone, they appear in the 
https://updates.orgmode.org interface.

Some Emacs bug reports created with M-x report-emacs-bug are related
to Org: in that case, someone is tagging them with "org", they appear
in https://debbugs.gnu.org as such, but the conversation is forwarded
to the Org mailing list.

-- 
 Bastien

Re: [PATCH] Don't fill displayed equations

[Tom Gillespie]

> Does anybody have any other thoughts?

>From time to time I encounter random patterns that I don't want to be
reformatted during a fill operation. Maybe a custom variable like
org-fill-paragraph-skip-regexp or similar that could be set by the user?
For Timothy's use case he would set it to the regexp provided in the
original patch? Not sure how much of the implementation in the patch
is dependent on that particular regexp, but a general solution that
could even be set per org file might be a very useful new feature.

Best!
Tom

Re: Org mode web site

[Bastien]

Hi Thomas and Tim,

Timothy  writes:

>> I’m seeing what looks like a spurious headline:   Elaboration + demo image
>> ignore
>
> Thanks, that is indeed spurious. “ignore” is the tag :ignore: but it seems 
> like
> the ox-extra that makes :ignore: work isn’t being loaded any more.

Fixed, thanks!

-- 
 Bastien

Re: [PATCH] Don't fill displayed equations

[Przemysław Pietrzak]

Hi Org-mode community!

> Does anybody have any other thoughts?

I have been following your discussion for several days
and if I understand it correctly promoting \[ to an element
is the most controversial.

Isn’t the behavior of fill-paragraph
(see https://emacs.stackexchange.com/q/29122/14127 
)
the biggest inconvenience?

Perhaps adding a proper fill-nobreak-predicate 
(see https://emacs.stackexchange.com/a/12419/14127 
)
would be enough?

This regex https://stackoverflow.com/a/14537848 
 may be a good starting point.

Best regards!
Premo

Re: New HTML exporter (was a feature request)

[Timothy]

Hi Tim,

> Probably what is needed is a new HTML exporter which is capable of doing
> what slimhtml does as the default, but includes the additional
> functionality already in the exporter which many people are using.

I think there may be some promise in the idea of rewriting (large parts of) the
current HTML exporter. The way that the web has changed over the last decade I
think we can now make some assumptions that can simplify things — for example
I think we could safely go HTML5-only.

Not something I have time to investigate now, but in a month or two (or
three ) I might take a look.

All the best,
Timothy

Re: Org lint and named source blocks

[Tom Gillespie]

> By the way, wouldn't it be better to use tree-sitter rather than
> something else for the format grammar?

Not really since we are going to need more than one implementation
using a parser generator to avoid baking implementation specific
details into the spec by accident. This is true for more than just
the grammar as well. The complexity of tokenization, parsing,
expanding, etc, for Org means that we are going to need multiple
implementations to nail the behavior for any formal spec.

That said, we definitely want a TS implementation at some point.
See https://github.com/tgbugs/laundry/issues/1 for a recent
discussion about ways forward.

The implementation I'm working on should translate to TS without
too much work since both brag and tree sitter describe LR variants.
There may be some subtle differences, but nothing fundamental.

The issue for me is that I don't have the bandwidth to get started
with a full tree sitter implementation, especially because it is going
to need a custom scanner, and because you're effectively on your
own when it comes to reconstructing the output of the AST into the
actual internal representation of an Org file. I also have no idea how
to deal with nested parsers in tree sitter. I have some ideas about
how it might be done, but nothing concrete (see the linked issue
for more on that).

Best,
Tom

Re: Unable to follow gnus links

[Ihor Radchenko]

Tom Ed White  writes:

> I was able to fix the problem for the time being by changing the
> arguments to:
>
> (defun org-gnus-open (path  _)
>
> The keystroke I use is C-c C-o, which runs org-open-at-point which is in
> org.el.

I understand. But it does not solve the potential problem for other users.

> Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1)
> ... ((functionp (org-link-get-parameter type :follow)) (funcall
> (org-link-get-parameter type :follow) path))
> ...

Judging from your backtrace, you seem to have a mixed Org installation
with some files loaded from Org <9.4 (that's when we changed the number
of arguments in :follow functions).

Can you try to re-install Org?

Note that mixed installation can also cause other unexpected problems.

Best,
Ihor

Re: [PATCH] Don't fill displayed equations

[Max Nikulin]

My thanks to Ihor for the argument concerning code of (maybe external) 
exproters and to Tom for parser-related considerations.


I think it is a kind of trade-off: breaking change vs. continuously 
breaking user experience. Do not worry too much, there is almost no 
chance that I will try to implement my plan, so current state will 
remain as is. In naive form my idea was:


1. Find the code where \( \) is parsed and remove \[ \] option
2. Find the place where \begin{equation} is handled and add \[ somewhere 
around.


I fill some misunderstanding since some arguments has the form "it is 
too hard because it requires ..." where "..." exactly what I was going 
to discuss.


On 04/10/2021 12:57, Tom Gillespie wrote:



Maybe you are right and Tom was actually assuming \begin{equation*}, not
#+begin_export latex.


Correct. My bad on that one.


By the way, I realized that choice of "\begin{equation}" and not 
"#+begin_equation" is not clear to me. However it allows to pass 
\begin{equation} to LaTeX or HTML+MathJax transparently.



Just as Timothy, I believe that \begin{equation*} is unnecessary verbose
when \[ works *mostly* in a similar way.


\begin{equation*} is absolutely required if you want to be able to include
newlines because \[ and \begin are not similar at all as far as parsing
is concerned.

 From the spec: https://orgmode.org/worg/dev/org-syntax.html#LaTeX_Environments

CONTENTS can contain anything but the “\end{NAME}” string.

The spec is not completely accurate since latex environments can't
contain a new heading, but the point is that latex environments are
elements, whereas \[ \] is an object.

  
I was going to discuss namely this change.


Isn't the whole point of the \[ ... \], \( ... \), $ ... $, $$ ... $$,
and \begin{env} ... \end{env} and constructs in Org to be consistent
with LaTeX?


For \begin and \end yes. For the others no.


Unsure, but then forbidding \[ \] at all may result in less confusion 
then current state "inline object that is transformed to block element 
during export". Making \[ \] a special case for paragraph filling when 
it is inline object would be even more confusing.



I'm actually fairly certain that such a change should never be made
due to the recent changes in org link syntax. Specifically given how
\[ is used for escapes in links. https://orgmode.org/manual/Link-Format.html
This means that the only place you could reliably use \[ is at the start of a
new line preceded only by whitespace. However, if this were to happen then
pretty much every org document that uses \[ \] is at risk for being broken
because something that was once a single paragraph will now be multiple
paragraphs.


Agree that context-dependent "\]" may cause problems.


If you need multiline use \begin \end, that is what they are there for, and they
fit better with org's general extensible approach to blocks. I would dearly love
to be able to have a single shorthand for src blocks that worked inline and
standalone,


I do not suggest using \[ \] both for inline object and block elements. 
I hope that even if behavior of \[ \] inside paragraphs were not 
specified it would not break user files since it will be transparently 
passed to LaTeX or HTML. However, LaTeX exporter may escape them to have 
it literally in the output.



Consider the case where you have something like

\[ something something

more content
more content [[www.example.com/\]oops][evil link]] \]


Frankly speaking, with Org I never sure in such cases whether everything 
inside \[ \] will be literally copied to LaTeX file or some some Org 
markup will be handled, so it is possible to insert something e.g. 
inside \text{}.



\[ a

b \]

\[
a
b
\]

a \[ b

c \] d


Similar variants exist for \begin{equation} \end{equation}


In short. Just not worth it.


The value of TeX, markdown, reStructured text, Org is convenience to 
type in comparison with SGML formats that are not really human 
friendly. In this sense \[ is noticeably better than \begin{equation*}.

Re: Some broken links in pages under https://orgmode.org/worg/org-contrib/babel

[Daniel Fleischer]

Mandar Mitra [2021-10-04 Mon 18:15] wrote:

Confirmed

5 Broken links:

> * https://orgmode.org/worg/org-contrib/babel/intro.html
> *** ... relevant section in the 
> [[https://orgmode.org/manual/Literal-examples.html][Org manual]] ...
> *** please have a look at the 
> [[https://orgmode.org/manual/Literal-examples.html][Org-mode manual]] before 
> proceeding
> *** blocks located in the 
> [[https://orgmode.org/worg/org-contrib/babel/library-of-babel.html][Library 
> of Babel]] file – raw file at
>
> * https://orgmode.org/worg/org-contrib/babel/uses.html
> *** 
> [[https://orgmode.org/worg/org-contrib/babel/examples/org-check.html][Checking
>  Your Org Mode Configuration]]
> *** 
> [[https://orgmode.org/worg/org-contrib/babel/examples/data-collection-analysis.html][Data
>  Collection and Analysis]]


-- 

Daniel Fleischer

Re: [BUG] Citations: exporting with csl crashes [9.5 (9.5-g0a86ad @ /home/quintus/.emacs.d/elpa/org-9.5/)]

[M . ‘quintus’ Gülker]

Am Montag, dem 04. Oktober 2021 schrieb Nicolas Goaziou:
> It looks like the issue is in the Citeproc library, not in the Org
> wrapper. You may want to report it upstream.

Ah, I see. Thank you for the pointer. I created an issue ticket with a
copy of the OP here:


  -quintus


-- 
Dipl.-Jur. M. Gülker | https://mg.guelker.eu | PGP: Siehe Webseite
Passau, Deutschland  | kont...@guelker.eu| O<

Re: Best way to include METAPOST in ConTeXt exporter

[Jason Ross]

I had considered using special blocks; they match my mental model the best.
However, they don't provide any support for syntax highlighting or opening
the block in a new major mode buffer. I'm not sure if it's worth giving up
language features in order to use the block that's most intuitive to users.

I'm also considering writing an Org Babel module for METAPOST. This could
allow METAPOST figures to be included with any export backend. However,
if I go this route, there are still some challenges:
1. Getting captions and tags attached to the resulting figures is clumsy.
   As far as I know,  this could be done with the :post header argument
   and a wrapper source block, but this would require boilerplate code
   in documents that use this feature
2. I don't know if there's a reasonable way to leverage ConTeXt's native support
   for METAPOST this way; if I ask Org Babel to generate an SVG, ConTeXt then
   has to parse the SVG and (internally) convert it back into METAPOST to
   render in the document. ConTeXt's SVG support (particularly with mathematical
   symbols) is missing some features, so this will be a lossy process.
   Essentially I'd want the module to return a file most of the time, but
   return raw METAPOST (wrapped in some tags) if the ConTeXt backend is used.

Here's a minimal implementation of the source block concept:

# Define a macro to add header arguments UNLESS ConTeXt backend is used
#+MACRO: conditional-header (eval (when (not (eq
org-export-current-backend 'context)) (concat  "#+HEADER: :results
file :file " $1)))

# Define a wrapper block to annotate source block outputs with
# caption and name
#+NAME: wrap_metapost
#+BEGIN_SRC emacs-lisp :var data="" :var caption="" :var name=""
(concat
 (when (org-string-nw-p name) (format "#+NAME: %s\n" name))
 (when (org-string-nw-p caption) (format "#+CAPTION: %s\n" caption))
 (if (eq org-export-current-backend 'context)
 (format "#+BEGIN_METAPOST \n%s\n#+END_METAPOST" data)
   data))
#+END_SRC

# Minimal Org Babel implementation for METAPOST
#+BEGIN_SRC emacs-lisp
(defvar org-babel-default-header-args:metapost
  '((:exports . "results"))
  "Default arguments to use when evaluating a dot source block.")
(defun org-babel-execute:metapost (body params)
  "Execute a block of METAPOST code with org-babel.
This function is called by `org-babel-execute-src-block'."
  (if (cdr (assq :file params))
  (let* ((out-file (cdr (assq :file params)))
 (cmdline (or (cdr (assq :cmdline params))
  (format "-T%s" (file-name-extension out-file
 (cmd (or (cdr (assq :cmd params)) "mpost"))
 (coding-system-for-read 'utf-8) ;use utf-8 with sub-processes
 (coding-system-for-write 'utf-8)
 (in-file (org-babel-temp-file "metapost-")))
(with-temp-file in-file
  (insert (org-babel-expand-body:generic body params)))
(org-babel-eval
 (concat cmd
 " -s 'outputformat=\"svg\"'"
 (format " -s 'outputtemplate=\"%s\"'"
(org-babel-process-file-name out-file))
 " " (org-babel-process-file-name in-file)) "")
nil)
body))
#+END_SRC

# Example Usage
{{{conditional-header(foo.svg)}}}
#+BEGIN_SRC metapost :results drawer :post
wrap_metapost(name="my-name", caption="my-caption", data=*this*)
beginfig(1);
draw origin--(100,100)--(200,0)--cycle;
endfig;
end;
#+END_SRC

This kind of works: It exports to HTML with a nice SVG figure and sends raw
METAPOST code to the backend, with #+CAPTION and #+NAME information
attached. Also, links to the figures work in the buffer as well as the pdf.

However, there's a lot I don't like about this.
1. No SVG preview in the buffer since the `conditional-header` macro doesn't
   get expanded until export time
2. Boilerplate; both the `conditional-header` and `wrap_metapost` definitions
   need to be included in the org file
3. Inconvenient to use since I have to add a macro call and a :post argument
   with weird syntax to every METAPOST figure, and the way captions and tags
   are specified is different.



On Mon, Oct 4, 2021 at 1:39 AM Ihor Radchenko  wrote:
>
> Jason Ross  writes:
>
> > Hello,
> >
> > I'd like to include METAPOST figures in the ConTeXt exporter backend I'm
> > developing. However, I don't know of an idiomatic way to add captions and
> > references for the figures.
>
> You can use affiliated keywords:
>
> (defconst org-element-affiliated-keywords
>   '("CAPTION" "DATA" "HEADER" "HEADERS" "LABEL" "NAME" "PLOT" "RESNAME" 
> "RESULT"
> "RESULTS" "SOURCE" "SRCNAME" "TBLNAME")
>   "List of affiliated keywords as strings.
> By default, all keywords setting attributes (e.g., \"ATTR_LATEX\")
> are affiliated keywords and need not to be in this list.")
>
> > Currently, I 

Re: Best way to include METAPOST in ConTeXt exporter

[Ihor Radchenko]

Jason Ross  writes:

> I had considered using special blocks; they match my mental model the best.
> However, they don't provide any support for syntax highlighting or opening
> the block in a new major mode buffer. I'm not sure if it's worth giving up
> language features in order to use the block that's most intuitive to users.
>
> I'm also considering writing an Org Babel module for METAPOST. This could
> allow METAPOST figures to be included with any export backend. However,
> if I go this route, there are still some challenges:

If you are in control of the export backend, you can directly process
the metapost source blocks during export and ignore/filter their output
as needed.

>#+MACRO: conditional-header (eval (when (not (eq
> org-export-current-backend 'context)) (concat  "#+HEADER: :results
> file :file " $1)))

>#+BEGIN_SRC metapost :results drawer :post
> wrap_metapost(name="my-name", caption="my-caption", data=*this*)

Or you can use "raw" results by default and format everything as you
wish in your Org Babel module programatically.

If above is not sufficient, you can install global export filters that
can transform the metapost blocks/source blocks/their results as you
need in other export backends.

Best,
Ihor

Re: master-->main?

[Bhavin Gandhi]

Hi Uwe,

On Mon, 4 Oct 2021 at 17:50, Uwe Brauer  wrote:
>
> Was master «renamed» main, I mean is the default branch now main instead of 
> master?
>

As far as I have understood, yes. master branch was renamed to main.
Reference: https://list.orgmode.org/87ee9bbpc9@gnu.org/

-- 
Regards,
Bhavin Gandhi (bhavin192) | https://geeksocket.in

Re: [BUG] Citations: exporting with csl crashes [9.5 (9.5-g0a86ad @ /home/quintus/.emacs.d/elpa/org-9.5/)]

[Nicolas Goaziou]

Hello,

M. ‘quintus’ Gülker  writes:

> Ah, I see. Thank you for the pointer. I created an issue ticket with a
> copy of the OP here:
> 

Great! Thank you.

Regards,
-- 
Nicolas Goaziou

Re: 9.5: coping with loss of ditaa.jar

[Tim Cross]

Eric S Fraga  writes:

> On Sunday,  3 Oct 2021 at 07:25, Jarmo Hurri wrote:
>> 1. I am running Fedora 34, where ditaa is available as a
>>package. However, just pointing org-ditaa-jar-path to the correct
>>location /usr/share/java/ditaa.jar is not sufficient, because doing
>>so leads to errors when trying to execute a ditaa babel block:
>
> On Debian 11 (bullseye, most recent stable version), this works just
> fine for me.  I didn't need to feed any parameters, as you have
> suggested being necessary.  I don't know why, mind you.  It could be a
> different version of ditaa.jar?  On Debian 11, the version installed is
> 0.10+ds1-1.2.

I suspect the difference is between having what Java calls a
'stand-alone' jar and a library jar.

With a 'stand-alone' jar, all dependencies needed by the java program
are bundled into the jar. With a library jar, only the specific code
that makes up the library is included. It is a little like static versus
dynamic linking of libraries. The idea is that with the lib only jar,
you would already have the library dependencies installed (via maven or
similar).

>From the OP's original post, my guess is the jar they had was only the
library, not a stand-alone jar with all the dependencies included. The
ditta release page holds both stand-alone and minimal lib jars from
memory. Most people will want the stand-alone version. 

Re: "Unknown processor biblatex"

[Colin Baxter]

Dear Eric,

> Eric S Fraga  writes:

> Colin, I also only use the basics when writing articles.  With the
> new org-cite, the closest I have is with the following settings,
> as an example:

> #+cite_export: natbib plain #+latex_header:
> \usepackage[numbers,sort,super]{natbib}

> #+bibliography: ~/[...]/bibliography.bib

> This converts the simplest [cite:@author] to \citep{author}.
> Natbib settings need to be adjusted to your tastes/needs, of
> course.

> In my org configuration, I have

> #+begin_src emacs-lisp (require 'oc-basic) (require 'oc-csl)
> (require 'oc-natbib) #+end_src

> to cover all the bases.

> I have not been able to get away from using natbib for LaTeX
> export, unfortunately.  A simple basic bibtex org-cite exporter
> would be welcome, one that simply generates \cite{author} without
> any frills.

> It's important to highlight that, to me, the advantage of
> org-cite, over what I was using before with my own cite: link
> definition, is that changing that first line to something like

> #+cite_export: csl "[...]/acm-siggraph.csl"

> lets me export the same document to ODT or text with the
> citations.  It's not something I need often but I did in fact need
> it just recently and was greatly welcome!

Thank you very much for your interesting reply. For "serious" work I've
always used only LaTeX, reserving org-mode for notes; consequently for
me, there not much motivation to get the new org-mode cite to
work. However I'll give your settings a try.

Best wishes,

Colin.

Re: 9.5: coping with loss of ditaa.jar

[Eric S Fraga]

On Tuesday,  5 Oct 2021 at 00:28, Tim Cross wrote:
> I suspect the difference is between having what Java calls a
> 'stand-alone' jar and a library jar.

[...]

> Most people will want the stand-alone version. 

That sounds like a reasonable summary.  It will be good to get
confirmation along the way and a clear directive on how to ensure org
knows how to use the jar file.  I do rely on ditaa (mostly for teaching
related activities) and hadn't thought about the implications of having
the ditaa.jar file moved out of org-contrib.

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: "Unknown processor biblatex"

[Eric S Fraga]

On Monday,  4 Oct 2021 at 14:36, Colin Baxter wrote:
> For "serious" work I've always used only LaTeX, reserving org-mode for
> notes

I moved 100% to org for my writing (& coding) some time ago now.  In the
earlier days, I often had to do the final steps before submitting in
LaTeX itself but, for some time now, I have been able to all of my
writing and configuring within the org document and then simply upload
the resulting LaTeX file(s).

But it definitely helps to know LaTeX to ensure that various bits are
done as the publisher wants (style file, title page, authors'
institutions, figure captions, etc.)

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: Citation in footnote not expanded/exported to LaTeX (using Org-ref-cite)

[Bruce D'Arcus]

On Sun, Oct 3, 2021 at 6:23 PM Nicolas Goaziou  wrote:
>
> Hello,
>
> Elias Bounatirou  writes:
>
> > Just to clarify the BUG:
> > Citations in a footnote in the following environment are not exported to
> > LaTeX: when the footnote follows two or more citations, of which one has a
> > suffix, i.e. for instance in
> >
> > Body text with a citation: [cite:@low2001; @mcneill2011 with a
> > suffix][fn:3].
>
> I cannot reproduce the problem. With the following document:
>
> --8<---cut here---start->8---
> #+bibliography: foo.bibtex
> #+cite_export: biblatex authoryear

Can you try with a note-based style like verbose?

Bruce

Re: New HTML exporter (was a feature request)

[Matt Price]

On Mon., Oct. 4, 2021, 2:21 a.m. Timothy,  wrote:

> Hi Tim,
>
> > Probably what is needed is a new HTML exporter which is capable of doing
> > what slimhtml does as the default, but includes the additional
> > functionality already in the exporter which many people are using.
>
> I think there may be some promise in the idea of rewriting (large parts
> of) the
> current HTML exporter. The way that the web has changed over the last
> decade I
> think we can now make some assumptions that can simplify things — for
> example
> I think we could safely go HTML5-only
>

> It seems to me that if the html exporter is being rewritten, we might want
to think about ways to make it easier to export some elements as custom
components. As their use becomes more and more common, I would reckon this
will be a desirable feature.


>
>

Re: "Unknown processor biblatex"

[Nicolas Goaziou]

Hello,

Colin Baxter  writes:

>> Bruce D'Arcus  writes:

> > You have to load oc-biblatex, say using use-package, and also set
> > org-cite-export-processors, like:
>
> > (setq org-cite-export-processors '((latex biblatex) (t csl)))
>
> Great, but what about old timers like me who insist on using bibtex?

What do you mean by "using bibtex"? In particular, what package, if any,
do you use to actually cite something? Do you limit yourself to the
built-in "\cite" and "\nocite" commands? If that's the case, there is no
support for it yet, though it should be trivial to add some.

> I sympathise with the op in not getting this new org-cite to
> work. It has beaten me despite repeated efforts.

You may want to report what didn't work for you.

Regards,
-- 
Nicolas Goaziou

Re: "Unknown processor biblatex"

[Colin Baxter]

> Nicolas Goaziou  writes:

> Hello, Colin Baxter  writes:

>>> Bruce D'Arcus  writes:

>> > You have to load oc-biblatex, say using use-package, and also
>> set > org-cite-export-processors, like:
>> 
>> > (setq org-cite-export-processors '((latex biblatex) (t csl)))
>> 
>> Great, but what about old timers like me who insist on using
>> bibtex?

> What do you mean by "using bibtex"? In particular, what package,
> if any, do you use to actually cite something?

I don't understand the question.

1. In LaTeX I simply use \bibliography, \cite and the command "bibtex".
2. In org-mode, I use ol-bibtex and reftex-cite. Works well, although I
   only use org-mode occasionally for notes. I change [[bib:ref]] to
   [[cite:ref]] automatically.

> Do you limit
> yourself to the built-in "\cite" and "\nocite" commands?

I only use \cite. Qualifications, such as page numbers, etc, I insert as
normal text about the citation, or as a footnote. I like to keep things
simple, which is one reason I don't use biblatex - and I can't be
bothered to learn it.

Best wishes,

Colin Baxter.

Re: invalid-function (date date) after update to 9.5

[Ihor Radchenko]

Florian Lindner  writes:

> Hello,
>
> after the upgrade to 9.5 (9.5-g0a86ad @ /home/florian/.emacs.d/elpa/org-9.5/) 
> on 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 
> 1.16.0) of 2020-09-19 my agenda stopped working
>
> (org-agenda) -> any keyword (a, t or n) gives:

Duplicate of https://list.orgmode.org/87y27adbnh@iki.fi/T/#t

Re: [PATCH] The align of time is not beautiful as 9.4 when I update to org 9.5.

[Max Nikulin]

On 04/10/2021 14:48, Ihor Radchenko wrote:

tumashu writes:


When I update to org 9.5,  I find that  the align of time like "7:00" has been 
changed.

I think the new style is not beautiful as old style.
  
1. New style look like not align to  the first char, for the width of 9 looks like > 1

2. the old style is align ":"


The attached patch should fix the issue. Please, test it though. I do
not use time grid regularly.



- (when s1 (setq s1 (org-get-time-of-day s1 'overtime)))
+ (when s1 (setq s1 (format "%05s" (org-get-time-of-day s1 'overtime


I think, "%5s" is enough, flag "0" does not anything useful for strings.

Re: org-element.el change in emacs.git

[Adam Porter]

Hi Amin,

Amin Bandali  writes:

>> By the way, I'm curious, not having always followed the internal details
>> of Org's development over the years: why are changes like that made to
>> emacs.git and merged back into Org, instead of being made in Org and
>> then merged back into Emacs with the next sync?  It seems like it could
>> be a burden, requiring someone like you to track them and merge them,
>> but there's probably a good reason for this workflow.
>>
>
> Speaking from personal experience/observations, as far as I know the
> Emacs developers don't have strict rules about having uni-directional
> changes.  And this is not unique to Org; I've seen similar changes in
> both directions in other projects developed outside emacs.git that are
> periodically merged into emacs.git.  Eliminating the need for keeping
> track of such changes is one potential argument for developing Org --
> and those other similar packages -- inside emacs.git itself. :)

That would be an interesting development, indeed.  :)  Thanks.

Re: how to pull from the git org repo

[tomas]

On Mon, Oct 04, 2021 at 12:47:58PM +0200, Uwe Brauer wrote:
> 
> Hi
> 
> I just realized that the org repo I am pulling from is
> *   commit 52b09799cfba0a847e93c9e21883266570644245 (HEAD -> master, 
> origin/master, origin/HEAD)
> |\  Merge: 846801e 21eb69c
> | | Author: Nicolas Goaziou 
> | | Date:   Fri May 21 18:30:23 2021 +0200
> | |
> | | Merge branch 'maint'
> 
> But now 
> 
>  git pull 
> 
> Gives me:
> 
> fatal: unable to access 'https://code.orgmode.org/bzg/org-mode.git/': server 
> certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
> CRLfile: none

It seems that some letsencrypt root certificate has
changed from under the Intratubes. Perhaps updating
your OS will fix that (if it's Debian, updating the
ca-cacert might do the trick).

> Did the repository move, and then where to?

The error message suggests otherwise. Can you access
that URL from your browser?

Cheers
 - t


signature.asc
Description: Digital signature

Re: Best way to include METAPOST in ConTeXt exporter

[Ihor Radchenko]

Jason Ross  writes:

> Hello,
>
> I'd like to include METAPOST figures in the ConTeXt exporter backend I'm
> developing. However, I don't know of an idiomatic way to add captions and
> references for the figures.

You can use affiliated keywords:

(defconst org-element-affiliated-keywords
  '("CAPTION" "DATA" "HEADER" "HEADERS" "LABEL" "NAME" "PLOT" "RESNAME" "RESULT"
"RESULTS" "SOURCE" "SRCNAME" "TBLNAME")
  "List of affiliated keywords as strings.
By default, all keywords setting attributes (e.g., \"ATTR_LATEX\")
are affiliated keywords and need not to be in this list.")

> Currently, I export METAPOST with `#+BEGIN_EXPORT metapost` / `#+END_EXPORT`
> tags. However, this feature seems to be intended for completely "raw"
> outputs
> with no markup or tagging in the resulting export. I'm interested in
> supporting
> at least `#+NAME` and `#+CAPTION` keywords for METAPOST figures so that they
> can be referred to in the Org file and also in the exported pdf.



> What are some better ways of doing something like this? Source blocks? How
> would
> a user expect to use a feature like this?


You can use a special block:
#+caption: Sample caption
#+attr_context: :field value
#+begin_metapost
...
#+end_metapost

The parsed representation of this element in exporter will be something like:

(special-block (:type "metapost" :begin 292 :end 382 :contents-begin 364 
:contents-end 368 :post-blank 0 :post-affiliated 347 :caption (((#("Sample 
caption" 0 14 (:parent #4) :attr_context (":field value")))


Best,
Ihor

invalid-function (date date) after update to 9.5

[Florian Lindner]

Hello,

after the upgrade to 9.5 (9.5-g0a86ad @ /home/florian/.emacs.d/elpa/org-9.5/) 
on 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cairo version 
1.16.0) of 2020-09-19 my agenda stopped working

(org-agenda) -> any keyword (a, t or n) gives:

Debugger entered--Lisp error: (invalid-function (date date))
(date date)()
org-agenda-get-day-entries("/home/florian/org/capture.org" (10 4 2021) 
:deadline :scheduled :timestamp :sexp)
apply(org-agenda-get-day-entries "/home/florian/org/capture.org" (10 4 2021) 
(:deadline :scheduled :timestamp :sexp))
org-agenda-list(nil)
funcall-interactively(org-agenda-list nil)
call-interactively(org-agenda-list)
#f(compiled-function () #)()
funcall(#f(compiled-function () #))
(let nil (funcall '#f(compiled-function () #)))
eval((let nil (funcall '#f(compiled-function () #
org-agenda-run-series("Agenda and all TODOs" (((agenda "") (alltodo ""
org-agenda(nil)
funcall-interactively(org-agenda nil)
call-interactively(org-agenda nil nil)
command-execute(org-agenda)

When I move capture.org out of the way, it happens to another file. Any hint 
what can be the problem here or where I can start looking?

I have seen the problem mentioned in 
www.reddit.com/r/DoomEmacs/comments/mlc7qi/orgagenda_stopped_working_after_upgrade/
 but that basically says to reinstall. I deleted my elpa folder and 
reinstalled, but nothing changed.

Thanks!

Re: Org lint and named source blocks

[Tom Gillespie]

Thanks for the pointer! The actual point of contact seems to be
https://github.com/milisims/tree-sitter-org. Good to find another
group that is working on this. Best,
Tom

Re: [PATCH] The align of time is not beautiful as 9.4 when I update to org 9.5.

[Nicolas Goaziou]

Hello,

Max Nikulin  writes:

> On 04/10/2021 14:48, Ihor Radchenko wrote:
>> tumashu writes:
>>>
>>> When I update to org 9.5,  I find that  the align of time like "7:00" has 
>>> been changed.
>>>
>>> I think the new style is not beautiful as old style.
>>>   1. New style look like not align to  the first char, for the
>>> width of 9 looks like > 1
>>> 2. the old style is align ":"
>> The attached patch should fix the issue. Please, test it though.
>> I do
>> not use time grid regularly.
>
>> -  (when s1 (setq s1 (org-get-time-of-day s1 'overtime)))
>> +  (when s1 (setq s1 (format "%05s" (org-get-time-of-day s1 'overtime
>
> I think, "%5s" is enough, flag "0" does not anything useful for
> strings.

Also, the fix belongs to `org-get-time-of-day', which is also
responsible for formatting the output.

Regards,
-- 
Nicolas Goaziou

Re: [PATCH] The align of time is not beautiful as 9.4 when I update to org 9.5.

[Ihor Radchenko]

Nicolas Goaziou  writes:

>> I think, "%5s" is enough, flag "0" does not anything useful for
>> strings.
>
> Also, the fix belongs to `org-get-time-of-day', which is also
> responsible for formatting the output.

I doubt so. `org-get-time-of-day' is used to format ending time in time
ranges.  If we force fixed width in `org-get-time-of-day', we may have
something like " 8:00- 9:00" instead of " 8:00-9:00".  On the other
hand, the current behaviour for non-nil org-agenda-timegrid-use-ampm, we
already have "8am- 9am" even without the patch.

WDYT?

Best,
Ihor

how to pull from the git org repo

[Uwe Brauer]

Hi

I just realized that the org repo I am pulling from is
*   commit 52b09799cfba0a847e93c9e21883266570644245 (HEAD -> master, 
origin/master, origin/HEAD)
|\  Merge: 846801e 21eb69c
| | Author: Nicolas Goaziou 
| | Date:   Fri May 21 18:30:23 2021 +0200
| |
| | Merge branch 'maint'

But now 

 git pull 

Gives me:

fatal: unable to access 'https://code.orgmode.org/bzg/org-mode.git/': server 
certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
CRLfile: none


Did the repository move, and then where to?

Thanks

Uwe Brauer 

Re: org-capture-template with changing heading (including a TIMESTAMP)

[Uwe Brauer]

> Uwe Brauer  writes:

> Because you did not supply a function. The docstring says:
> (file+function "path/to/file" function-finding-location)


Oops I read

 (file+function "path/to/file" function-finding-location)
 A function to find the right location in the file

 (clock)
File to the entry that is currently being clocked

And took the entry (clock) for that function-finding-location 

My bad.

I have to read and understand the role of that function better.


smime.p7s
Description: S/MIME cryptographic signature

Re:[PATCH] The align of time is not beautiful as 9.4 when I update to org 9.5.

[tumashu]

At 2021-10-04 15:48:49, "Ihor Radchenko"  wrote:
>tumashu  writes:
>
>> Hello:
>>
>>
>> When I update to org 9.5,  I find that  the align of time like "7:00" has 
>> been changed.
>>
>> I think the new style is not beautiful as old style.
>>  
>> 1. New style look like not align to  the first char, for the width of 9 
>> looks like > 1
>> 2. the old style is align ":"
>
>The attached patch should fix the issue. Please, test it though. I do
>not use time grid regularly.

If change s1, I think s2 should be deal with too, by the way, what about change 
the below function?

```
(defun org-agenda-time-of-day-to-ampm-maybe (time)
  "Conditionally convert TIME to AM/PM format.
This is based on `org-agenda-timegrid-use-ampm'."
  (if org-agenda-timegrid-use-ampm
  (org-agenda-time-of-day-to-ampm time)
time))
^^^
```

Another way is creating a new function for the below code, so user can advice 
it to full control time string format.

```
(cond (s2 (concat
  (org-agenda-time-of-day-to-ampm-maybe s1)
  "-" (org-agenda-time-of-day-to-ampm-maybe s2)
  (when org-agenda-timegrid-use-ampm " ")))
 (s1 (concat
  (org-agenda-time-of-day-to-ampm-maybe s1)
  (if org-agenda-timegrid-use-ampm
  (concat time-grid-trailing-characters " ")
time-grid-trailing-characters)))
 (t ""))

```


>
>Best,
>Ihor
>

Re: "Unknown processor biblatex"

[Eric S Fraga]

Colin,

I also only use the basics when writing articles.  With the new
org-cite, the closest I have is with the following settings, as an
example:

#+cite_export: natbib plain
#+latex_header: \usepackage[numbers,sort,super]{natbib}
#+bibliography: ~/[...]/bibliography.bib

This converts the simplest [cite:@author] to \citep{author}.  Natbib
settings need to be adjusted to your tastes/needs, of course.

In my org configuration, I have

#+begin_src emacs-lisp
  (require 'oc-basic)
  (require 'oc-csl)
  (require 'oc-natbib)
#+end_src 

to cover all the bases.

I have not been able to get away from using natbib for LaTeX export,
unfortunately.  A simple basic bibtex org-cite exporter would be
welcome, one that simply generates \cite{author} without any frills.

It's important to highlight that, to me, the advantage of org-cite, over
what I was using before with my own cite: link definition, is that
changing that first line to something like

#+cite_export: csl "[...]/acm-siggraph.csl"

lets me export the same document to ODT or text with the
citations.  It's not something I need often but I did in fact need it
just recently and was greatly welcome!

HTH,
eric

-- 
: Eric S Fraga via Emacs 28.0.60, Org release_9.5-30-g9e71df
: Latest paper written in org: https://arxiv.org/abs/2106.05096

Re: [BUG] Citations: exporting with csl crashes [9.5 (9.5-g0a86ad @ /home/quintus/.emacs.d/elpa/org-9.5/)]

[András Simonyi]

Dear Marvin,

thanks for the bug report! I was able to reproduce the issue and it
seems to be indeed a problem in citeproc-el -- I'll investigate and
respond to the citeproc-el ticket.

best wishes,
András

On Mon, 4 Oct 2021 at 19:29, Nicolas Goaziou  wrote:
>
> Hello,
>
> M. ‘quintus’ Gülker  writes:
>
> > Ah, I see. Thank you for the pointer. I created an issue ticket with a
> > copy of the OP here:
> > 
>
> Great! Thank you.
>
> Regards,
> --
> Nicolas Goaziou
>

Re: [PATCH] Re: New source block results option for attaching file to node

[Christopher M. Miles]

Ihor Radchenko  writes:

> Greg Minshall  writes:
>
>> i can imagine wanting to have input files and
>> output files in separate directories.  (for ease in "make clean", if for
>> no other conceptual reason.)  (but, probably i don't understand.)

I agree with this thought. We should separate two directories.

>
> Makes sense. Currently, there is :dir header arg to set working
> directory (aka input files directory). Maybe we can introduce something
> like :results-dir header arg to set the output directory? It's value can
> be a directory path or symbol 'attach.
>
> `:results file :results-dir 'attach` will be equivalent of
> `:results file attach` in the patch proposed by Ryan Scott.
>
> WDYT?

I agree with this idea. Use ~:results-dir 'attach~ is better.

Will the patch be updated?

>
> Best,
> Ihor



<#secure method=pgpmime mode=sign>
-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

Bare oc-csl author variants?

[Timothy]

Hi All,

I was recently citing something and wanted to mention the author and so tried
[cite/a/b:@] and was surprised to see it didn’t work. Looking at oc-csl.el I see
that we only define the following author variants:
• `a/c'
• `a/f'
• `a/cf'

Is there any reason why we haven’t added `a/b', `a/bc', `a/bf', `a/bcf' ?
>From a quick test, this seems to work as expected:
┌
│ (`(,(or "author" "a") . ,variant)
│  (pcase variant
│((or "caps" "b") '(:mode author-only :suppress-affixes t))
│((or "caps" "c") '(:mode author-only :capitalize-first t))
│((or "full" "f") '(:mode author-only :ignore-et-al t))
│((or "bare-caps" "bc") '(:mode author-only :suppress-affixes t 
:capitalize-first t))
│((or "bare-full" "bf") '(:mode author-only :suppress-affixes t 
:ignore-et-al t))
│((or "caps-full" "cf") '(:mode author-only :capitalize-first t 
:ignore-et-al t))
│((or "bare-caps-full" "bcf") '(:mode author-only :suppress-affixes t 
:capitalize-first t :ignore-et-al t))
│(_ '(:mode author-only
└

All the best,
Timothy

Re: [PATCH] Re: New source block results option for attaching file to node

[Ryan Scott]

I've been working through a few different approaches. What's shaping up is
something more general, having a special value for directory parameters
(i.e. 'attach) and auto-detection of link paths that are in the attachment
directory.
The latest iterations don't move any files around, so can't actually
enforce the output directory. That makes it safer overall as with my
initial patch if you were to return a path to something you *didn't* want
moved to your attachment directory you might get very surprising results.

I'll post a new patch with a different approach in a little bit.

On Mon, Oct 4, 2021 at 5:06 PM Christopher M. Miles 
wrote:

> Ihor Radchenko  writes:
>
> Greg Minshall  writes:
>>
>> i can imagine wanting to have input files and output files in separate
>>> directories. (for ease in "make clean", if for no other conceptual reason.)
>>> (but, probably i don't understand.)
>>>
>> I agree with this thought. We should separate two directories.
>
> Makes sense. Currently, there is :dir header arg to set working directory
>> (aka input files directory). Maybe we can introduce something like
>> :results-dir header arg to set the output directory? It's value can be a
>> directory path or symbol 'attach.
>>
>> `:results file :results-dir 'attach` will be equivalent of `:results file
>> attach` in the patch proposed by Ryan Scott.
>>
>> WDYT?
>>
> I agree with this idea. Use :results-dir 'attach is better.
>
> Will the patch be updated?
>
> Best, Ihor
>>
>
> <#secure method=pgpmime mode=sign>
> --
> [ stardiviner ]
>I try to make every word tell the meaning that I want to express.
>
>Blog: https://stardiviner.github.io/
>IRC(freenode): stardiviner, Matrix: stardiviner
>GPG: F09F650D7D674819892591401B5DF1C95AE89AC3
>

ox-latex-subfig

[edgar]

Hello nice people!

I just want to let you know about ox-latex-subfig, which you can find 
here: https://notabug.org/broncodev/ox-latex-subfig.git . It provides a 
filter to convert Org tables into "sub-figures" when exporting to (PDF) 
\LaTeX.


As you may know, the subcapiton package is deprecated, and I just like 
having figures side by side. I hope that it's useful to you as it is for 
me :) .


Thanks for Org! (you changed my life for the better).

-
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  

Table of contents position in HTML export

[Kodi Arfer]

When I export this file to HTML with `emacs -Q` and Org 9.5

#+TITLE: example document

text before headline

* headline!

after headline

the table of contents appears before "text before headline", although the manual says "Org 
normally inserts the table of contents directly before the first headline of the file". So shouldn't it 
be after "text before headline"? Or is it the manual that's wrong?

Re: Unable to follow gnus links

[Tom Ed White]

Ihor Radchenko  writes:

> Tom Ed White  writes:
>
>> I was able to fix the problem for the time being by changing the
>> arguments to:
>>
>> (defun org-gnus-open (path  _)
>>
>> The keystroke I use is C-c C-o, which runs org-open-at-point which is in
>> org.el.
>
> I understand. But it does not solve the potential problem for other users.
>
>> Debugger entered--Lisp error: (wrong-number-of-arguments (2 . 2) 1)
>> ... ((functionp (org-link-get-parameter type :follow)) (funcall
>> (org-link-get-parameter type :follow) path))
>> ...
>
> Judging from your backtrace, you seem to have a mixed Org installation
> with some files loaded from Org <9.4 (that's when we changed the number
> of arguments in :follow functions).
>
> Can you try to re-install Org?
>
> Note that mixed installation can also cause other unexpected problems.
>
> Best,
> Ihor

That was it, thank you. I was loading an obsolete version of
ol.el. Hopefully I've found and eliminated all obsolete org code.

Regards,
Tom Ed

Re: [PATCH] Fontification for inline src blocks

[Protesilaos Stavrou]

On 2021-10-03, 17:09 +0800, Ihor Radchenko  wrote:

> Timothy  writes:
>
>> Ihor Radchenko  writes:
>>
>>> Let me bump this thread again and mark it as a patch ;)
>>
>> Thanks for the bump. I'd like to get this working, but I don't know how best 
>> to
>> deal with the "prettification" of {{{results(=value=)}}}, which is the major 
>> blocker as I
>> see it.
>
> What about separating the src_{} fontification into separate patch? I
> think that part raised no objections.
>
> As for the results prettifications, I look at this and similar ideas as
> at Emacs themes.  It looks nice on your screenshot with your fonts and
> colours, but may not be good for other people.  Similar to org-bullets
> and co.
>
> I can see how some people (I am among those people) want to reduce the
> markup noise beyond hiding emphasis markers.  However, some people
> prefer not to hide text in buffer under "bells and whistles".  Maybe we
> can create some kind of "prettify-symbol themes" replacing different
> markup elements in bulk with nice symbols/svg (e.g. inline results,
> block headers/footers, uninteresting property drawers aka
> org-custom-properties, bullets, etc)?
> WDYT?
>
> Also, CCing Prot as it might be of interest for him.

Thank you!

I am monitoring the discussion in case there is something I would need
to do for my themes.  Otherwise I have no technical insight to offer
about the substance of this feature.

With regard to the use of faces, I generally find that re-purposing
faces in an altogether different context than their original can create
constraints for users/themes.  For example, and without having tried the
patch yet, we find this:[1]

(font-lock-append-text-property beg lang-end 'face 'org-block)

Is the text-to-be-propertised the same as an Org block or does it differ
in purpose/presentation?  Because a user/theme may like their blocks to
e.g. have no background of their own, but also wish to maintain a
distinct background colour for inline constructs like org-verbatim,
org-code, and those discussed here.  The rationale would be that blocks
are clear enough due to their innate spacing and indentation, whereas
inline constructs are surrounded by text.

This is not a hard requirement, of course, while too many overly
specific faces can also prove problematic for testing/maintenance.  Just
something for you to bear in mind.

Finally, how does the use of 'org-block' in this context relate to
'org-src-block-faces'?  Could there be undesired conflicts in styling or
whatnot?

All the best,
Prot

[1] 

-- 
Protesilaos Stavrou
https://protesilaos.com