Re: [BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Ihor Radchenko]

Daniel Ortmann  writes:

> Sometime during the past week I have been surprised by a sudden jump in
> load time when clocking into the first task in the agenda. Today, while
> tracking down that performance change, the problem "disappeared"! The
> first clockin behaved normally.
>
> But! Pressing 'R' in the daily agenda took a long time.
>
> I ran profile-start and then pressed R.
> Here are the cpu and memory reports.
> The memory report seems odd to me.
> Thoughts?
>
> 19250 58% + ...
> 13660 41% + command-execute
> 35 0% + timer-event-handler
>
> 3,754,109,912 99% + command-execute
> 168,717 0% + timer-event-handler
> 19,138 0% + redisplay_internal (C function)
> 0 0% ...

Thanks for reporting.

Could you please run the profiler again and then save the reports to
file using M-x profiler-report-write-profile?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Line breaks and brackets in LaTeX export

[Max Nikulin]

On 19/10/2022 10:57, Ihor Radchenko wrote:

Juan Manuel Macías writes:


Today I have tried with the latest version of tabularray (2022C, the one
I tried yesterday was 2022A, included in TeX Live 2022), and the bad
results persist. Also, it now returns a compile error when an \empty
precedes a \hline. I suspect this package does a pretty drastic
redefinition of \\. The [0pt] option still works fine here, though.


Then [0pt] should it be. At least for now, before we have a cleaner
solution.


It seems when I had a look into latex.ltx first time, I confused which 
branch is executed when length is less than or equal to zero and decided 
that it is the heavier \@xargarraycr. Actually \@yargarraycr do not 
really worry me, so degree of my objection concerning \\[0pt] 
significantly decreased.


