Re: [FR] yank media: allow customization of absolute path a filter for type candidates

[Visuwesh]

[ஞாயிறு பிப்ரவரி 23, 2025] Ihor Radchenko wrote:

> Visuwesh  writes:
>
>>> Visuwesh, do you want to proceed with this part?
>>
>> Do we only want this for images, or for everything?  Everything entails
>> images, all dropped files, dropped image files only, and XDND.
>
> Everything, I think.
>
>> This would warrant a NEWS entry too, right?
>
> Indeed.
>
>> +(defun org-link--normalise-filename (filename &optional absolute-always)
>> +  "Return FILENAME as required by the value of `org-link-file-path-type'.
>> +When ABSOLUTE-ALWAYS is non-nil, always return an absolute and
>> +abbreviated filename."
>
> ABSOLUTE-ALWAYS should not be necessary. The caller may simply let-bind
> `org-link-file-path-type'. Alternatively, you may avoid using dynamic
> scope and simply pass org-link-file-path-type as the second argument.

I went with a slightly different approach in the attached where an
optional argument is accepted by the function, defaulting to the value
of org-link-file-path-type.

>From 448387e7645623f29446986d529ce0b388477f77 Mon Sep 17 00:00:00 2001
From: Visuwesh 
Date: Tue, 25 Feb 2025 11:17:34 +0530
Subject: [PATCH] Respect `org-file-link-type' in `yank-media' and DND handlers

* lisp/ol.el (org-link--normalise-filename): New function...
(org-insert-link): extracted from here.  Use it
* lisp/org.el (org--image-yank-media-handler)
(org--dnd-local-file-handler, org--dnd-attach-file)
(org--dnd-xds-function): Respect the value of `org-file-link-type'
when inserting file: links.
* etc/ORG-NEWS (Miscellaneous): Announce the change.

Reported-by: pinmacs 
Link: https://list.orgmode.org/orgmode/a7d4e731-1af6-4ce9-9f4d-d49ddcf57...@cas.cat
---
 etc/ORG-NEWS |  5 +
 lisp/ol.el   | 49 -
 lisp/org.el  | 23 ++-
 3 files changed, 47 insertions(+), 30 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 9eb4f711c..e39e06b9e 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -416,6 +416,11 @@ capture ~:tree-type~ options]], the internal variable
 undocumented helper function ~org-datetree-insert-line~.
 
 ** Miscellaneous
+*** ~yank-media~ and DND handlers now honor the user option ~org-file-link-type~
+
+When inserting file: links, ~yank-media~ and DND handlers now respect
+the user option ~org-file-link-type~.
+
 *** ox-man: Support specifying =#+DATE:= and ~org-export-with-date~
 
 Previously, ox-man ignored =#+DATE:= keyword even when
diff --git a/lisp/ol.el b/lisp/ol.el
index b456f79e6..e6acf5ad6 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -2565,6 +2565,31 @@ (defun org-store-link (arg &optional interactive?)
 (org-link--add-to-stored-links link desc)))
 (car org-stored-links)
 
+(defun org-link--normalise-filename (filename &optional method)
+  "Return FILENAME as required by METHOD.
+METHOD defaults to the value of `org-link-file-path-type'."
+  (setq method (or method org-link-file-path-type))
+  (cond
+   ((eq method 'absolute)
+(abbreviate-file-name (expand-file-name filename)))
+   ((eq method 'noabbrev)
+(expand-file-name filename))
+   ((eq method 'relative)
+(file-relative-name filename))
+   ((functionp method)
+(funcall method filename))
+   (t
+(save-match-data
+  (if (string-match (concat "^" (regexp-quote
+ (expand-file-name
+  (file-name-as-directory
+   default-directory
+			(expand-file-name filename))
+	  ;; We are linking a file with relative path name.
+	  (substring (expand-file-name filename)
+		 (match-end 0))
+	(abbreviate-file-name (expand-file-name filename)))
+
 ;;;###autoload
 (defun org-insert-link (&optional complete-file link-location description)
   "Insert a link.  At the prompt, enter the link.
@@ -2752,27 +2777,9 @@ (defun org-insert-link (&optional complete-file link-location description)
 		 link path-start (match-beginning 0))
 		  (substring-no-properties link (match-end 0
 	   (origpath path))
-	  (cond
-	   ((or (eq org-link-file-path-type 'absolute)
-		(equal complete-file '(16)))
-	(setq path (abbreviate-file-name (expand-file-name path
-	   ((eq org-link-file-path-type 'noabbrev)
-	(setq path (expand-file-name path)))
-	   ((eq org-link-file-path-type 'relative)
-	(setq path (file-relative-name path)))
-	   ((functionp org-link-file-path-type)
-	(setq path (funcall org-link-file-path-type path)))
-	   (t
-	(save-match-data
-	  (if (string-match (concat "^" (regexp-quote
-	 (expand-file-name
-	  (file-name-as-directory
-	   default-directory
-(expand-file-name path))
-		  ;; We are linking a file with relative path name.
-		  (setq path (substring (expand-file-name path)
-	(match-end 0)))
-		(setq path (abbreviate-file-name (expand-file-name path)))
+	  (setq path (org-link--normalise-filename path (if (equal complete '(16))
+'absolute
+

Re: Some hacks on top of org-publish

[Nikolaos Chatzikonstantinou]

On Sat, Feb 22, 2025 at 11:51 PM Nikolaos Chatzikonstantinou
 wrote:
>
> On Mon, Dec 30, 2024 at 1:12 PM Ihor Radchenko  wrote:
> >
> > Nikolaos Chatzikonstantinou  writes:
> >
> > > ... I got inspired by Worg's website
> > > which does not do any backend hacking as far as I can tell, but
> > > instead puts some javascript to collapse the table of contents.
> >
> > WORG does not use JS. The TOC is implemented using pure CSS.
> >
> > > Do you have a particular backend for me to look at as a recommendation
> > > of an easy source? I don't want it to be derived because I want to
> > > understand the whole process.
> >
> > Try ox-org.
>
> Hello Ihor,
>
> I'm still struggling with the basics of derived backends. Here's what
> I have so far: 
> .
>
> I am simply trying to transcode italic elements so that they're
> treated differently on headers (with ) and in body (with ). How
> can I accomplish this? My function is (straight from ox-html.el):
>
> #+begin_src elisp
> (defun blorg-html-italic (_italic contents info)
>   "Transcode ITALIC from Org to HTML for a blog.
> Italicize if in title, otherwise emphasize."
>   (format
>(or (cdr (assq 'italic (plist-get info :html-text-markup-alist))) "%s")
>contents))
> #+end_src
>
> I cannot tell what the three arguments _italic, contents, info are
> for, even after reading the docs, and after inspecting them with
> edebug. Do I need to understand Org ASTs? Do I need to understand
> Org-publish better? I'm just at loss here.

I realized what the answer is: The contents variable is just a focus
of the entire Org AST, as returned by org-element-parse-buffer, and
the docs of that function are very helpful to understand what the
format of contents is.

Regards,
Nikolaos Chatzikonstantinou

Re: [BUG] Latex exporter should consider export settings [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Pedro Andres Aranda Gutierrez]

Attached is a quick fix that only takes into account the existing
org-export-with- settings.

Best, /PA

On Tue, 25 Feb 2025 at 07:31, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> HI,
> I'm giving this a second shot, now that the ToC fix is in the code.
>
> I have a question: we have the org-export-with-... for author, title and
> creator.
> So we can act on these things in the PDF attributes when exporting to
> LaTeX.
> The producer will include the LaTeX distribution. Do we really want to
> suppress this?
>
> If so, (org-latex--format-spec) doesn't know about the producer and we
> need to introduce this as a new entry in the format spec.
>
> WDYT?
>
> /PA
>
> PS: I sincerely think it would be easier to add it as a note in the doc,
> that if you don't want metadata in your PDF, you should customize
> or set a local value for the hyperref setup. You don't include metadata,
> but you are able to set a title for the reader.
>
>
> On Wed, 19 Feb 2025 at 09:26, Pedro Andres Aranda Gutierrez <
> paag...@gmail.com> wrote:
>
>> Final version... got the wrong file... sorry /PA
>>
>> On Wed, 19 Feb 2025 at 07:57, Pedro Andres Aranda Gutierrez <
>> paag...@gmail.com> wrote:
>>
>>> Mea culpa.. attached...
>>> /PA
>>>
>>> On Wed, 19 Feb 2025 at 07:22, Pedro Andres Aranda Gutierrez <
>>> paag...@gmail.com> wrote:
>>>
 Hi Ihor,

 I'll dive again in my Outbox to check, but I'm pretty sure I sent you
 what I consider is now the last version, consolidated as a unified patch.
 It has all comments regarding the documentation and a reworked LISP
 implementation which was prompted some comments of yours. It passes tests,
 etc.

 Best, /P.A.

 On Tue, 18 Feb 2025 at 19:41, Ihor Radchenko 
 wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > OK, great. But there's also the patch for the table of contents
> waiting...
> > and we wanted to give this idea another approach to
> > code once and use it both to export latex and beamer. I'd appreciate
> we do
> > this after we have sorted out the table of contents.
>
> In my book, I am waiting for you to submit the next version of the
> TOC patch. Just double-checking.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


 --
 Fragen sind nicht da, um beantwortet zu werden,
 Fragen sind da um gestellt zu werden
 Georg Kreisler

 Headaches with a Juju log:
 unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
 run a leader-deposed hook here, but we can't yet
 Year 1 of the New Koprocracy


>>>
>>> --
>>> Fragen sind nicht da, um beantwortet zu werden,
>>> Fragen sind da um gestellt zu werden
>>> Georg Kreisler
>>>
>>> Headaches with a Juju log:
>>> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
>>> run a leader-deposed hook here, but we can't yet
>>> Year 1 of the New Koprocracy
>>>
>>>
>>
>> --
>> Fragen sind nicht da, um beantwortet zu werden,
>> Fragen sind da um gestellt zu werden
>> Georg Kreisler
>>
>> Headaches with a Juju log:
>> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
>> run a leader-deposed hook here, but we can't yet
>> Year 1 of the New Koprocracy
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
> Year 1 of the New Koprocracy
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
Year 1 of the New Koprocracy
From 2a102300eafb674d06705442544e456260ad2c17 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Tue, 25 Feb 2025 08:12:07 +0100
Subject: [PATCH] Export PDF metadata using hyperref according to
 org-export-with-...

---

lisp/ox-latex.el: adjust PDF metadata according to the existing settings in
org-export-with-title,  org-export-with-author and  org-export-with-creator.

* lisp/ox-latex.el: (org-latex--format-spec): replace author, title and creator
fields with "" when the corresponding org-export-with-... is nil.

Link: https://list.orgmode.org/87zfivm8qt.fsf@localhost/T/#t

 lisp/ox-latex.el | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index a7ab4ca7b..af3ac308b 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -1940,16 +1940,24 @@ INFO is a plist used as a communication channel."
 ;; Here the ac

Re: [BUG] Latex exporter should consider export settings [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Pedro Andres Aranda Gutierrez]

HI,
I'm giving this a second shot, now that the ToC fix is in the code.

I have a question: we have the org-export-with-... for author, title and
creator.
So we can act on these things in the PDF attributes when exporting to LaTeX.
The producer will include the LaTeX distribution. Do we really want to
suppress this?

If so, (org-latex--format-spec) doesn't know about the producer and we need
to introduce this as a new entry in the format spec.

WDYT?

/PA

PS: I sincerely think it would be easier to add it as a note in the doc,
that if you don't want metadata in your PDF, you should customize
or set a local value for the hyperref setup. You don't include metadata,
but you are able to set a title for the reader.


On Wed, 19 Feb 2025 at 09:26, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> Final version... got the wrong file... sorry /PA
>
> On Wed, 19 Feb 2025 at 07:57, Pedro Andres Aranda Gutierrez <
> paag...@gmail.com> wrote:
>
>> Mea culpa.. attached...
>> /PA
>>
>> On Wed, 19 Feb 2025 at 07:22, Pedro Andres Aranda Gutierrez <
>> paag...@gmail.com> wrote:
>>
>>> Hi Ihor,
>>>
>>> I'll dive again in my Outbox to check, but I'm pretty sure I sent you
>>> what I consider is now the last version, consolidated as a unified patch.
>>> It has all comments regarding the documentation and a reworked LISP
>>> implementation which was prompted some comments of yours. It passes tests,
>>> etc.
>>>
>>> Best, /P.A.
>>>
>>> On Tue, 18 Feb 2025 at 19:41, Ihor Radchenko 
>>> wrote:
>>>
 Pedro Andres Aranda Gutierrez  writes:

 > OK, great. But there's also the patch for the table of contents
 waiting...
 > and we wanted to give this idea another approach to
 > code once and use it both to export latex and beamer. I'd appreciate
 we do
 > this after we have sorted out the table of contents.

 In my book, I am waiting for you to submit the next version of the
 TOC patch. Just double-checking.

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

>>>
>>>
>>> --
>>> Fragen sind nicht da, um beantwortet zu werden,
>>> Fragen sind da um gestellt zu werden
>>> Georg Kreisler
>>>
>>> Headaches with a Juju log:
>>> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
>>> run a leader-deposed hook here, but we can't yet
>>> Year 1 of the New Koprocracy
>>>
>>>
>>
>> --
>> Fragen sind nicht da, um beantwortet zu werden,
>> Fragen sind da um gestellt zu werden
>> Georg Kreisler
>>
>> Headaches with a Juju log:
>> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should
>> run a leader-deposed hook here, but we can't yet
>> Year 1 of the New Koprocracy
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
> Year 1 of the New Koprocracy
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
Year 1 of the New Koprocracy

Re: [PATCH] Sanitize links in headings to avoid broken Texinfo menus

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> I think it is 6443c83bd1 :)

Oops!  You are right.

> May you please keep the old test cases and add new cases as extra?
> I see no reason not to keep the old tests.

The old test has wrong assumptions in the new reality and it must *not*
pass.  I tried to adjust it, before submitting the patch, but it changed
dramatically and collapsed into an incomplete version of the new test.
In other words, no test was deleted.  Instead, one test was updated.

Does that make sense?

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
--- Thomas Alva Edison, 1932

Rudolf Adamkovič  [he/him]
http://adamkovic.org

Re: [PATCH] lisp/org-collector.el: Add support for TBLFM

[Ihor Radchenko]

Slava Barinov  writes:

> Oh, right, I messed the scopes.

Is your new patch version correct?
I still see #+TBLFM stripped unconditionally even when :tblfm parameter
is not specified.

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

[BUG] Org report [9.7.19 (9.7.19-??-5a4686915 @ /Users/butlerlocal/.emacs.d/.local/straight/build-29.4/org/)]

[Kevin Butler]

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.




Emacs  : GNU Emacs 29.4 (build 1, aarch64-apple-darwin21.6.0, NS appkit-2113.60 
Version 12.6.6 (Build 21G646))
 of 2024-08-02
Package: Org mode version 9.7.19 (9.7.19-??-5a4686915 @ 
/Users/butlerlocal/.emacs.d/.local/straight/build-29.4/org/)

current state:
==
(setq
 org-link-elisp-confirm-function nil
 org-directory "~/Dropbox/notes"
 org-after-refile-insert-hook '(save-buffer)
 org-indirect-buffer-display 'current-window
 org-roam-db-gc-threshold 2305843009213693951
 org-bibtex-headline-format-function 'org-bibtex-headline-format-default
 org-log-done 'time
 org-agenda-tags-todo-honor-ignore-options t
 org-roam-mode-hook '(+org-roam-detach-magit-section-mode-map-h 
turn-on-visual-line-mode)
 org-load-hook '(+org-init-org-directory-h +org-init-appearance-h 
+org-init-agenda-h +org-init-attachments-h
 +org-init-babel-h +org-init-babel-lazy-loader-h 
+org-init-capture-defaults-h +org-init-capture-frame-h
 +org-init-custom-links-h +org-init-export-h +org-init-habit-h 
+org-init-hacks-h +org-init-keybinds-h
 +org-init-popup-rules-h +org-init-smartparens-h 
+org-init-roam-h)
 org-startup-folded nil
 org-babel-after-execute-hook '(+org-redisplay-inline-images-in-babel-result-h)
 org-link-abbrev-alist '(("doomdir" . "/Users/butlerlocal/.doom.d/%s") 
("emacsdir" . "/Users/butlerlocal/.emacs.d/%s")
 ("doom-repo" . 
"https://github.com/doomemacs/doomemacs/%s";)
 ("wolfram" . "https://wolframalpha.com/input/?i=%s";)
 ("wikipedia" . "https://en.wikipedia.org/wiki/%s";) 
("duckduckgo" . "https://duckduckgo.com/?q=%s";)
 ("kagi" . "https://kagi.com/search?q=%s";) ("gmap" . 
"https://maps.google.com/maps?q=%s";)
 ("gimages" . "https://google.com/images?q=%s";) 
("google" . "https://google.com/search?q=";)
 ("youtube" . "https://youtube.com/watch?v=%s";) 
("github" . "https://github.com/%s";))
 org-agenda-files 
'("~/Dropbox/notes/.attach/ae/fffb9c-cb85-44b9-a02c-23e4452969b2/_20240522_134002PRISM
 Webinar Edo Navot.org" 
"~/Dropbox/notes/Department_and_FICS_Tasks/cise-retreat-research-notes.org" 
"~/Dropbox/notes/Department_and_FICS_Tasks/farimah-notes.org" 
"~/Dropbox/notes/deft/2019-03-06 itu-meeting.org" 
"~/Dropbox/notes/deft/2019-03-10 acsac-demongraphics-notes.org" 
"~/Dropbox/notes/deft/2019-03-11 fics-conference.org" 
"~/Dropbox/notes/deft/2019-05 wise-funding-panel.org" 
"~/Dropbox/notes/deft/2019-065 guevara-wisec.org" 
"~/Dropbox/notes/deft/2021-05-25 oakland-ethics-panel.org" 
"~/Dropbox/notes/deft/Defcon smartphone firmware attacks.org" 
"~/Dropbox/notes/deft/SRC Meeting notes 2019-02-28.org" 
"~/Dropbox/notes/deft/ipv-surveillance-usenix.org" 
"~/Dropbox/notes/deft/research.gov phone number.org" 
"~/Dropbox/notes/meetings/search/2019-12-search-datasci.org" 
"~/Dropbox/notes/meetings/.#embry-riddle-meeting.org" 
"~/Dropbox/notes/meetings/2019-11-20-cyber-manufacturing-meeting.org" 
"~/Dropbox/notes/meetings/2019-12-acsac-general-chair-debrief.org" 
"~/Dropbox/notes/meetings/2019-12-acsac-hotwash.org" 
"~/Dropbox/notes/meetings/2020-01-13-ehab-call.org" 
"~/Dropbox/notes/meetings/2020-01-arl-meeting.org" 
"~/Dropbox/notes/meetings/2020-01-mpc-workshop.org" 
"~/Dropbox/notes/meetings/2020-04-honeywell.org" 
"~/Dropbox/notes/meetings/2020-06-18 nsf-panel-notes.org" 
"~/Dropbox/notes/meetings/2020-10-22_DSIT-notes.org" 
"~/Dropbox/notes/meetings/2021-04-darpa-mice.org" 
"~/Dropbox/notes/meetings/2022-10-22_NIH-workshop.org" 
"~/Dropbox/notes/meetings/2023-07 cra-ccc-council-meeting.org" 
"~/Dropbox/notes/meetings/2023-10-darpa-ics-proposers-day.org" 
"~/Dropbox/notes/meetings/atcmd.org" "~/Dropbox/notes/meetings/ccs18.org" 
"~/Dropbox/notes/meetings/cd-meet.org" 
"~/Dropbox/notes/meetings/darpa-race.org" 
"~/Dropbox/notes/meetings/embry-riddle-meeting.org" 
"~/Dropbox/notes/meetings/fingerprint.org" 
"~/Dropbox/notes/meetings/firmware.org" 
"~/Dropbox/notes/meetings/foci-notes.org" 
"~/Dropbox/notes/meetings/frontier19-mobile.org" 
"~/Dropbox/notes/meetings/itu.org" "~/Dropbox/notes/meetings/lineage.org" 
"~/Dropbox/notes/meetings/smcsgx.org" "~/Dropbox/notes/meetings/sonar.org" 
"~/Dropbox/notes/meetings/students.org" "~/Dropbox/notes/meetings/wips2023.org" 
"~/Dropbox/notes/meetings/wisec.org" "~/Dropbox/notes/meetings/xai.org" 
"~/Dropbox/notes/pages/contents.org" 
"~/Dropbox/notes/project/2024-marcom-search.org" 
"~/Dropbox/notes/project/acsac.org" "~/Dropbox/notes/project/cyan.org" 
"~/Dropbox/notes/project/eyetrack.org" 
"~/Dropbox/notes/project/fics-conference.org" 
"~/D

Re: [BUG] Incorrect LaTeX export when using images in a table to display them side-by-side. [9.7.5 (release_9.7.5 @ /home/dadinn/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> If we have a table of figures, we might have problems when referencing the 
> figures.

Figures inside tables will be inlined. They are not floats and cannot
have caption, name, be referenced.

> What approach would fit best
>
> 1. Keep tables and figures separate, which may imply a good amount of Lisp, 
> still to be investigated.
> 2. Make everything with tables and have
>a) headings starting with ’Table’ for figures
>b) non consecutive figure numbering

Just \includegraphics will do.
Basically, leave things as they are now. The main problem is not
including image, but using \begin{center} ... where it cannot be used.

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

Re: Repeater in a time-range?

[David Masterson]

Rens Oliemans  writes:

> David Masterson  writes:
>
>> Is it possible to specify a repeater in a time-range in Org?  Something
>> like:
>>
>>   <2025-03-06 Thu 16:00 +1w>--<2025-03-27 Thu 16:00>
>
> Not like this, unfortunately.  It is possible with diary-sexps, or M-x
> org-clone-subtree-with-time-shift. Check out these threads:
> - https://list.orgmode.org/87bjxe2lwa@renaudbussieres.com/
> - https://list.orgmode.org/87bk0gsop3@breatheoutbreathe.in/
>
> And also see
> (info "(org) Timestamps")
> 
> , and for diary sexps, see
> (info "(emacs) Special Diary Entries")

Thanks
-- 
David Masterson

Re: [BUG] Incorrect LaTeX export when using images in a table to display them side-by-side. [9.7.5 (release_9.7.5 @ /home/dadinn/.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

>>This is \begin{center}
>>\includegraphics[width=\linewidth]{/home/yantar92/Downloads/wallpaper.png}
>>\end{center} foo.
>> 
>> Pedro, any ideas how to address this?
>
> Just to be clear, what is the intent of the org line?
> 1. Inlining a figure in a paragraph, with the image being as wide as the 
> paragraph.
> 2. Having a smaller image, preceded by the “This is:’ and ended with the 
> “foo” in the same line?

The aim is replicating HTML export. Inline image is inlined; not
floated, not captioned, etc. Think of emoji. If there is an image in the
middle of paragraph is it just like 😼 - just goes as a glyph alike any
other letter.

> For 2. You will have to play with the image’s size.

That's a job for user. In the future, we may allow inline attributes
(see https://list.orgmode.org/orgmode/875xwqj4tl.fsf@localhost/), but
that's not our concern now. My plan minimum is to make things compile at
least :)

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

Re: [BUG] The org-indent-drawer function does not work for drawers in plain lists since commit af300bd5b

[Vins Xiro]

On Sun, Feb 23 2025, Ihor Radchenko wrote:

> Vins Xiro  writes:
>
>> Well, there is org-indent-drawer, but it does not work as I expect
>> since commit af300bd5b, as I can see.
>
> Are you sure?
> af300bd5b0 is a 12 years old commit.

Definitely.

I had to use Distrobox with an old Linux distribution to find the commit.

> It is not exactly a bug - 0 indentation is a perfectly valid indentation
> position in some cases.

So it is not a bug.

Thanks for the clarification.

-- 
WBR, Vins Xiro

Re: [PATCH] Improve the clock-out message

[Ihor Radchenko]

Rudolf Adamkovič  writes:
> Ihor, if you are OK with this version, please merge. :)

Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=67de496b1e

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

Re: [PATCH] ob-dot: Add `graphviz-dot' language alias

[Rudolf Adamkovič]

Ihor Radchenko  writes:

> They work. Fundamental mode is usable, isn't it?

As usable as any other language: no syntax highlighting, no correct
indentation, no compilation and run, no code completion, etc.

Instead of theorizing, let me tell you my experience, as a user of the
Org Mode and Graphviz:

I have had the Graphviz Dot mode installed for a long time and only now
noticed Org does not use it.  I took it for granted that Org would does
its best to enable the right major mode, for that is the case with all
the other languages I use.  Turns out, it does not, and I missed out on
all the great features of the Graphviz Dot mode.

A user of the Org Mode and Graphviz has currently 3 options:

(1) Write `#+begin_src dot':

- lose all benefits of the specialized major mode
- keep all benefits of Org Babel

(2) Write `#+begin_src graphviz-dot':

- keep all benefits of the specialized major mode
- lose all benefits or Org Babel:

  org-babel-execute-src-block: No org-babel-execute function for 
graphviz-dot!

(3) Keep changing between `dot' and `graphviz-dot':

This is the best option for an average user, currently.

Note that options (2) and (3) require the user to "know the trick".

> In contrast, if you force using graphwiz-dot-mode from MELPA, and it is
> not installed, there will be an error.

Is this not the default behavior in Org Babel?

e.g. Lua or R are editable in the Fundamental mode as Dot is.

> Maybe we should solve this problem more generally, and universally
> change babel to try deriving the major mode first and fall back to
> fundamental-mode if the major mode is not available.

That would be great.  In fact, it sounds like a perfect job for Org
experts like you. :)

But even if we had this functionality, we still need an alias for
`graphviz-dot', right?  Otherwise, the specialized mode would not
activate.  So, perhaps my patch is a step in the right direction?

> Why not simply graphviz?

I named it after the specialized major mode, to make it work out of the
box.  But, as I explain below, `graphviz' would be the best name for
these source blocks.

>> P.S. As the next step, we could perhaps rename `ob-dot' to
>> `ob-graphviz-dot' and make `dot' the alias, not `graphviz-dot', so that
>> the officially documented `#+BEGIN_SRC dot' works out of the box too.
>
> But the official name is "DOT language" isn't it?
> I see no reason for renaming.

In fact, the best name would be `ob-graphviz', and the reason is as
follows.  While the `dot' source blocks default to the Dot language,
they can use all the other Graphviz languages as well.  For example,
below is my drawing of a molecule with a hydrocarbon ring, which is
easier done with Circo:

#+begin_src dot :cmd circo :file cyclopentane.svg
  graph {
bgcolor = transparent
node [shape = circle]
{ node [label = "C" style = filled] c1 c2 c3 c4 c5 }
{ node [label = "H"] h11 h12 h21 h22 h31 h32 h41 h42 h51 h52 }
c1 -- c2 -- c3 -- c4 -- c5 -- c1
h11 -- c1 -- h12
h21 -- c2 -- h22
h31 -- c3 -- h32
h41 -- c4 -- h42
h51 -- c5 -- h52
  }
#+end_src

Calling the source block `dot' is nonsense, as the language is `circo'.

Instead, we should write `#+begin_src graphviz :cmd circo' and and call
the Babel package `ob-graphviz`.  It just happens that `:cmd' defaults
to `dot'.  And that is fine, as Dot is the most popular Graphviz
language.

Rudy
-- 
"If you're thinking without writing, you only think you're thinking."
--- Leslie Lamport

Rudolf Adamkovič  [he/him]
http://adamkovic.org

Re: [BUG] Incorrect LaTeX export when using images in a table to display them side-by-side. [9.7.5 (release_9.7.5 @ /home/dadinn/.emacs.d/straight/build/org/)]

[Pedro Andres Aranda Gutierrez]

Fine. I have approached this from the LaTeX we want to generate and have a 
proof of concept… attached is the PDF produced on overleaf.com 

A question:

If we have a table of figures, we might have problems when referencing the 
figures.

What approach would fit best

1. Keep tables and figures separate, which may imply a good amount of Lisp, 
still to be investigated.
2. Make everything with tables and have
   a) headings starting with ’Table’ for figures
   b) non consecutive figure numbering

Best, /PA

> El 24 feb 2025, a las 8:57, Pedro Andres Aranda Gutierrez  
> escribió:
> 
> Hi Ihor,
> 
> I’m starting to look at this. Could you please confirm that the ToC patch is 
> closed before or are there any further things to add to it?
> 
> Best, /PA
> 
>> El 23 feb 2025, a las 18:47, Ihor Radchenko  escribió:
>> 
>> Daniel Dinnyes  writes:
>> 
>>> I am trying to generate a LaTeX export with these two images displayed
>>> side-by-side:
>>> 
>>> ```org
>>> | [[file:./chat1.png]] | [[file:./chat2.png]] |
>>> ```
>>> 
>>> They display correctly inside the Emacs buffer.
>>> 
>>> On the HTML export they display correctly side-by-side, but the for some
>>> reason there are visible border lines on the top and bottom of the table
>>> (not on the sides).
>> 
>> This is expected in HTML export for tables.
>> 
>>> The LaTeX export (via `org-export-dispatch` does not work. For some
>>> reason the `pdflatex` process runs on 100% CPU, and doesn't complete.
>>> 
>>> I've looked at just the .tex export Org generates:
>>> 
>>> ```
>>> \\begin{tabular}\[\\centering\]{ll}
>>> \\begin{center}
>>> \\includegraphics\[width=.9\\linewidth\]{./chat1.png}
>>> \\end{center} & \\begin{center}
>>> \\includegraphics\[width=.9\\linewidth\]{./chat2.png}
>>> \\end{center}\\
>>> \\end{tabular}
>>> ```
>>> 
>>> It seems the problem is that it generates the center environments inside
>>> the tabular one.
>> 
>> Confirmed.
>> `org-latex--inline-image', by default (when `org-latex-images-centered'
>> is t), tries to center the images using center environment
>> 
>> It is ok for standalone images, but is clearly broken when the image is
>> really inline - a part of paragraph or table cell in this case.
>> 
>> Another example is
>> 
>>  This is file:~/Downloads/wallpaper.png foo.
>> 
>> which is exported as
>> 
>>   This is \begin{center}
>>   \includegraphics[width=\linewidth]{/home/yantar92/Downloads/wallpaper.png}
>>   \end{center} foo.
>> 
>> Pedro, any ideas how to address this?
>> 
>> -- 
>> Ihor Radchenko // yantar92,
>> Org mode maintainer,
>> Learn more about Org mode at .
>> Support Org development at ,
>> or support my work at 
> 

Re: Repeater in a time-range?

[Rens Oliemans]

David Masterson  writes:

> Is it possible to specify a repeater in a time-range in Org?  Something
> like:
>
>   <2025-03-06 Thu 16:00 +1w>--<2025-03-27 Thu 16:00>

Not like this, unfortunately.  It is possible with diary-sexps, or M-x
org-clone-subtree-with-time-shift. Check out these threads:
- https://list.orgmode.org/87bjxe2lwa@renaudbussieres.com/
- https://list.orgmode.org/87bk0gsop3@breatheoutbreathe.in/

And also see
(info "(org) Timestamps")

, and for diary sexps, see
(info "(emacs) Special Diary Entries")
-- 
Rens

Re: May we have a variant of display-buffer-reuse-window that considers indirect buffers?

[martin rudalics]

> Martin, may you install your part of the patch for Emacs?

Installed on master.  Please check.

martin

Re: [BUG] Incorrect LaTeX export when using images in a table to display them side-by-side. [9.7.5 (release_9.7.5 @ /home/dadinn/.emacs.d/straight/build/org/)]

[Pedro Andres Aranda Gutierrez]

Hi,
Answers inline...

> El 23 feb 2025, a las 18:47, Ihor Radchenko  escribió:
> 
> It is ok for standalone images, but is clearly broken when the image is
> really inline - a part of paragraph or table cell in this case.
> 
> Another example is
> 
>   This is file:~/Downloads/wallpaper.png foo.
> 
> which is exported as
> 
>This is \begin{center}
>\includegraphics[width=\linewidth]{/home/yantar92/Downloads/wallpaper.png}
>\end{center} foo.
> 
> Pedro, any ideas how to address this?

Just to be clear, what is the intent of the org line?
1. Inlining a figure in a paragraph, with the image being as wide as the 
paragraph.
2. Having a smaller image, preceded by the “This is:’ and ended with the “foo” 
in the same line?

For 2. You will have to play with the image’s size.
If you mean 1. it will also depend on the image’s size. Playing with something 
equivalent, my wallpaper ;-) produces the same when exporting the line to PDF 
and to HTML.

So, to start with, I’d rather leave ’the paragraph side' of the “problem” for 
further discussion and concentrate on the 'table side' (my previous message).

Best, /PA
> 
> -- 
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: ob-haskell has stopped working

[Aitenate]

It sound like the same issue I've experienced [1]. Try using an older
version of haskell-mode and it should workaround the problem.

[1] - https://github.com/haskell/haskell-mode/issues/1867

Regards,
Aitenate

Re: [PATCH] Improve the clock-out message

[Rudolf Adamkovič]

Kévin Le Gouguec  writes:

> One question: should it be "before saving" or "before exiting"? [...]

I gave this some more thought, and you are right.  From the user's POV,
the question is *not* about saving but about clocking out.  Saving is
implied.  I updated the message, and the commit message too.

Ihor, if you are OK with this version, please merge. :)

Rudy
>From 10c80436b6ad02b7684394f25e7d60e529d95bd4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rudolf=20Adamkovi=C4=8D?= 
Date: Mon, 24 Feb 2025 13:19:46 +0100
Subject: [PATCH] org-clock: Improve the clock-out message

* lisp/org-clock.el (org-clock-kill-emacs-query): Reword "Clock out
and save?" to "Clock out before exiting?", as the "save?" part is
confusing: the user might think their file will not be saved, as in
"data loss", if they answer no.
---
 lisp/org-clock.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/org-clock.el b/lisp/org-clock.el
index 933c05487..d72ef4e29 100644
--- a/lisp/org-clock.el
+++ b/lisp/org-clock.el
@@ -3316,7 +3316,7 @@ The details of what will be saved are regulated by the variable
   "Query user when killing Emacs.
 This function is added to `kill-emacs-query-functions'."
   (let ((buf (org-clocking-buffer)))
-(when (and buf (yes-or-no-p "Clock out and save? "))
+(when (and buf (yes-or-no-p "Clock out before exiting? "))
   (with-current-buffer buf
 (org-clock-out)
 (save-buffer
-- 
2.39.5 (Apple Git-154)

-- 
"All you have to do is write one true sentence.  Write the truest
sentence that you know."  --- Ernest Miller Hemingway (1899-1961)

Rudolf Adamkovič  [he/him]
http://adamkovic.org

Re: [PATCH] cosmetic of begin/end lines

[Phil Estival]

* [2025-02-21 18:57 +] Ihor Radchenko :
> Phil Estival  writes:
>
>>> Does the attached diff fix the problem you are encountering?
>>
>> Yes it does. Thank you!
>>
>> But we are losing that previous possibility we had of a
>> bi-color display of meta lines, with the second part (past
>> the text of a meta line) being of the color of the block.
>
> That's an accidental feature. Just happen to work.
>
> Historically, we always used org-fontifiy-whole-block-delimiter-line = t.
> It became optional to fontify the newline to avoid underline extending
> too far. See https://yhetil.org/emacs-bugs/83d0hd8ceh@gnu.org/
>
> Looking at that discussion, it seems that it happened before :extend t
> face attribute got introduced into Emacs. Maybe we can get along with
> letting users set :extend t/nil in the face itself and deprecating
> org-fontify-whole-block-delimiter-line.
>

Ok, now everything is clear.

One more clarification though, I wrote "meta lines" instead of
"#+begin/end_src" but that was not exact, as "meta lines" covers
everything that starts with "#+".

> So, you want [remainder of the line] to be fontified differently from
> the rest of the #+begin_src ...?

Currently, the remainder of the line can either be default, part of
begin_src or part of the block body due to this accidental feature.

At first what I really wanted was to attenuate #+begin_src and to
underline the language but I ended up turning on prettify-symbols-mode
for the first and then, annoyed by the extend property being reset,
observed the situation and suggested the changes we've been discussing
about.

The question is: wouldn't it be a good design choice to keep the
possibility to emphasize source blocks in org and its exports like in
this fourth schema?

1)
   #+begin_src chicken
  ┌┐
  │ #; │
  │ #;   source│
  │ #; │
  └┘

2)
  ┌┐
  │#+begin_src chicken │
  ├┴───┐
  │ #; │
  │ #;   source│
  │ #; │
  └┘

3)
  ┌┐
  │#+begin_src chicken │
  ├┤
  │ #; │
  │ #;   source│
  │ #; │
  └┘

4)
  ┌─┬──┐
  │ #+begin_src chicken │  │
  ├─┘  │
  │ #; │
  │ #;   source│
  │ #; │
  └┘

Re: Failure of asynchronous org exports and poly-org

[Benjamin McMillan]

That seems to fix the problem, thanks Ihor!

(Probably irrelevent: The actual patch file did not work for me.
Rather, > git apply 00...patch errored "the patch does not apply", with
.rej files showing ? at end of each line.
But copying the diffs by hand into org files worked.)

On Sun, Feb 23, 2025 at 9:17 PM Ihor Radchenko  wrote:

> Benjamin McMillan  writes:
>
> > The org export backend is complicated compared to my debugging skills,
> but
> > I have been able to determin the following.
> > 1) The issue happens because of poly-org.
> > 2) It happens with -q and a minimal configuration (org + poly-org in
> init).
> > 3) It happens even exporting a minimal org file, like a heading "test"
> and
> > the text "a"
> > 4) It only happens with org-export-in-background t
> > 5) With org-export-async-debug t the error given in *Org Export Process*
> is
> > like:
> >Invalid read syntax: "#<", 6, 407
> > ...
>
> Thanks for reporting!
> Does the attached patch fix your problem?
>
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>

Re: ob-haskell has stopped working

[Lawrence Bottorff]

Where can I find an older haskell-mode? Not finding one...

On Mon, Feb 24, 2025 at 4:00 AM Aitenate  wrote:

> It sound like the same issue I've experienced [1]. Try using an older
> version of haskell-mode and it should workaround the problem.
>
> [1] - https://github.com/haskell/haskell-mode/issues/1867
>
> Regards,
> Aitenate
>


-- 
⨽
Lawrence Bottorff
Grand Marais, MN, USA
borg...@gmail.com

Re: [BUG] Incorrect LaTeX export when using images in a table to display them side-by-side. [9.7.5 (release_9.7.5 @ /home/dadinn/.emacs.d/straight/build/org/)]

[Pedro Andres Aranda Gutierrez]

PS.
a simple

```latex
This is \includegraphics{my-image.png] foo.
```
Can be even more disastrous, depending on the size of the image.

Best, /PA

On Mon, 24 Feb 2025 at 10:38, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> Hi,
> Answers inline...
>
> > El 23 feb 2025, a las 18:47, Ihor Radchenko 
> escribió:
> >
> > It is ok for standalone images, but is clearly broken when the image is
> > really inline - a part of paragraph or table cell in this case.
> >
> > Another example is
> >
> >   This is file:~/Downloads/wallpaper.png foo.
> >
> > which is exported as
> >
> >This is \begin{center}
> >
> \includegraphics[width=\linewidth]{/home/yantar92/Downloads/wallpaper.png}
> >\end{center} foo.
> >
> > Pedro, any ideas how to address this?
>
> Just to be clear, what is the intent of the org line?
> 1. Inlining a figure in a paragraph, with the image being as wide as the
> paragraph.
> 2. Having a smaller image, preceded by the “This is:’ and ended with the
> “foo” in the same line?
>
> For 2. You will have to play with the image’s size.
> If you mean 1. it will also depend on the image’s size. Playing with
> something equivalent, my wallpaper ;-) produces the same when exporting the
> line to PDF and to HTML.
>
> So, to start with, I’d rather leave ’the paragraph side' of the “problem”
> for further discussion and concentrate on the 'table side' (my previous
> message).
>
> Best, /PA
> >
> > --
> > Ihor Radchenko // yantar92,
> > Org mode maintainer,
> > Learn more about Org mode at .
> > Support Org development at ,
> > or support my work at 
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
Year 1 of the New Koprocracy

Re: PATCH: ox-latex table of contents patch consolidated (was: [BUG] Latex exporter should consider export settings [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)])

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

>> 2. I renamed need-alternative to need-toc. IMHO, it is a bit more
>> clear. I also updated the commentary to explain what is going on.
>
> I was thinking more in the line of need-alternative-p since all this comes 
> when we guess we need an alternative text in the ToC

I went with need-alternative-toc-title.
Applied, onto main, with amendments.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=35d12cddc7

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

Re: Common Lisp weird Babel's results.

[Héctor Galbis Sanchis]

> I think that the code is already an improvement.

Nice!

> May you convert it into a proper patch against the latest main?

Of course! I'll try to do it this weekend.

El sáb, 22 feb 2025 a las 16:52, Ihor Radchenko ()
escribió:

> Héctor Galbis Sanchis  writes:
>
> >>  #+RESULTS:
> >>  [[file:"plot.png"]]
> >>
> >>So, it is no so simple.
> >
> > I see. I've been looking at ob-emacs-lisp.el since elisp and common lisp
> > are very similar. So, checking if `scalar` or `verbatim` are used should
> be
> > sufficient. If some is being used then returns the result. Otherwise,
> strip
> > out the quotes.
>
> Makes sense.
>
> >>Why list? Maybe just return current-result as is?
> >
> > As the function is recursive, if it returns a non-list object It will be
> > creating a non-proper list.
>
> Right.
>
> > However, this version could be more clear:
>
> +1
>
> > I've been thinking about how scalar and verbatim should work and I end up
> > with the conclusion that we cannot use a function that change the
> separator
> > when using Sly. The reason is that using `read-from-string` can fail in a
> > lot of different scenarios. Every literal object whose representation in
> > Common Lisp differs from the representation in Emacs Lisp will fail. This
> > includes vectors, characters, or even symbols.
> > ...
>
> Indeed. `read-from-string' is simply a quick and dirty way to make
> things working without having to implement a dedicated CL reader.
>
> > Besides, regarding the separator ', ', the function that writes the
> results
> > is the next one:
> > ...
> > ```
> > (defun echo-for-emacs (values &optional (fn #'slynk-pprint))
> > ...
> >  (if (some #'(lambda (s) (find #\Newline s))
> >strings)
> >  (format nil "~{~a~^~%~}" strings)
> >  (format nil "~{~a~^, ~}" strings)))
> > ```
> >
> > Check out the last 4 lines. It is weird that they are printing newlines
> > only when a newline is in one of the values. It seems like they put the
> > `format` functions in the wrong order.
>
> I am not sure where this `echo-for-emacs' is coming from.
>
> > Another thing I don't understand is the use of
> > `org-babel-lisp-vector-to-list`. I mean, clearly it is used to let
> vectors
> > being readable by emacs lisp. But, consider this example:
> >...
> > ```
> > #+begin_src lisp
> >   "This is a vector in Common Lisp: #(1 2 3)"
> > #+end_src
> >
> > #+RESULTS:
> > : This is a vector in Common Lisp: (1 2 3)
> > ```
> >
> > This feels wrong to me. But maybe there is a case where this is
> necessary.
> > Clearly, this is up to you, but I'm curious about the reason of using
> > `org-babel-lisp-vector-to-list`.
>
> Well.
>
> (defun org-babel-lisp-vector-to-list (results)
>   "Convert #(...) values in RESULTS string into a (...) list."
>   ;; TODO: better would be to replace #(...) with [...]
>   (replace-regexp-in-string "#(" "(" results))
>
> and the relevant commit says
>
> ob-lisp: turning vector results into lists for easy elisp reading
>
> * lisp/ob-lisp.el (org-babel-execute:lisp): Turn vectors into lists
>   before reading by elisp
>   (org-bable-lisp-vector-to-list): Stub of a vector->list function,
>   should be replaced with a cl-vector->el-vector function.
>
> In other words, this whole thing is a workaround to make
> `read-from-string' work a bit better yet without implementing a
> dedicated CL reader.
>
> > Lastly, this is the code I have right now:
>
> Thanks!
> I think that the code is already an improvement.
> May you convert it into a proper patch against the latest main?
> See https://orgmode.org/worg/org-contribute.html#first-patch
>
> > ```
> > (defun org-babel-read-lisp-values (result)
> >   "Parse RESULT as a sequence of values.
> >
> > RESULT is a string containing one or more Lisp values, optionally
> > separated by commas. The function reads each expression sequentially
> > and returns the parsed values as a list."
> >   (if (string-empty-p result)
> >   nil
> > (let* ((r (read-from-string result))
> >(current-result (car r))
> >(next-char (cdr r))
> >(rest-result (if (< next-char (length result))
> > (if (char-equal (aref result next-char) ?\,)
> > (substring result (+ next-char 2))
> >   (substring result (1+ next-char)))
> >   (substring result next-char
> >   (cons current-result (org-babel-read-lisp-values rest-result)
> >
> > (defun org-babel-execute:lisp (body params)
> >   "Execute a block of Common Lisp code with Babel.
> > BODY is the contents of the block, as a string.  PARAMS is
> > a property list containing the parameters of the block."
> >   (let (eval-and-grab-output)
> > (pcase org-babel-lisp-eval-fn
> >   (`slime-eval (org-require-package 'slime "SLIME")
> >(setq eval-and-grab-output
> 'swank:eval-and-grab-output))
> >   (`sly-eval

Re: org-toggle-timestamp-overlays fails to remove display property

[Ihor Radchenko]

> $ emacs -q --eval "(add-to-list 'load-path 
> \"/Users/jhemann/.emacs.d/straight/repos/org/lisp\")"
>
> M-x org-mode
> M-x calendar
> M-x other-window
> M-x org-date-from-calendar
> M-x previous-line
> M-x org-toggle-time-stamp-overlays
> M-x org-toggle-time-stamp-overlays
> M-x org-version
> ```
>
> You should see the display property remains after the toggle. I get

Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0b1f335172

Re: [BUG] Warning: org-element-cache [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.4/lisp/org/)]

[Ihor Radchenko]

Ting Boon Ghee  writes:

> My OS is Debian Testing (trixie). The Org package I am using is the
> built-in one that comes with Emacs 29.4. So upgrades will depend on
> Debian.

Fair enough.
Canceled.

> I think the warning pops up when I inserted a heading using M-RET. Other
> than the warning, I do not see any visible problem. It happened a few
> times. I am reporting only because the warning message said so. I guess
> it may have been resolved in later versions.

That's what I tried to figure out :)
In any case, thanks for reporting! That warning is there to find the
remaining rare bugs in asynchronous code.

Note that you should be able to suppress the warning by clicking on ⛔
with mouse.

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

Re: Failure of asynchronous org exports and poly-org

[Ihor Radchenko]

Benjamin McMillan  writes:

> That seems to fix the problem, thanks Ihor!

Fixed, on main.
Applied.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0cbf8817f9

> (Probably irrelevent: The actual patch file did not work for me.
> Rather, > git apply 00...patch errored "the patch does not apply", with
> .rej files showing ? at end of each line.
> But copying the diffs by hand into org files worked.)

Maybe some problem with windows/linux newlines. Or your email client
"fixing" newlines in the attachment.

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