\def\@argarraycr[#1]{%
  \ifnum0=`{\fi}${}\ifdim #1>\z@ \@xargarraycr{#1}\else
   \@yargarraycr{#1}\fi}

\def\@xargarraycr#1{\@tempdima #1\advance\@tempdima \dp \@arstrutbox
   \vrule \@height\z@ \@depth\@tempdima \@width\z@ \cr}
\def\@yargarraycr#1{\cr\noalign{\vskip #1}}

I have realized that

| / | <| > |
|   | a| b |
|   | @@latex:\noalign{\vskip 1em}@@ c | d |

is not a workaround to increase local interval between rows. It may 
cause disrupted vertical rules. Another recipe should be used:


| / | < | > |
|   | a | b @@latex:\rule[-1em]{0pt}{1em}@@ |
|   | c | d |

I believe that a more convenient way to override [0pt] to some other 
length for particular row should exist, but I have no idea which syntax 
should be used.


As to tabulararray, I still consider it as an experimental package. 
Perhaps I will install a more modern container. I am curious what code 
handles \\[0pt]. Likely I should read docs to get impression related to 
design goals and approaches to implement them. The bug tracker of the 
project looks like an appropriate place to ask a question concerning \\ 
variant safe for dumb exporters.


For a while I have the following question. Is \\{} have the same effect 
on tabularray parser as \\\empty?

Re: Haskell code blocks

[Thomas S. Dye]

Ihor Radchenko  writes:


"Thomas S. Dye"  writes:

Thanks Ihor.  I don't actually use Haskell.  Earlier this year 
I 
attempted to complete the Org Babel language documents on Worg, 
but couldn't get the obligatory "hello world" code block to 
behave 
in Haskell.  I'm guessing that ob-haskell.el actually works for 
experienced Haskell programmers and was hoping someone had a 
solution to the Prelude> problem.  I'm not sure when I might 
get 
back to this.


To clarify, it looks like Prelude Emacs is doing something wrong 
here.

Something that breaks haskell-mode and consequently ob-haskell.


I'm using Spacemacs.  Prelude is a standard module in Haskell.  I 
thought that might be the source.


Tom
--
Thomas S. Dye
https://tsdye.online/tsdye

Re: Haskell code blocks

[Ihor Radchenko]

"Thomas S. Dye"  writes:

> Thanks Ihor.  I don't actually use Haskell.  Earlier this year I 
> attempted to complete the Org Babel language documents on Worg, 
> but couldn't get the obligatory "hello world" code block to behave 
> in Haskell.  I'm guessing that ob-haskell.el actually works for 
> experienced Haskell programmers and was hoping someone had a 
> solution to the Prelude> problem.  I'm not sure when I might get 
> back to this.

To clarify, it looks like Prelude Emacs is doing something wrong here.
Something that breaks haskell-mode and consequently ob-haskell.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: [BUG] ob-scheme: geiser command has changed [9.6 (9.6-??-86c4635 @ /home/zilti/.emacs.d/.local/straight/build-27.2/org/)]

[Ihor Radchenko]

Daniel Ziltener  writes:

> The latest Geiser release 0.26 got rid of the "run-geiser" function. It
> is sufficient to just replace the call to "run-geiser" with "geiser"
> instead to make ob-scheme work again.

Thanks for reporting!
Can you try the attached (blind) patch?

>From 2565c66ed06e30885ee884d52eac824e23d55707 Mon Sep 17 00:00:00 2001
Message-Id: <2565c66ed06e30885ee884d52eac824e23d55707.1666153213.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 19 Oct 2022 12:18:00 +0800
Subject: [PATCH] ob-scheme: Use new function name `geiser' instead of
 deprecated `run-geiser'

* lisp/ob-scheme.el (geiser): Declare function.
(org-babel-scheme-get-repl): Use `geiser' when available.

Reported-by: Daniel Ziltener 
Link: https://orgmode.org/list/b0c62bc5-468a-31ce-2a42-c67c57117...@lyrion.ch
---
 lisp/ob-scheme.el | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/lisp/ob-scheme.el b/lisp/ob-scheme.el
index 8e3d48c32..00c50d63d 100644
--- a/lisp/ob-scheme.el
+++ b/lisp/ob-scheme.el
@@ -55,7 +55,11 @@ (defvar geiser-debug-jump-to-debug-p)  ; Defined in geiser-debug.el
 (defvar geiser-repl-use-other-window)  ; Defined in geiser-repl.el
 (defvar geiser-repl-window-allow-split)	; Defined in geiser-repl.el
 
+;; FIXME: `run-geiser' is obsolete since Geiser 0.26.  `geiser' is the
+;; new name.
 (declare-function run-geiser "ext:geiser-repl" (impl))
+(declare-function geiser "ext:geiser-repl" (impl))
+
 (declare-function geiser-mode "ext:geiser-mode" ())
 (declare-function geiser-eval-region "ext:geiser-mode"
   (start end &optional and-go raw nomsg))
@@ -120,7 +124,10 @@ (defun org-babel-scheme-get-repl (impl name)
   (let ((buffer (org-babel-scheme-get-session-buffer name)))
 (or buffer
 	(progn
-	  (run-geiser impl)
+  (if (fboundp 'geiser)
+  (geiser impl)
+;; FIXME: Obsolete since Geiser 0.26.
+	(run-geiser impl))
 	  (when name
 	(rename-buffer name t)
 	(org-babel-scheme-set-session-buffer name (current-buffer)))
-- 
2.35.1



-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Haskell code blocks

[Thomas S. Dye]

Thanks Ihor.  I don't actually use Haskell.  Earlier this year I 
attempted to complete the Org Babel language documents on Worg, 
but couldn't get the obligatory "hello world" code block to behave 
in Haskell.  I'm guessing that ob-haskell.el actually works for 
experienced Haskell programmers and was hoping someone had a 
solution to the Prelude> problem.  I'm not sure when I might get 
back to this.


All the best,
Tom

Ihor Radchenko  writes:


"Thomas S. Dye"  writes:


I'm struggling to write a minimal ob-doc-haskell.org for Worg.

I installed Haskell via Spacemacs (development branch) and the 
Haskell installation appears to be functioning correctly.


The obligatory Hello World! example yields bad results.

#+name: haskell-hello-world
#+begin_src haskell 
main :: IO () 
main = putStrLn  "Hello, World!"

main
#+end_src

#+RESULTS: haskell-hello-world
: Prelude> Hello, World!

I'm guessing the "Prelude>" part of the output is the prompt 
from 
the interpreter.


I found this in ob-haskell.el:

  (setq-local comint-prompt-regexp
  (concat haskell-prompt-regexp 
  "\\|^λ?> 
  "
  
But I couldn't find a way to modify haskell-prompt-regexp 
without 
changing the source.


Advice welcome.


I guess you can report this as a bug in Haskell-mode?
haskell-prompt-regexp is defined there.

If absolutely necessary and if you want that _your_ Haskell 
prompt is
different from Haskell-mode defaults, just setq 
haskell-prompt-regexp in

your config.



--
Thomas S. Dye
https://tsdye.online/tsdye

Re: links to orgcard.pdf and orgcard.txt are broken

[Ihor Radchenko]

Norwid Behrnd  writes:

> According to the digest of [2022-10-16 Sun], orgcard.txt and orgcard.pdf are
> thankfully again available online at
>
> https://orgmode.org/orgcard.txt
> https://orgmode.org/orgcard.pdf
>
> When comparing with an old print of the .pdf (about version 7.8.11 by 2012), I
> noticed the current .pdf explicitly states to refer to orgmode 9.5.5, while
> the .txt version does not.  At present, line 2 only reads
>
> ```
> Org Mode Reference Card (for version )
> ```

Confirmed.
Bastien?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Line breaks and brackets in LaTeX export

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> It is easy to change \\\empty constant to \\[0pt] if necessary. I have
>> no objection either way. Though I do not feel like we are in rush. I'd
>> like to hear from ox-latex maintainer.
>
> Today I have tried with the latest version of tabularray (2022C, the one
> I tried yesterday was 2022A, included in TeX Live 2022), and the bad
> results persist. Also, it now returns a compile error when an \empty
> precedes a \hline. I suspect this package does a pretty drastic
> redefinition of \\. The [0pt] option still works fine here, though.

Then [0pt] should it be. At least for now, before we have a cleaner
solution.

See the attached patch.

>From b060f63078d65758f8fd2ab7725fbcf8b2de0057 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Wed, 19 Oct 2022 11:48:26 +0800
Subject: [PATCH] org-latex-line-break-safe: Use safer value of "\\[0pt]"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ox-latex.el (org-latex-line-break-safe):
(org-latex-table-row):
Change \empty ending to explicit optional argument.  \empty still has
undesired side effects in some cases.

* testing/lisp/test-org-table.el (test-org-table/to-latex):
* testing/lisp/test-ox-latex.el (test-ox-latex/verse): Update tests.

Reported-by: Juan Manuel Macías 
Link: https://orgmode.org/list/87o7u9rz1a@posteo.net
---
 lisp/ox-latex.el   | 12 ++--
 testing/lisp/test-org-table.el |  6 +++---
 testing/lisp/test-ox-latex.el  | 12 ++--
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index dc8477d14..a5652fd78 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -278,17 +278,17 @@ (defconst org-latex-language-alist
 
 - `:lang-name' the actual name of the language.")
 
-(defconst org-latex-line-break-safe "\\empty"
+(defconst org-latex-line-break-safe "[0pt]"
   "Linebreak protecting the following [...].
 
-Without \"\\empty\" it would be interpreted as an optional argument to
+Without \"[0pt]\" it would be interpreted as an optional argument to
 the .
 
 This constant, for example, makes the below code not err:
 
 \\begin{tabular}{c|c}
-[t] & s\\empty
-[I] & A\\empty
+[t] & s[0pt]
+[I] & A[0pt]
 [m] & kg
 \\end{tabular}")
 
@@ -4005,9 +4005,9 @@ (defun org-latex-table-row (table-row contents info)
 			  (org-export-get-parent-table table-row) info
 	   (format "%s
 \\endfirsthead
-\\multicolumn{%d}{l}{%s} \\empty
+\\multicolumn{%d}{l}{%s} [0pt]
 %s
-%s \\empty\n
+%s [0pt]\n
 %s
 \\endhead
 %s\\multicolumn{%d}{r}{%s} 
diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el
index 722c37ea4..573179878 100644
--- a/testing/lisp/test-org-table.el
+++ b/testing/lisp/test-org-table.el
@@ -1635,11 +1635,11 @@ (ert-deftest test-org-table/to-generic ()
 (ert-deftest test-org-table/to-latex ()
   "Test `orgtbl-to-latex' specifications."
   (should
-   (equal "\\begin{tabular}{l}\na\\empty\n\\end{tabular}"
+   (equal "\\begin{tabular}{l}\na[0pt]\n\\end{tabular}"
 	  (orgtbl-to-latex (org-table-to-lisp "| a |") nil)))
   ;; Test :environment parameter.
   (should
-   (equal "\\begin{tabularx}{l}\na\\empty\n\\end{tabularx}"
+   (equal "\\begin{tabularx}{l}\na[0pt]\n\\end{tabularx}"
 	  (orgtbl-to-latex (org-table-to-lisp "| a |")
 			   '(:environment "tabularx"
   ;; Test :booktabs parameter.
@@ -1648,7 +1648,7 @@ (ert-deftest test-org-table/to-latex ()
 "\\toprule" (orgtbl-to-latex (org-table-to-lisp "| a |") '(:booktabs t
   ;; Handle LaTeX snippets.
   (should
-   (equal "\\begin{tabular}{l}\n\\(x\\)\\empty\n\\end{tabular}"
+   (equal "\\begin{tabular}{l}\n\\(x\\)[0pt]\n\\end{tabular}"
 	  (orgtbl-to-latex (org-table-to-lisp "| $x$ |") nil)))
   ;; Test pseudo objects and :raw parameter.
   (should
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 4fb9f2888..adb3a60ea 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -60,14 +60,14 @@ (ert-deftest test-ox-latex/verse ()
 (should
  (search-forward
   "\\begin{verse}
-lorem ipsum dolor\\empty
-lorem ipsum dolor\\empty
+lorem ipsum dolor[0pt]
+lorem ipsum dolor[0pt]
 \\vspace*{1em}
-lorem ipsum dolor\\empty
-lorem ipsum dolor\\empty
+lorem ipsum dolor[0pt]
+lorem ipsum dolor[0pt]
 \\vspace*{1em}
-lorem ipsum dolor\\empty
-lorem ipsum dolor\\empty
+lorem ipsum dolor[0pt]
+lorem ipsum dolor[0pt]
 \\end{verse}"
 
 (provide 'test-ox-latex)
-- 
2.35.1



-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: R code blocks in org version 9.5

[William Denton]

On 18 October 2022, Naresh Gurbuxani wrote:


Recently I started using org version 9.5 with my init.el that worked well for 
org 9.4

In org 9.5, I can run stand-alone R code blocks.  But when I try to run them in 
a session, emacs hangs.


I haven't had any problems like that, and I use R session code blocks pretty 
much every day.  Can you narrow it down any?  Does even the most basic block, 
just adding 1 + 1, not work?  What about with emacs -Q?



Bill

--
William Denton
https://www.miskatonic.org/
Librarian, artist and licensed private investigator.
Toronto, Canada

Re: A couple of `org-priority' fixes

[Ihor Radchenko]

Alex Giorev  writes:

> I found a couple of problems in org-priority, I think these patches fix
> them.

Thanks for the very clean patches and sorry for the late reply.

> - The first patch is truly minor, it just adds a bit to the docstring
> - The problem which prompted the second patch arises when all priorities
> are lowercase (you can test this by evaluating (setq org-priority-highest
> ?a org-priority-lowest ?z org-priority-default ?o) and then trying to set
> the priority to some lowercase letter)
> - The problem solved by the third patch arises when numerical priorities
> are used and 32 is given as the argument, 32 being the character code of
> the space character, because that character is used to signal property
> removal.

I have tested your patches using make test (see
https://orgmode.org/worg/org-contribute.html#first-patch) and it appears
that your patches break removing priority from a headline.

Can you please fix this issue?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Haskell code blocks

[Ihor Radchenko]

"Thomas S. Dye"  writes:

> I'm struggling to write a minimal ob-doc-haskell.org for Worg.
>
> I installed Haskell via Spacemacs (development branch) and the 
> Haskell installation appears to be functioning correctly.
>
> The obligatory Hello World! example yields bad results.
>
> #+name: haskell-hello-world
> #+begin_src haskell 
> main :: IO () 
> main = putStrLn  "Hello, World!"
> main
> #+end_src
>
> #+RESULTS: haskell-hello-world
> : Prelude> Hello, World!
>
> I'm guessing the "Prelude>" part of the output is the prompt from 
> the interpreter.
>
> I found this in ob-haskell.el:
>
>   (setq-local comint-prompt-regexp
>   (concat haskell-prompt-regexp "\\|^λ?> 
>   "
>   
> But I couldn't find a way to modify haskell-prompt-regexp without 
> changing the source.
>
> Advice welcome.

I guess you can report this as a bug in Haskell-mode?
haskell-prompt-regexp is defined there.

If absolutely necessary and if you want that _your_ Haskell prompt is
different from Haskell-mode defaults, just setq haskell-prompt-regexp in
your config.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

[PATCH] Bind calendar-debug-sexp to non-nil when running tests (was: problem with diary sexps)

[Ihor Radchenko]

Max Nikulin  writes:

>> More accurate error can be found after setting calendar-debug-sexp to t.
>> I got the following backtrace clearly indicating lexical scope issue:
>> 
>> Debugger entered--Lisp error: (void-variable entry)
>>(diary-float t 2 1)
>>(let ((entry "") (date '(4 5 2022))) (diary-float t 2 1))
>>(eval (let ((entry "") (date '(4 5 2022))) (diary-float t 2 1)) t)
>
> It looks like the source of the problem with unit tests that I faced 
> yesterday trying to look closer at the bug with daylight saving time in 
> agenda.

I guess we can permanently bind calendar-debug-sexp to non-nil in tests.
It should help if we encounter diary-related issues in future.

WDYT?

>From e86bbe12b79f9958fcd5ccf1586e9d9c829ee8c2 Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Wed, 19 Oct 2022 10:28:40 +0800
Subject: [PATCH] testing: Provide more debug info for diary sexps

* testing/org-test.el (org-test-run-batch-tests):
(org-test-run-all-tests): Bind `calendar-debug-sexp' to non-nil when
running tests.

See https://orgmode.org/list/t2hpe9$119m$1...@ciao.gmane.io
---
 testing/org-test.el | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/testing/org-test.el b/testing/org-test.el
index 9f7bab9ea..65d157bca 100644
--- a/testing/org-test.el
+++ b/testing/org-test.el
@@ -457,7 +457,9 @@ (defun org-test-run-batch-tests (&optional org-test-selector)
   (let ((org-id-track-globally t)
 	(org-test-selector
 	 (if org-test-selector org-test-selector "\\(org\\|ob\\)"))
-	org-confirm-babel-evaluate org-startup-folded vc-handled-backends)
+	org-confirm-babel-evaluate org-startup-folded vc-handled-backends
+;; Catch errors in diary sexps better.
+(calendar-debug-sexp t))
 (org-test-touch-all-examples)
 (org-test-update-id-locations)
 (org-test-load)
@@ -471,7 +473,9 @@ (defun org-test-run-all-tests ()
   (org-test-touch-all-examples)
   (org-test-update-id-locations)
   (org-test-load)
-  (ert "\\(org\\|ob\\)")
+  (let (;; Catch errors in diary sexps better.
+(calendar-debug-sexp t))
+(ert "\\(org\\|ob\\)"))
   (org-test-kill-all-examples))
 
 (defmacro org-test-at-time (time &rest body)
-- 
2.35.1



-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Bug: Org sentence commands and emphasis markers [9.3 (release_9.3 @ /usr/local/share/emacs/27.1/lisp/org/)]

[Ihor Radchenko]

Gustavo Barros  writes:

> There is some adverse interaction between Emacs sentence related 
> commands and Org emphasis markers, when whole sentences are emphasized. 
> This report describe some cases of this interaction, for your 
> consideration.  But, as a general rule, if a whole sentence is 
> emphasized, sentence movement and killing, and paragraph filling won't 
> work as expected.

Thanks for the detailed report.

We have had multiple similar reports, but yours also contains a nice set
of reproducers.

Confirmed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Bug: Texinfo export: Inline images are NOT rendered in INFO viewer [9.4.5 (release_9.4.5-354-g40b70c @ /home/rameshnedunchezian/src/org-mode/lisp/)]

[Ihor Radchenko]

Ramesh Nedunchezian  writes:

> Bug: Texinfo export: Inline images are NOT rendered in INFO viewer
> [9.4.5 (release_9.4.5-354-g40b70c @ 
> /home/rameshnedunchezian/src/org-mode/lisp/)]
>
>
> 1. Unzip the attached zip file.
> 2. C-x C-f doc/helm.org.  Note that it has inline image.
> 3. C-u C-h i doc/helm.info and rename the buffer. Note that it doesn't
>display the inline image.
> 4. C-u C-h i doc/helm-1.info and rename the buffer.  Note that it DOES
>display the inline image.
>
> See the attached screenshot for what the above steps looks like.
>
> (3) above is a bug.  (4) above is after applying the remedy.
>
> You can do a
>
> ./helm.sh
>
> to recreate the above texi files.  This file also has additional
> observations.
>
> TLDR: The presence of leading "./" in texi file's `@image ...'
> creates the problem.

Sorry for the late reply.
I am unable to reproduce on the latest main.

Re: observations.

## Observation 1: according to
##
## (info "(texinfo) Image Syntax")
##
## Here is the synopsis of the '@image' command:
##  @image{FILENAME[, WIDTH[, HEIGHT[, ALTTEXT[, EXTENSION}
##
## For Info and HTML output, 'makeinfo' uses the optional fifth
## argument EXTENSION to '@image' for the filename extension, if it is
## specified and the file is found.  Any leading period should be
## included in EXTENSION.  For example:
##
##  @image{foo.xpm}
##
##
## So, just to be on the safe side, it would be a good idea to add a dot to
## the image extension.

According to 9.2.1 Image Syntax,

   In Info output, 'makeinfo' writes a reference to the binary image
file (trying FILENAME suffixed with 'EXTENSION', '.EXTENSION', '.png',
or '.jpg', in that order) if one exists.  It also literally includes the
'.txt' file if one exists.  This way, Info readers which can display
images (such as the Emacs Info browser, running under X) can do so,
whereas Info readers which can only use text (such as the standalone
Info reader) can display the textual version.

Dot is unnecessary.

## Observation 2: Why is the caption getting stripped in the output file?

Because texinfo captions cannot have verbatim inside unless you also
provide shortcaption. This is a limitation of texinfo. Not Org.
If you have any ideas how to better deal with these limitations, please
share them.

## Observaion 3: Anyway to take care of the warnings that texi2html
## generates.  Can the CAPTION text be used as an alt text, when there
## is no alt text?

I see no warnings on my side running ./helm.sh

For alt text, won't doing so duplicate the caption and text displayed in
place of the figure?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Problems running ob-julia tests (testing/test-ob-julia.el)

[Ihor Radchenko]

Pedro Bruel  writes:

> I believe the ob-julia version we have on orgmode does not support sessions.

There is definitely session support in lisp/ob-julia.el. ob-julia does
define org-babel-load-session:julia and org-babel-prep-session:julia.

Session support is even tested in testing/lisp/test-ob-julia.el
For example, in test-ob-julia/session-multiline.

ob-julia documentation also declares full session support:
https://orgmode.org/worg/org-contrib/babel/languages/ob-doc-julia.html

For context, Christian is helping us to setup automatic CI tests for Org
and we are now experiencing some issues with tests for babel languages.
Those tests are normally disabled as they require external packages,
which is why the problem was not noticed in the past.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Problems running ob-julia tests (testing/test-ob-julia.el)

[Pedro Bruel]

Hi,

Could you please share which versions of julia, emacs, and orgmode you are
running?
I believe the ob-julia version we have on orgmode does not support sessions.

Thanks,
Pedro

On Mon, Oct 17, 2022 at 9:45 PM Ihor Radchenko  wrote:

> [CCing the maintainer]
>
> Ihor Radchenko  writes:
>
> > Christian Köstlin  writes:
> >
> >> I am trying to run the ob-julia tests but `make test` is prompting me
> >> for a project folder. Has anybody the tests (or the ob-julia setup) in
> >> a working state? (Simple ob-julia evaluations (without session) do
> >> work for me).
> >
> > Some more data.
> >
> > I just tried to run test-ob-julia/colnames-yes-header-argument
> > interactively and the test fails. Trying to execute example source block
> > raises the following error:
> >
> > ERROR: syntax: cannot juxtapose string literal
>
> Pedro, could you please take a look
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

R code blocks in org version 9.5

[Naresh Gurbuxani]

Recently I started using org version 9.5 with my init.el that worked well for 
org 9.4

In org 9.5, I can run stand-alone R code blocks.  But when I try to run them in 
a session, emacs hangs.

Have you seen this problem? Is there a solution?

Thanks,
Naresh

Sent from my iPhone

[BUG] recent slow down in agenda's clock table report (and with first clock-in) [9.6-pre (release_9.5.5-995-g4b9aef @ /home/dortmann/src/git-org-mode/lisp/)]

[Daniel Ortmann]

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.


Sometime during the past week I have been surprised by a sudden jump in
load time when clocking into the first task in the agenda. Today, while
tracking down that performance change, the problem "disappeared"! The
first clockin behaved normally.

But! Pressing 'R' in the daily agenda took a long time.

I ran profile-start and then pressed R.
Here are the cpu and memory reports.
The memory report seems odd to me.
Thoughts?

19250 58% + ...
13660 41% + command-execute
35 0% + timer-event-handler

3,754,109,912 99% + command-execute
168,717 0% + timer-event-handler
19,138 0% + redisplay_internal (C function)
0 0% ...


Emacs : GNU Emacs 29.0.50 (build 66, x86_64-pc-linux-gnu, GTK+ Version 
3.22.30, cairo version 1.15.12)

of 2022-10-18
Package: Org mode version 9.6-pre (release_9.5.5-995-g4b9aef @ 
/home/dortmann/src/git-org-mode/lisp/)

[BUG] ob-scheme: geiser command has changed [9.6 (9.6-??-86c4635 @ /home/zilti/.emacs.d/.local/straight/build-27.2/org/)]

[Daniel Ziltener]

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.


The latest Geiser release 0.26 got rid of the "run-geiser" function. It
is sufficient to just replace the call to "run-geiser" with "geiser"
instead to make ob-scheme work again.

Emacs : GNU Emacs 27.2 (build 1, x86_64-suse-linux-gnu, GTK+ Version 
3.24.31, cairo version 1.16.0)
Package: Org mode version 9.6 (9.6-??-86c4635 @ 
/home/zilti/.emacs.d/.local/straight/build-27.2/org/)


current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

org-fontify-whole-heading-line t
org-capture-prepare-finalize-hook '(org-roam-capture--install-finalize-h)
org-link-shell-confirm-function 'yes-or-no-p
org-mode-local-vars-hook '(+indent-guides-disable-maybe-h +org-init-gifs-h)
org-babel-after-execute-hook 
'(+org-redisplay-inline-images-in-babel-result-h)

org-insert-heading-respect-content t
org-after-refile-insert-hook '(save-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-roam-log-setup-hook '(org-roam--register-completion-functions-h)
org-follow-link-hook '(+nav-flash-delayed-blink-cursor-h)
org-roam-db-node-include-function '(closure (t) nil t)
org-persist-directory "/home/zilti/.emacs.d/.local/cacheorg/persist/"
org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel . 3))
org-html-format-inlinetask-function 
'org-html-format-inlinetask-default-function

org-enforce-todo-dependencies t
org-odt-format-headline-function 'org-odt-format-headline-default-function
org-special-ctrl-a/e t
org-imenu-depth 6
org-persist-before-write-hook '(org-element--cache-persist-before-write)
org-agenda-files '("~/org/")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-reveal-start-hook '(org-decrypt-entry)
org-modules '(ol-bibtex)
org-startup-folded nil
org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
org-log-buffer-setup-hook '(org-roam-log--setup)
org-mode-hook '(er/add-org-mode-expansions 
+lookup--init-org-mode-handlers-h

(closure ((hook . org-mode-hook) (--dolist-tail--) t) (&rest _)
(add-hook 'before-save-hook 'org-encrypt-entries nil t))
(closure
(org--rds reftex-docstruct-symbol org--single-lines-list-is-paragraph 
org-element-greater-elements
visual-fill-column-width org-clock-history org-agenda-current-date 
org-with-time org-defdecode org-def
org-read-date-inactive org-ans2 org-ans1 
org-columns-current-fmt-compiled org-clock-current-task org-clock-effort
org-agenda-skip-function org-agenda-skip-comment-trees 
org-agenda-archives-mode org-end-time-was-given
org-time-was-given org-log-note-extra org-log-note-purpose 
org-log-post-message org-last-inserted-timestamp
org-last-changed-timestamp org-entry-property-inherited-from 
org-blocked-by-checkboxes org-state
org-agenda-headline-snapshot-before-repeat org-agenda-buffer-name 
org-agenda-start-on-weekday
org-agenda-buffer-tmp-name org-priority-regexp org-mode-abbrev-table 
org-mode-syntax-table org-element-use-cache
org-element-cache-persistent buffer-face-mode-face org-tbl-menu 
org-org-menu org-struct-menu org-entities
org-last-state org-id-track-globally org-clock-start-time texmathp-why 
remember-data-file
org-agenda-tags-todo-honor-ignore-options iswitchb-temp-buflist 
align-mode-rules-list org-emphasis-alist
org-emphasis-regexp-components org-export-registered-backends 
crm-separator org-babel-load-languages
org-id-overriding-file-name org-indent-indentation-per-level 
org-element--timestamp-regexp
org-element-cache-map-continue-from org-element-paragraph-separate 
org-agenda-buffer-name

org-inlinetask-min-level t)
nil (add-hook 'change-major-mode-hook 'org-fold-show-all 'append 'local))
(closure
(org-src-window-setup *this* org-babel-confirm-evaluate-answer-no 
org-babel-tangle-uncomment-comments
org-src-preserve-indentation org-src-lang-modes 
org-edit-src-content-indentation org-babel-library-of-babel t)
nil (add-hook 'change-major-mode-hook #'org-babel-show-result-all 
'append 'local))

org-babel-result-hide-spec org-babel-hide-all-hashes
(closure
(org-agenda-skip-regexp org-fold-core-style org-table1-hline-regexp 
org-table-tab-recognizes-table\.el
org-table-dataline-regexp org-table-any-border-regexp 
org-agenda-restriction-lock-overlay
org-agenda-overriding-restriction org-agenda-diary-file 
org-complex-heading-regexp calendar-mode-map t)

nil (setq imenu-create-index-function 'org-imenu-get-tree))
doom-disable-show-paren-mode-h doom-disable-show-trailing-whitespace-h 
+org-enable-auto-reformat-tables-h
+org-enable-auto-update-cookies-h +org-make-last-point-visible-h 
evil-org-mode toc-org-enable writegood-mode

flyspell-mode embrace-org-mode-hook org-eldoc-load)
org-clock-persist 'history

Re: [PATCH] Unit-test for Please add support for dlangs packagemanager to ob-C.el

[tbanelwebmin]

  
  
For unit-testing Dlang, we could mock the
  «dub» command (compiler+packager). For instance, we could replace
  it by the «cat» Linux command, just while running the unit-test.
  
  But the «cat» command introduces a new dependency on Linux. Is
  there a portable equivalent for «cat»?
  
  

On 10/2/22
09:29, Ihor Radchenko wrote:
  

  Max Nikulin  writes:


  
I am unsure concerning general policy related to org-babel test, so the 
following is rather discussion than a direct request to change the test.

Is there a way to avoid dependency on remote resources? My concern is 
test results affected by network issues. In addition, more required 3rd 
party tools means less probability that a developer after modification 
of generic babel code noticed that the changes break D backend because 
missing tool on the development machine. I have no idea how much efforts 
is required to create a mock for isolated environment.

  
  
Tests must not rely on remote resources.
However, it does not mean that we cannot test remote resources in Org
tests. One simply needs to mock the url-retrieve or whatever function is
used to retrieve remove resource.


  
Another point is that missed dub binary is not reflected in test report. 
If `skip-unless' feature of ert is available in Emacs-26 then it should 
be used.

  
  
The current approach to optional binaries is throwing
'missing-test-dependency error when the binary is not available.





  

Re: [PATCH] Add light argument to org-babel-lob-get-info

[Ferdinand Pieper]

Ihor Radchenko  writes:

> I'd prefer to change LIGHT to NO-EVAL, including in
> org-babel-get-src-block-info. Changing argument name in function does
> not affect its caller in any way. Just need to update the function body
> and docstring carefully.
>
> NO-EVAL is already used by org-babel-parse-header-arguments and
> org-babel-params-from-properties.

I also prefer the NO-EVAL naming. I updated the patch to use no-eval and also 
added a second patch to rename the light argument of 
org-babel-get-src-block-info and all its occurrences (I changed the 'light to 
'no-eval in all its calls only for consistency and future proofing reasons, 
altough it is unnecessary right now). Feel free to squash them into one commit. 
I was not sure wether one or two commits would be preferred.

> May I know if you are proposing this for a specific purpose?

Thanks for asking. I use it in a function that creates quasi unique names 
similar to org-babel-temp-file. But instead of random names it uses the source 
block content and header info to create a unique hash. This makes it very easy 
to create unique but from call to call consistent filenames in header 
arguments, when you don't want to worry about the filename, but also don't want 
to clutter your result directory (especially if its not /tmp) or care about 
constant filenames, e.g. for linking. Without the no-eval/light argument the 
hash generation gets stuck in a recursive loop. I attached the functions for 
reference.
If there is wider interest in this, these could be added to org either as a 
variant of org-babel-temp-file or as an extension.

>From 22edd4f3a9382eb3dca5558b13053cba6fedf7ce Mon Sep 17 00:00:00 2001
From: fpi 
Date: Tue, 18 Oct 2022 17:27:54 +0200
Subject: [PATCH 1/2] org-babel-lob-get-info: Add no-eval argument

* lisp/ob-lob.el (org-babel-lob-get-info): Add no-eval argument to
prevent recursive evaluation of lisp values in parameters.
---
 lisp/ob-exp.el |  2 +-
 lisp/ob-lob.el | 13 +
 lisp/ob-ref.el |  2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el
index de7e1e3a3..67ed22f84 100644
--- a/lisp/ob-exp.el
+++ b/lisp/ob-exp.el
@@ -29,7 +29,7 @@
 
 (require 'ob-core)
 
-(declare-function org-babel-lob-get-info "ob-lob" (&optional datum))
+(declare-function org-babel-lob-get-info "ob-lob" (&optional datum no-eval))
 (declare-function org-element-at-point "org-element" (&optional pom cached-only))
 (declare-function org-element-context "org-element" (&optional element))
 (declare-function org-element-property "org-element" (property element))
diff --git a/lisp/ob-lob.el b/lisp/ob-lob.el
index c6be8be80..10822accb 100644
--- a/lisp/ob-lob.el
+++ b/lisp/ob-lob.el
@@ -119,10 +119,15 @@ after REF in the Library of Babel."
 	(cdr (assoc-string ref org-babel-library-of-babel
 
 ;;;###autoload
-(defun org-babel-lob-get-info (&optional datum)
+(defun org-babel-lob-get-info (&optional datum no-eval)
   "Return internal representation for Library of Babel function call.
 
 Consider DATUM, when provided, or element at point otherwise.
+ 
+When optional argument NO-EVAL is non-nil, Babel does not resolve
+remote variable references; a process which could likely result
+in the execution of other code blocks, and do not evaluate Lisp
+values in parameters.
 
 Return nil when not on an appropriate location.  Otherwise return
 a list compatible with `org-babel-get-src-block-info', which
@@ -144,16 +149,16 @@ see."
 			org-babel-default-lob-header-args
 			(append
 			 (org-with-point-at begin
-			   (org-babel-params-from-properties language))
+			   (org-babel-params-from-properties language no-eval))
 			 (list
 			  (org-babel-parse-header-arguments
-			   (org-element-property :inside-header context))
+			   (org-element-property :inside-header context) no-eval)
 			  (let ((args (org-element-property :arguments context)))
 			(and args
  (mapcar (lambda (ref) (cons :var ref))
 	 (org-babel-ref-split-args args
 			  (org-babel-parse-header-arguments
-			   (org-element-property :end-header context)
+			   (org-element-property :end-header context) no-eval
 		 nil
 		 (org-element-property :name context)
 		 begin
diff --git a/lisp/ob-ref.el b/lisp/ob-ref.el
index 2b4a16aea..2bba2071e 100644
--- a/lisp/ob-ref.el
+++ b/lisp/ob-ref.el
@@ -57,7 +57,7 @@
 (require 'org-macs)
 (require 'cl-lib)
 
-(declare-function org-babel-lob-get-info "ob-lob" (&optional datum))
+(declare-function org-babel-lob-get-info "ob-lob" (&optional datum no-eval))
 (declare-function org-element-at-point "org-element" (&optional pom cached-only))
 (declare-function org-element-property "org-element" (property element))
 (declare-function org-element-type "org-element" (element))
-- 
2.20.1

>From 015ce9ef56c997331ea34957d47fa98efffb54a3 Mon Sep 17 00:00:00 2001
From: fpi 
Date: Tue, 18 Oct 2022 17:34:18 +0200
Subject: [PATCH 2/2] org-babel-get-src-block-info: Rename light argument

* lisp/ob-c

Re: org-agenda-tag-filter-preset: maybe a recent bug?

[Garjola Dindi]

On Tue 18-Oct-2022 at 05:39:27 +02, Liu Hui 
wrote: 
> Hi Garjola,
>
> The preset of filter is not supposed to be used with individual
> command. The docstring of 'org-agenda-tag-filter-preset' says:
>
>> The preset filter is a global property of the entire agenda view. In
>> a block agenda, it will not work reliably to define a filter for one
>> of the individual blocks. You need to set it in the global options
>> and expect it to be applied to the entire view.
>
> So you just need to preset the filter in the global options, e.g.
>
>   ;; multi-block view
>   ("W" "Work Daily Action List"
>((agenda ""))
>((org-agenda-tag-filter-preset
>  (quote
>   ("+work")
>
> or
>
>   ("W" "Work Daily Action List"
>agenda ""
>((org-agenda-tag-filter-preset
>  (quote
>   ("+work")

Hi Liu,

Thank you very much for your answer. It seems that I have been using
wrong agenda custom commands for several years!

In any case, your suggestion solved my problem and I am back on the main
branch. 

Thank you.

Garjola


-- 

Re: links to orgcard.pdf and orgcard.txt are broken

[Norwid Behrnd]

According to the digest of [2022-10-16 Sun], orgcard.txt and orgcard.pdf are
thankfully again available online at

https://orgmode.org/orgcard.txt
https://orgmode.org/orgcard.pdf

When comparing with an old print of the .pdf (about version 7.8.11 by 2012), I
noticed the current .pdf explicitly states to refer to orgmode 9.5.5, while
the .txt version does not.  At present, line 2 only reads

```
Org Mode Reference Card (for version )
```

Between 2012 and 2022, orgmode changed some chords e.g., substituted `

Re: [BUG] columnview cannot deal with more than 100 headings [N/A (N/A @ /home/oub/emacs/site-lisp/packages/org/)]

[Uwe Brauer]

>>> "IR" == Ihor Radchenko  writes:

> Uwe Brauer  writes:
>> I attach a file that hopefully explains the problem.
>> 
>> That file contains 109 heading, each heading has 17 different properties 
>> when all of them are included in the 
>> #+BEGIN: columnview
>> #+END:
>> 
>> Block then not all headings are included. It seems to work with 15 
>> properties but not for all 17.

> I tried your file on the latest main, but I do not see anything
> obviously wrong. Could you please clarify what you expect to see?

I had the time to check my document which contains now 140 entries, it
worked like charm very fast and produced the right table out of the box.

Thanks, so that seems fix, if I find something strange I report back,

Thanks 

-- 
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military. 
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine. 


smime.p7s
Description: S/MIME cryptographic signature

Re: Line breaks and brackets in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

>> Assuming that there is currently no alternative to the non-selective
>> solution, and that, as you say, the presence of brackets may be more
>> common than I initially expected, if I had to choose between \empty and
>> [0pt], I would say that [0pt] is the safest, as it is an expected
>> argument to \\ and equals the default space. I can't think of any
>> unexpected results from this, but of course, it also depends on there
>> being no package redefining \\ with another argument structure on its
>> own. I think it would be a bad idea for a package developer, but LaTeX
>> (and the LaTeX packages) is horribly unpredictable.
>
> It is easy to change \\\empty constant to \\[0pt] if necessary. I have
> no objection either way. Though I do not feel like we are in rush. I'd
> like to hear from ox-latex maintainer.

Today I have tried with the latest version of tabularray (2022C, the one
I tried yesterday was 2022A, included in TeX Live 2022), and the bad
results persist. Also, it now returns a compile error when an \empty
precedes a \hline. I suspect this package does a pretty drastic
redefinition of \\. The [0pt] option still works fine here, though.

Re: Fwd: org-priority: allow customization of priority indicator

[Ihor Radchenko]

drlkf  writes:

> I would like to submit a patch to allow users to change the priority
> tag's form entirely. While it has been working for my use-case i.e
> basic operations inside org buffers and org-agenda, it is not perfect
> and there are some bugs that remain when using more advanced features
> with different tag forms (mine is `_p' where `p' is `[1-9]'), that I am
> not competent enough to solve. However I believe there are no breaking
> changes if the user does not modify said tag form. If there's any
> precision I can add, please let me know.

Thanks for the patch!

In general, we do not intend to support changing basic elements of Org
syntax. So, things like your _p may remain buggy because they clash with
underscore emphasis.

However, your patch is anyway useful because it makes the Org code
cleaner and more modular. A side effect that users will be able to
change the syntax at their own risk can also be considered as somewhat
odd feature (apparently useful for you at least).

As a general feedback to the patch, I suggest moving the old and new
priority variables into org-element.el and change them to defconst
(Elisp still allows altering defconsts). When moving, rename them to use
org-element-* prefix, but keep old existing variables under defvaralias.

More comments below.

> Subject: [PATCH] org-priority: allow customization of priority indicator
>
> * org.el (org-priority): Allow the user to set the prefix and suffix
> of the priority indicator so that it have a completely different form
> for them (e.g _A instead of [#A]).

Please word the patch more along the lines of "Refactor priority
syntax". Org maintainers are not going to take an extra burden of
resolving bugs coming from arbitrary changes in property syntax.

> -  (when (string-match "\\[#\\([A-Z0-9]\\)\\] ?" tmp)
> - (plist-put props 'priority-letter (match-string 1 tmp))
> +  (when (string-match org-priority-regexp tmp)
> + (plist-put props 'priority-letter (match-string 3 tmp))

Do note that org-priority-regexp is not the same with the old regexp.
Maybe we can introduce something like org-element-priority-regexp that
does not do match groups. Just "[\\[#[A-Z0-9]+\\][ \t]*". Then, you can use it
here instead of employing costly lazy matching in analytic
org-priority-regexp.

> -(priority (and (looking-at "\\[#.\\][ \t]*")
> +(priority (and (looking-at (format "%s.%s[ \t]*"
> +  (regexp-quote 
> org-priority-prefix)
> +  (regexp-quote 
> org-priority-prefix)))

Better use org-element-priority-regexp as above.

> -(priority (and (looking-at "\\[#.\\][ \t]*")
> +(priority (and (looking-at (format "%s.%s[ \t]*"
> +  (regexp-quote 
> org-priority-prefix)
> +  (regexp-quote 
> org-priority-prefix)))
> (progn (goto-char (match-end 0))
>(aref (match-string 0) 2

same

> -   "\\(?: +\\(\\[#.\\]\\)\\)?"
> +   (format "\\(?: +\\(%s.%s\\)\\)?"
> +  (regexp-quote org-priority-prefix)
> +  (regexp-quote org-priority-suffix))
> "\\(?: +\\(.*?\\)\\)??"
> "\\(?:[ \t]+\\(:[[:alnum:]_@#%:]+:\\)\\)?"
> "[ \t]*$")
> org-complex-heading-regexp-format
> (concat "^\\(\\*+\\)"
> "\\(?: +" org-todo-regexp "\\)?"
> -   "\\(?: +\\(\\[#.\\]\\)\\)?"
> +   (format "\\(?: +\\(%s.%s\\)\\)?"
> +  (regexp-quote org-priority-prefix)
> +  (regexp-quote org-priority-suffix))

same

> "\\(?: +"
> ;; Stats cookies can be stuck to body.
> "\\(?:\\[[0-9%%/]+\\] *\\)*"
> @@ -5764,8 +5768,10 @@ needs to be inserted at a specific position in the 
> font-lock sequence.")
> '(org-activate-code (1 'org-code t))
> ;; COMMENT
> (list (format
> -  "^\\*+\\(?: +%s\\)?\\(?: +\\[#[A-Z0-9]\\]\\)? 
> +\\(?9:%s\\)\\(?: \\|$\\)"
> +  "^\\*+\\(?: +%s\\)?\\(?: +%s[A-Z0-9]%s\\)? +\\(?9:%s\\)\\(?: 
> \\|$\\)"
>org-todo-regexp
> +  (regexp-quote org-priority-prefix)
> +  (regexp-quote org-priority-suffix)

same

>   Priorities
>  
> +(defvar org-priority-prefix "[#"
> +  "Prefix to insert before a priority value to form the priority indicator.
> +It should be matched in accordance by `org-priority-regexp' in order
> +for priorities to work both-ways (inserting and extracting).")
> +
> +(defvar org-priority-suffix "]"
> +  "Suffix to insert after a priority value to end the priority indicator.
> +It should be matched in accordance by `org-priority-regexp' in order
> +for priorities to work 

Fwd: org-priority: allow customization of priority indicator

[drlkf]

Hello,

I would like to submit a patch to allow users to change the priority
tag's form entirely. While it has been working for my use-case i.e
basic operations inside org buffers and org-agenda, it is not perfect
and there are some bugs that remain when using more advanced features
with different tag forms (mine is `_p' where `p' is `[1-9]'), that I am
not competent enough to solve. However I believe there are no breaking
changes if the user does not modify said tag form. If there's any
precision I can add, please let me know.

>From 94117daef8fec4e214d9973a17c2ae4baba1d761 Mon Sep 17 00:00:00 2001
From: drlkf 
Date: Thu, 9 Jun 2022 03:19:00 +0200
Subject: [PATCH] org-priority: allow customization of priority indicator

* org.el (org-priority): Allow the user to set the prefix and suffix
of the priority indicator so that it have a completely different form
for them (e.g _A instead of [#A]).
---
 org-agenda.el  |  4 ++--
 org-element.el |  8 ++--
 org.el | 40 
 3 files changed, 40 insertions(+), 12 deletions(-)

diff --git a/org-agenda.el b/org-agenda.el
index 71aac271f..cbbe5e4c6 100644
--- a/org-agenda.el
+++ b/org-agenda.el
@@ -3431,8 +3431,8 @@ This ensures the export commands can easily use it."
   (setq props (plist-put props 'day tmp))
   (setq props (plist-put props 'agenda-day tmp)))
 (when (setq tmp (plist-get props 'txt))
-  (when (string-match "\\[#\\([A-Z0-9]\\)\\] ?" tmp)
-	(plist-put props 'priority-letter (match-string 1 tmp))
+  (when (string-match org-priority-regexp tmp)
+	(plist-put props 'priority-letter (match-string 3 tmp))
 	(setq tmp (replace-match "" t t tmp)))
   (when (and (setq re (plist-get props 'org-todo-regexp))
 		 (setq re (concat "\\`\\.*" re " ?"))
diff --git a/org-element.el b/org-element.el
index 9db1406b3..2047e202b 100644
--- a/org-element.el
+++ b/org-element.el
@@ -1009,7 +1009,9 @@ Assume point is at beginning of the headline."
 			 (match-string 1
 	   (todo-type
 	(and todo (if (member todo org-done-keywords) 'done 'todo)))
-	   (priority (and (looking-at "\\[#.\\][ \t]*")
+	   (priority (and (looking-at (format "%s.%s[ \t]*"
+  (regexp-quote org-priority-prefix)
+  (regexp-quote org-priority-prefix)))
 			  (progn (goto-char (match-end 0))
  (aref (match-string 0) 2
 	   (commentedp
@@ -1158,7 +1160,9 @@ Assume point is at beginning of the inline task."
 			 (match-string 0
 	   (todo-type (and todo
 			   (if (member todo org-done-keywords) 'done 'todo)))
-	   (priority (and (looking-at "\\[#.\\][ \t]*")
+	   (priority (and (looking-at (format "%s.%s[ \t]*"
+  (regexp-quote org-priority-prefix)
+  (regexp-quote org-priority-prefix)))
 			  (progn (goto-char (match-end 0))
  (aref (match-string 0) 2
 	   (title-start (point))
diff --git a/org.el b/org.el
index 06af12339..648eb840a 100644
--- a/org.el
+++ b/org.el
@@ -4468,14 +4468,18 @@ related expressions."
 	  org-complex-heading-regexp
 	  (concat "^\\(\\*+\\)"
 		  "\\(?: +" org-todo-regexp "\\)?"
-		  "\\(?: +\\(\\[#.\\]\\)\\)?"
+		  (format "\\(?: +\\(%s.%s\\)\\)?"
+  (regexp-quote org-priority-prefix)
+  (regexp-quote org-priority-suffix))
 		  "\\(?: +\\(.*?\\)\\)??"
 		  "\\(?:[ \t]+\\(:[[:alnum:]_@#%:]+:\\)\\)?"
 		  "[ \t]*$")
 	  org-complex-heading-regexp-format
 	  (concat "^\\(\\*+\\)"
 		  "\\(?: +" org-todo-regexp "\\)?"
-		  "\\(?: +\\(\\[#.\\]\\)\\)?"
+		  (format "\\(?: +\\(%s.%s\\)\\)?"
+  (regexp-quote org-priority-prefix)
+  (regexp-quote org-priority-suffix))
 		  "\\(?: +"
 		  ;; Stats cookies can be stuck to body.
 		  "\\(?:\\[[0-9%%/]+\\] *\\)*"
@@ -5764,8 +5768,10 @@ needs to be inserted at a specific position in the font-lock sequence.")
 	  '(org-activate-code (1 'org-code t))
 	  ;; COMMENT
 	  (list (format
-		 "^\\*+\\(?: +%s\\)?\\(?: +\\[#[A-Z0-9]\\]\\)? +\\(?9:%s\\)\\(?: \\|$\\)"
+		 "^\\*+\\(?: +%s\\)?\\(?: +%s[A-Z0-9]%s\\)? +\\(?9:%s\\)\\(?: \\|$\\)"
 		 org-todo-regexp
+		 (regexp-quote org-priority-prefix)
+		 (regexp-quote org-priority-suffix)
 		 org-comment-string)
 		'(9 'org-special-keyword t))
 	  ;; Blocks and meta lines
@@ -7144,7 +7150,7 @@ This is a list with the following elements:
   (list (length (match-string 1))
 	(org-reduced-level (length (match-string 1)))
 	(match-string-no-properties 2)
-	(and (match-end 3) (aref (match-string 3) 2))
+	(and (match-end 3) (aref (match-string 3) (length org-priority-prefix)))
 	(match-string-no-properties 4)
 	(match-string-no-properties 5)
 
@@ -11269,13 +11275,29 @@ from the `before-change-functions' in the current buffer."
 
 ;;;

Re: Verse block and separations

[Juan Manuel Macías]

Ihor Radchenko writes:

>> In my init I have redefined the verse block like this, so that there is
>> a white line between stanzas, not \vspace (I have also added some things
>> for the verse package, so that the numbering of verses is not broken).
>> So your example would produce a white line under \begin{verse}, not the
>> current \vspace, which would be irrelevant to LaTeX. But this is only a
>> hack:
>
> Could you provide a patch?

Sorry, I missed this message...

Sure, I think by the end of this week I'll be able to prepare a patch. I
put it on the agenda.

Re: [BUG] EXPORT_FILE_NAME keyword is used by `org-export-output-file-name' before macro expansion/INCLUDEs/removing COMMENTed trees (was: Confused about what the COMMENT keyword means)

[Alain . Cochard]

alain.coch...@unistra.fr writes on Tue 11 Oct 2022 16:42:
 > Ihor Radchenko writes on Sun  2 Oct 2022 12:48:
 > 
 >  > I recommend you to use :EXPORT_FILE_NAME: headline property and export
 >  > using subtree scope.
 > 
 > Thanks a lot for the tip.  A suggestion: that the :TITLE: property
 > be used if it exists.

Well, I just read about the EXPORT_ prefix properties for subtree
export, hence realized that the :EXPORT_TITLE: property can be used
for what I had in mind above.

PS: there are a few occurrences of 'sub-tree' in the manual, but many
of 'subtree'; I suggest to use 'subtree' everywhere -- better
regarding searching.


-- 
EOST (École et Observatoire des Sciences de la Terre) 
ITE (Institut Terre & Environnement) | alain.coch...@unistra.fr
5 rue René Descartes   [bureau 110]  | Phone: +33 (0)3 68 85 50 44 
F-67084 Strasbourg Cedex, France | [ slot available for rent ]

Re: Org-mode syntax as a tool-independent MIME type

[Karl Voit]

Hi Bastien,

* Bastien  wrote:
> Hi Karl and Timothy,
>
> thank you Karl for reviving this important topic.
>
> I think our collective priority should be to work on
> https://orgmode.org/worg/dev/org-synxtax.html so that it reflects the
> current Org syntax.  Hopefully we can do this before Org 9.6.  As
> discussed with TEC, we can factor out suggestions from this document
> so that it is not a mix of facts and hypotheses.

A valid approach.

I think we do have two different approaches ongoing here. With OD1 I
tried to come up with a minimal set of Org-mode syntax elements that
are very easy to implement in non-Emacs tools in order to get an
easy intro to this universe. This is a bottom-up approach.

Defining the whole Org-mode syntax as you've suggested is a complete
definition of Orgdown (or OD∞ as of
https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Orgdown-Levels.org
) which is a top-down approach.

So far, I don´t see a conflict here. This may arise with OD2, OD3,
... definitions if they will ever exist.

> Then we can work on suggestions for evolutions of the current Org-mode
> syntax chunk by chunk, as a long-term goal for stabilizing changes for
> Org 10 (2023 ?)

Sounds great!

> What occurred to me while rereading this thread is that definining a
> syntax for a IETF RFC on an Org mimetype probably needs to be done not
> just by this Emacs Org-mode community, but by bringing together other
> "consumers" of .org files, from ecosystems outside of Emacs.
>
> Such a collective work could lead to define what subset of the Org
> syntax is useful as the corner-stone for .org files everywhere - which
> is what you rightfully brought up with "Orgdown".

I tried to collect projects on
https://gitlab.com/publicvoit/orgdown/-/blob/master/doc/Tool-Support.org

> If successful, such a process could end up in defining the minimal and
> official "Org syntax" while allowing implementations (like the one for
> Emacs org-mode) to supercharge this syntax if deemed useful.

To me, this sound aligned with the idea of OD levels OD1 and OD∞.

> Perhaps TEC is right and we will end up having the minimal syntax
> being the one we currently use for Org-mode: we'll see.
>
> But we need volunteers: one to work on worg/dev/org-synxtax.org (I'm
> assuming TEC can lead the work here) and one to set up a discussion
> with people implementing Org in various places (you ?).

What kind of discussion is on your mind? At the moment, I tend to
think that the Org-mode community should provide directions by
developing a formal definition of the syntax and maybe later-on
define viable sub-sets (the OD levels?) so that tool developers
don't have to implement the whole large thing.

At this stage, I don't know what discussions you're trying to start
here. Can you elaborate?

> I suggest to take this sequentially and not tackle the second work
> before we're done with the first one.

I interpret this as "discussions with tool developers after working
on the formal Org definition". This would be my understanding and
also my thought.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: Option that prevents Org to add \lstset{language=⟨language⟩,...} when code blocks are exported to LaTeX

[Ihor Radchenko]

Denis Bitouzé  writes:

> Otherwise, all the options specified by `\lstset` can be applied as an
> option of the `lstlisting` environment:
>
>   ┌
>   │ \begin{lstlisting}[language=⟨language⟩,...]
>   └

This should be the safest and the least verbose.

I implemented the suggestion in the attached patch.
Let me know if it works for you.

>From f1905d7e854c8a1788f92326b453ebd1e2b4a21b Mon Sep 17 00:00:00 2001
Message-Id: 
From: Ihor Radchenko 
Date: Tue, 18 Oct 2022 16:09:19 +0800
Subject: [PATCH] org-latex-src-block--listings: Put options within lstlisting
 environment
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/ox-latex.el (org-latex-src-block--listings): Do not use global
\lstset to set options.  Prefer optional argument to lstlisting
environment instead.

Reported-by: Denis Bitouzé 
Link: https://orgmode.org/list/87pmepvb7u@example.com
---
 lisp/ox-latex.el | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index dc8477d14..38bdbf661 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3577,9 +3577,9 @@ (cl-defun org-latex-src-block--listings
(org-export-data main info))
 (lst-opt (plist-get info :latex-listings-options)))
 (concat
- ;; Options.
  (format
-  "\\lstset{%s}\n"
+  "\\begin{lstlisting}[%s]\n%s\\end{lstlisting}"
+  ;; Options.
   (concat
(org-latex--make-option-string
 (append
@@ -3600,10 +3600,8 @@ (cl-defun org-latex-src-block--listings
(t `(("firstnumber" ,(number-to-string (1+ num-start)))
 ("numbers" "left"))
(let ((local-options (plist-get attributes :options)))
- (and local-options (concat "," local-options)
- ;; Source code.
- (format
-  "\\begin{lstlisting}\n%s\\end{lstlisting}"
+ (and local-options (concat "," local-options
+  ;; Source code.
   (let* ((code-info (org-export-unravel-code src-block))
  (max-width
   (apply 'max
-- 
2.35.1



-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Org-mode syntax as a tool-independent MIME type

[Karl Voit]

Hi Timothy,

* Timothy  wrote:
> --=-=-=
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable

Off topic: Something's quite off here with the encoding at least at
my side (using slrn). I might be related to my setup, can't tell at
the moment.

> Hi Karl,
>
>> For reasons explained in my Orgdown-related articles[1] I would
>> propose to use this chance to introduce a different term for the
>> Org-mode lightweight markup language in contrast to the Org-mode
>> Elisp implementation in order to push the syntax in a tool-agnostic
>> way.
>
> Personally, I don=E2=80=99t see the need for a split. If anything, it seems=
>  harmful to
> me. 

In my personal experience, people often seem to mix both things in
discussions, causing unnecessary loops and conflicts. To me, a
different name is very important. From the response related to OD,
I might be in a minority here.

If you want to push the format, you'd have to use "Org-mode syntax"
or "Org-mode syntax file" or similar. People who are aware of the
difference to the implementation mostly do not use words that differ
here. So in my opinion, a slightly different term would help. It's
not a dramatic difference, it's more subtle for most people. 

> What I=E2=80=99ve taken to doing is referring to org-mode files outside=
>  Emacs simply
> as Org files, and I think this works well for a number of reasons, not leas=
> t because:
> =E2=81=83 It creates a 1-1 corespondency with the file extension, think abo=
> ut how
>   markdown is often referred to as =E2=80=9CMD=E2=80=9D due to the .md file=
>  extension.
> =E2=81=83 I also see other people naturally talking about =E2=80=9COrg file=
> s=E2=80=9D online, so this is
>   partway to being a de-facto convention

You're right. I do think that this is mostly because of lack of an
alternative.

> =E2=81=83 I think it=E2=80=99s less confusing having =E2=80=9COrg=E2=80=9D =
> be related with =E2=80=9Corg-mode=E2=80=9D than
>   =E2=80=9COrgDown=E2=80=9D (or similar), and should people familiar with o=
> ne come across
>   mention of the other it should thus reduce the chance of confusion.
>
> What I do see the need for is the development of more resources on the form=
> at
> itself (like the org-syntax document). Done right this should be a boon to =
> both
> org-mode and Org outside Emacs.

Absolutely.

>> I proposed the term Orgdown for the Org-mode syntax and also
>> proposed various levels in order to provide sub-sets of Org-mode
>> syntax[3] that are realistic to implement with finite effort. Using
>> those OD-levels to come up with a formal definition (EBNF?) might
>> play perfectly well with different parameters of the MIME type[4].
>>
>> In my opinion, this would be a huge step forward for the whole
>> ecosystem that supports the same Org-mode syntax.
>>
>> If we do not keep the MIME type independent from the GNU Emacs
>> Org-mode implementation, the overall use would be much smaller in
>> the long run.
>
> I find myself holding a contrary position, that we should keep the notion o=
> f an
> =E2=80=9COrg=E2=80=9D format under the org-mode project to keep everything =
> under one umbrella,
> as it were.

I don´t think that this is a contrary position. OD is supposed to be
a 100% sub-set of Org-mode syntax as implemented in Elisp.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
   > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: [BUG] ox-odt fails for org-id links (e.g., from org-roam v2) [9.5.2 (9.5.2-gfbff08 @ /home/moritz/.emacs.d/elpa/27.2/develop/org-9.5.2/)]

[Ihor Radchenko]

Moritz Schäfer  writes:

> When exporting an org-file with org-id based links  to odt, I get the
> error error "FIXME: Unable to resolve ", where  is the
> filename, the org-id-link was pointing to.
>
> Org-id links (example below) are the default for org-roam (v2).
>
> [[id:5222a0dd-5084-41bd-b61d-21dcb3290187][Note title]]
>
> The issue lies within ox-odt.el in the org-odt-link function. There, '
> destination' takes the value of the file name of the id-link target.
> Therefore, (org-element-type destination) gets evaluated to 'plain-text,
> which is not resolvable by 'org-odt-link--infer-description', thus it
> raises the error.
>
> I worked around this issue by adding a check for plain-text, but would like
> to raise this issue here to find proper ideas on how to fix this.

Thanks for reporting, and sorry for the late reply.
Could you provide an example and steps demonstrating the problem?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Option that prevents Org to add \lstset{language=⟨language⟩,...} when code blocks are exported to LaTeX

[Denis Bitouzé]

Le 18/10/22 à 04h14, Ihor Radchenko a écrit :

> Denis Bitouzé  writes:
>
>> here is a feature request about the LaTeX export.
>>
>> With ~(setq org-latex-listings t)~, code blocks such as:
>>
>>   ┌
>>   │ #+BEGIN_SRC ⟨language⟩ :exports code
>>   │ ...
>>   │ #+END_SRC
>>   └
>>
>> are exported to LaTeX into:
>>
>>   ┌
>>   │ \lstset{language=⟨language⟩,label= ,caption= ,captionpos=b,numbers=none}
>>   │ \begin{lstlisting}
>>   │ ...
>>   │ \end{lstlisting}
>>   └
>>
>> But the:
>>
>>   ┌
>>   │ \lstset{language=⟨language⟩,label= ,caption= ,captionpos=b,numbers=none}
>>   └
>>
>> systematically added before each of the ~lstlisting~ LaTeX environments
>> is not always desirable and let me explain why.
>
> Confirmed.
> Is there a way to apply \lstset locally for the environment?

It is enough to put it in a group:

  ┌
  │ \bgroup
  │ \lstset{...}
  │ \begin{lstlisting}
  │ ...
  │ \end{lstlisting}
  │ \egroup
  └

Otherwise, all the options specified by `\lstset` can be applied as an
option of the `lstlisting` environment:

  ┌
  │ \begin{lstlisting}[language=⟨language⟩,...]
  └
-- 
Denis

Re: surprising(?) interaction between agenda grid and default-duration

[Ihor Radchenko]

Detlef Steuer  writes:

> I you specify a default duration of an event, say,
>
> (setq org-agenda-default-appointment-duration 60)
>
> and specify a time grid, say
>
> (setq org-agenda-time-grid '((today remove-match)
>  (800 1000 1200 1400 1600 1800 2000)
>  ".." "" ))
>
> Then setting the default duration overrides the grid appearance.
> ...
>   13:40-14:40 now - - - - - - - - - - - - - - - - - - - - - - - - 
> -
>   14:00-15:00 
>   16:00-17:00 
>   18:00-19:00 
>   20:00-21:00 
>
> caught me by surprise. Even the 2 hour block length setting is overridden.
>
> If this should be considered a bug, I don't know. But maybe the manual
> should mention and describe the relationship between these settings?
>
> As the description of org-agenda-default-appointment-duration does not
> mention the grid at all, I would think the logical improvement would be
> to let the grid alone and use the default duration as advertised only.

Confirmed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at .
Support Org development at ,
or support my work at 

Re: Org-mode syntax as a tool-independent MIME type

[Bastien]

Hi Karl and Timothy,

thank you Karl for reviving this important topic.

I think our collective priority should be to work on
https://orgmode.org/worg/dev/org-synxtax.html so that it reflects the
current Org syntax.  Hopefully we can do this before Org 9.6.  As
discussed with TEC, we can factor out suggestions from this document
so that it is not a mix of facts and hypotheses.

Then we can work on suggestions for evolutions of the current Org-mode
syntax chunk by chunk, as a long-term goal for stabilizing changes for
Org 10 (2023 ?)

What occurred to me while rereading this thread is that definining a
syntax for a IETF RFC on an Org mimetype probably needs to be done not
just by this Emacs Org-mode community, but by bringing together other
"consumers" of .org files, from ecosystems outside of Emacs.

Such a collective work could lead to define what subset of the Org
syntax is useful as the corner-stone for .org files everywhere - which
is what you rightfully brought up with "Orgdown".

If successful, such a process could end up in defining the minimal and
official "Org syntax" while allowing implementations (like the one for
Emacs org-mode) to supercharge this syntax if deemed useful.

Perhaps TEC is right and we will end up having the minimal syntax
being the one we currently use for Org-mode: we'll see.

But we need volunteers: one to work on worg/dev/org-synxtax.org (I'm
assuming TEC can lead the work here) and one to set up a discussion
with people implementing Org in various places (you ?).

I suggest to take this sequentially and not tackle the second work
before we're done with the first one.

2 cts,

-- 
 Bastien