Re: Yesterday's meetup

[Pedro Andres Aranda Gutierrez]

Hi again.
The change may need a bit more thinking:

When testing, I got

FAILED  test-org-export/get-inbuffer-options
((should (equal
 (org-test-with-temp-text (format "#+DESCRIPTION: l1\n#+LANGUAGE:
es\n#+SELECT_TAGS: a\n#+TITLE: a\n#+SETUPFILE:
\"%s/examples/setupfile.org\"\n#+LANGUAGE: fr\n#+SELECT_TAGS:
c\n#+TITLE: c" org-test-dir) (org-export--get-inbuffer-options))
'(:languages ("fr") :select-tags ("a" "b" "c") :title ("a b c"
:form (equal (:languages ("es" "en" "fr")
select-tags ("a" "b" "c") :title (#("a b c" 0 1 (:parent #3) 1 2
(:parent #3) 2 3 (:parent #3) 3 4 (:parent #3) 4 5 (:parent #3
(:languages ("fr") :select-tags ("a" "b" "c") :title ("a b c")))
:value nil :explanation (list-elt 1 (proper-lists-of-different-length
3 1 ("es" "en" "fr") ("fr") first-mismatch-at 0)))

(org-export--get-inbuffer-options) seems to be collecting all
languages in :languages and the :language fix doesn't seem to be
enough

best, /PA

On Sun, 20 Jul 2025 at 07:51, Pedro Andres Aranda Gutierrez
 wrote:
>
> No worries. In a group with native and non-native speakers, it is
> always the case that we all need clarifications.
> That been part of my life since I was 3 ;-)
> Add to this "life" and it is more than possible that someone (in this
> case yours truely) reads more into a message that there really is,
> so I may have read the options list in ox-latex.el into your answer.
>
> So it's not a matter of being right or wrong, it's more about
> synchronising before the black-out occurs ;-)
>
> I'll push the change is a couple of minutes.
> best, /PA
>
> On Sun, 20 Jul 2025 at 07:41, Ihor Radchenko  wrote:
> >
> > Pedro Andres Aranda Gutierrez  writes:
> >
> > > Just to clarify. Your initial suggestion was having :languages in
> > > LaTeX only and use :language for the first and :languages for all.
> > > Now you want to have this behaviour for all backends (except that the
> > > others only use :language FTMB).
> >
> > Likely not.
> > My suggestion was
> > https://list.orgmode.org/orgmode/877c0t2kze.fsf@localhost/
> > I meant changing ox.el and `org-export-options-alist' from the very
> > beginning. Sorry, if it was not clear enough.
> >
> > > So I just change the entry, all backends allow more than one language
> > > in #+LANGUAGE (at least in theory).
> >
> > Yes.
> >
> > > Thanks for any enlightenment, /PA
> >
> > To be clear, I may be (and sometimes am) wrong. But I try my best to be
> > consistent and explain everything I suggest or the reasons I change my
> > mind.
> >
> > --
> > 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
>
> Sagen's Paradeiser, write BE!
> Year 1 of the New Koprocracy



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

Sagen's Paradeiser, write BE!
Year 1 of the New Koprocracy

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

[Ihor Radchenko]

Ihor Radchenko  writes:

>> The test creates a `src' block with the language set to `any-language'.
>> It passes with that fake language, but when I change it to something
>> real, such as `c' or `fundamental', the indentation is incorrect, and
>> the test fails.
>
> I can reproduce.
> The test is indeed not correct.
> src block in the test should not have "-i" flag. It is exactly what is
> making the test fail. (AFAIU)

I fixed the test and then applied your patches on top of that.
I also amended if-let to become if-let*. The former is obsolete on Emacs
master.
Applied, onto main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1bec6a36f
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=cb7bcfdca
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=8ef67956d

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

Re: [PATCH][Worg] publish.sh: Suppress subscripts without braces

[Max Nikulin]

On 17/07/2025 16:02, Christian Moe wrote:

Max Nikulin writes:


I have noticed another case when "latex" in "#+begin_latex" is
rendered as subscript in a Worg article. Do you expect massive
regressions if subscript without explicit curly braces are suppressed?

[...]

org-contrib/babel/examples/drift.org:  be the proportion of red individuals. So 
X_1 is 6 and p_1 is 0.6. To
org-contrib/babel/examples/drift.org:  individual. So X_2 is a /binomial/ 
random variable, with 10 trials and


Must be typed as \(X_1\), \(p_1\), and \(X_2\) to use proper font (italics).


org-hacks.org:hydrometer correction, abv calculation, priming sugar for a given 
CO_2


This is a better example when subscript should be outside of LaTeX 
fragment. I do not like that the manual contains an example with math 
typed in plain text


(info "(org) Subscripts and Superscripts")


#+begin_example
exporters/freemind.org:out release_7.9.4/
exporters/xoxo.org:out release_7.9.4/
#+end_example


Thanks for fixing it.


So the objection I have is not about regressions, but about which
writing norm to require. I don't think there's a strong reason why
people should have to write =CO_{2}= instead of =CO_2=. And there's no
good reason for writing "release_7.9.4" in the above examples.


I think, it is acceptable to type "CO_{2}". However I would prefer to 
recommend contributors to set ^:t for specific file to override 
defaults. The file with "CO_2" has explicit "#+OPTIONS: ^:t"



However, there /is/ a good reason for the convention that one should use
verbatim markers when quoting keywords like =#+begin_src=. Failure to do
should be fixed, and export with subscripts is a useful tripwire that
should ideally help us to catch it.


My goal is to make formatting better for visitors. Mistakes during 
editing of articles are unavoidable.


I think, the only way to find all improper use of sub/super-scripts is 
to run org-element parser with t setting for all files and to report 
found subscripts.



Whether or not we change the default, it might be a good idea to note
it in worg-editing.org.


I agree, but some decision is required before.

Re: Users of org-publish

[Max Nikulin]

On 19/07/2025 19:32, Ihor Radchenko wrote:

Also, note thathttps://orgmode.org/ andhttps://orgmode.org/worg/ are
generated using publishing system 🙂


Worg uses custom elisp code for export that iterates over .org files, 
see publish.sh. Current CI does not allow persistent state required for 
stable cross-reference links. From build logs:



[exporting] index.org
Reference "*Org-mode on mobile devices" in file "org-faq.org" cannot be 
resolved without publishing
Reference "*Personal Web Sites" in file "org-web.org" cannot be resolved 
without publishing

Re: [BUG] Tags following a timestamp does not work.

[Ihor Radchenko]

Miki Kawabe  writes:

> I'm wondering if it's allowed to use both timestamp and tag in the same 
> headline in Org mode.
> Although I read the manual on Tags and Timestamps, I couldn't find any 
> explanation for these limitation.
>
> org-open-at-point does not work for tags, when the tags are following a 
> timestamp.
>
> Example
>
> * Headline <2020-04-01>:tag1:
> tag1 is "no found link". Is this a bug ?
> ...

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=791c2285e

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

Re: [BUG] Error about org-link-types when creating a link [9.7.31 (9.7.31-4e6d38 @ /home/dsmasterson/.emacs.d/elpa/org-9.7.31/)]

[Ihor Radchenko]

David Masterson  writes:

> When trying to create a link in an Org file, I get the following errors
> immediately after typing '[['.  I can continue filling in the link and
> autocomplete kicks in fine as I am typing the link.  When closing the
> link with ']]', the link is collapsed properly.  What is the error
> trying to tell me?  A problem with the "org-ac" package?
>
> No completions
> ac-candidates-1: Symbol’s value as variable is void: org-link-types
> No completions
> Error running timer ‘ac-update-greedy’: (void-variable org-link-types)

org-oc has

(defun org-ac--get-link-head-candidates ()
  (append (ac-pcmp/get-ac-candidates)
  (mapcar (lambda (x) (concat x ":")) org-link-types)))

But there is no such variable in Org mode - `org-link-types'. There is a
*function*. Bug in org-ac.
Please report there.

Canceled.

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

Re: [BUG] Error about org-link-types when creating a link [9.7.31 (9.7.31-4e6d38 @ /home/dsmasterson/.emacs.d/elpa/org-9.7.31/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> But there is no such variable in Org mode - `org-link-types'. There is a
> *function*. Bug in org-ac.

Looks like there used to be such variable long time ago.
But it has been removed in
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9bc294003
9 years ago.

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

Re: [PATCH] org-protocol.org: Add history section (was: Re: [PATCH v5] WORG Org Protocol Page Rewrite)

[Max Nikulin]

On 15/07/2025 19:26, Christian Moe wrote:


I've drafted a history section, attached here as a patch.


Great work. I had only a part of added links in my notes.


+make the code easier to maintain and offer more options, Carsten
+Dominik 
[[https://list.orgmode.org/orgmode/c46f10dc-de51-43d4-affe-f71e440d1...@gmail.com/][rewrote
 and renamed it]] as the independent =org-capture.el=
+module (Org version 
[[https://list.orgmode.org/87bolcr957@altern.org/][7.8.11]], 2010). 
Accordingly, the Org protocol


org-capture.el was released in 7.01



Carsten Dominik. Org-mode release 7.01. Mon, 19 Jul 2010 08:43:23 +0200

From my point of view, it would be easier to review changes if thread 
subjects and dates were added as inline comments (do not use # comments, 
they break paragraphs)


Dominik 
[[https://list.orgmode.org/orgmode/c46f10dc-de51-43d4-affe-f71e440d1...@gmail.com/][rewrote 
and renamed it]] @@comment:
New implementation of the Org remember process ready for comments and 
testing.

Tue, 22 Jun 2010 14:36:15 +0200
@@ as the

or if mail messages were referenced using footnotes with sender, 
subject, and timestamp:


[fn::Carsten Dominic.
New implementation of the Org remember process ready for comments and 
testing.
[[https://list.orgmode.org/orgmode/c46f10dc-de51-43d4-affe-f71e440d1...@gmail.com][Tue, 
22 Jun 2010 14:36:15 +0200]]]

Re: [BUG] org-edit-src-code with code argument is broken

[Ihor Radchenko]

hiecaq  writes:

> 1. `emacs -Q temp.org`, with the following content:
> --8<---cut here---start->8---
> #+begin_src emacs-lisp
> #+end_src
> --8<---cut here---end--->8---
>
> 2. Put cursor on the block and `M-:`, in eval type 
> `(org-edit-src-code "'()")` and RET, the edit buffer shows up with 
> the content `'()`, but...
>
> Actual behavior:
> 1. The edit buffer is read only
> 2. `M-x org-edit-src-exit` close the edit buffer as intended, but 
> it does not insert `'()` back into the org mode buffer.
>
> Expect behavior:
> 1. The edit buffer should not be read only
> 2. Even if the edit buffer is not edited afterwards, `M-x 
> org-edit-src-exit` should insert its content back to the org mode 
> buffer.

What you observe is intentional.
The commit that introduced this feature says the following:

https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d1b8b347f

Allow org-src edit buffer to be used in read-only mode

org-edit-src-code gains extra optional arguments `code' and
`edit-buffer-name'. If `code' is supplied, then this code forms the
contents of the edit buffer, which is made read-only. In this case,
the mechanisms for writing back to the org buffer on save are
disabled.

Optional argument `edit-buffer-name' allows a name for the edit buffer
to be supplied.

The docstring is not accurate.

To fix this, we can either:
1. Fix the docstring and call it done
2. Allow the buffer to be editable. Although, I do not fully understand
   why the read-only has been introduced to start with. (And I cannot
   find anything in the mailing list archives)

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

Re: [BUG] org-capture with file+olp target matches todo keywords case insensitively

[Ihor Radchenko]

Lewis Baker  writes:

> The problem is that org-find-olp does not set case-fold-search to nil and
> so the regular expression matching performs a case-insensitive match.
> ...
> This should be reproducible by running:
>
> (setq org-capture-templates
>   '(("t" "Do today" entry
>  (file+olp "daily.org" "Today")
>  "* TODO %?")
> ("m" "Maybe do today" entry
>  (file+olp "daily.org" "Maybe Today")
>  "* TODO %?")))
> (setq org-todo-keywords
>   '((sequence "TODO(t)" "MAYBE(m)" "|" "DONE(d)")))
>
> And then creating a daily.org file that contains the following contents:
> * Today
> * Maybe Today
>
> And then running (org-capture nil "t")

Confirmed.

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

Re: [BUG] org-capture--fill-template side-effect can occasionally cause org-roam-capture to fail to find file+head+olp target

[Ihor Radchenko]

Lewis Baker  writes:

> In org-capture--fill-template there is a section that creates a new buffer
> named "*Capture*" and then activates this buffer so that it can insert the
> template and perform various regexp search/replace operations on the
> placeholders. However, the activation of this temporary buffer is performed
> using (switch-to-buffer-other-window (get-buffer-create "*Capture*")) which
> internally ends up dispatching to (display-buffer).
>
> The problem with this is that it can modify the window layout, which can
> cause existing windows to be resized, even if only temporarily. When a
> window is resized, this can in turn cause (point) in the displayed buffer
> to be changed so that (point) remains on-screen.
> ...

Sounds plausible.

> I managed to fix the behaviour locally by applying the following change to
> org-capture--fill-template:
>
> --- a/lisp/org-capture.el
> +++ b/lisp/org-capture.el
> @@ -1696,7 +1696,7 @@ Expansion occurs in a temporary Org mode buffer."
>(message "no template") (ding)
>(sit-for 1))
>  (save-window-excursion
> -  (switch-to-buffer-other-window (get-buffer-create "*Capture*"))
> +  (set-buffer (get-buffer-create "*Capture*"))
>(erase-buffer)
>(setq buffer-file-name nil)
>(setq mark-active nil)
>
> This activates the buffer without changing the window layout.
> Does this change/fix seem reasonable?
>
> I suspect that the (save-window-excursion) should probably also be changed
> to a (save-excursion), but was unable to convince myself so far that there
> weren't other window-affecting operations in there.

AFAIK, `switch-to-buffer-other-window' there is intentional.
In particular, it is useful when the template expansion involves
interactive prompt where we want the user to see the current state of
*Capture* buffer and also the original window where the capture command
was called.

I think that the best we can do here on Org side is to document this
potential pitfall.

Tentative patch attached.

>From b4e21345770183f7263ba523178fd86e77db8081 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Sun, 20 Jul 2025 13:52:25 +0200
Subject: [PATCH] org-capture-fill-template: Clarify that point may move as a
 side effect

* lisp/org-capture.el (org-capture-fill-template): Update the
docstring, warning that calling the function might lead to point
moving in displayed buffers.

Reported-by: Lewis Baker 
Link: https://orgmode.org/list/calqfjj6gmrqkgxksv7bk4h6yrwwilmsv2-e1zz+gd6y-_oa...@mail.gmail.com
---
 lisp/org-capture.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/org-capture.el b/lisp/org-capture.el
index 02a1ea833..580bf5f19 100644
--- a/lisp/org-capture.el
+++ b/lisp/org-capture.el
@@ -1714,7 +1714,10 @@ (defun org-capture-fill-template (&optional template initial annotation)
 INITIAL content and/or ANNOTATION may be specified, but will be overridden
 by their respective `org-store-link-plist' properties if present.
 
-Expansion occurs in a temporary Org mode buffer."
+Expansion occurs in a temporary Org mode buffer that will be displayed
+if the template expansion triggers user prompt.  Beware that displaying
+the temporary buffer may alter point position in the already displayed
+buffers."
   (let* ((template (or template (org-capture-get :template)))
 	 (buffer (org-capture-get :buffer))
 	 (file (buffer-file-name (or (buffer-base-buffer buffer) buffer)))
-- 
2.50.1


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

[FR] Org export: expanding links to included files (was: [BUG] Export backend cross-references are broken [9.7.30 (release_9.7.30 @ /home/user/org-mode-git/lisp/)])

[Ihor Radchenko]

Louis Vigneras  writes:

> Following yantar92’s suggestion on the matrix channel, I am reporting 
> here what appears to be a bug.
>
> I have an index.org file with the following:
> #+include: chapter-1.org
> #+include: chapter-2.org
>
> In chapter-1.org I have the following:
> * Heading
> [[file:chapter-2.org::*Heading 1][Link to heading 1]]
>
> In chapter-2.org I have the following:
> * Heading 1
>
> Text
>
> When exporting to both PDF and HTML, links are rendered as follows:
>
> ```latex
> \href{chapter-2.org}{Link to heading 1}
> ...

I checked the sources, and it is not a bug. Rather a missing feature.

> I believe the expected behavior should output links referring to 
> headings of the output document. It should not refer to the org file for 
> the PDF output, nor the chapter-2.html file for the HTML output as it 
> only produces an index.html file.

I agree that it would be expected.
On the other hand, it would not be trivial to implement.
Consider, for example,
#+include: chapter-1.org
#+include: chapter-2.org :lines 2-20

What should we do in such situation?

In addition, there could be duplicates in heading names and a link that
would otherwise be unique as  may no
longer be, after we include multiple files, if another included file
also contains * Heading 1.

Note also that the reference is not broken - the reference should still
be valid.

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

renumbering chapters

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi folks.

I've written a book and just created a new chapter by splitting one in half.

They are numbered Chapter 1, Chapter 2, etc, and they're all level one headings.

So how can I auto-renumber them please?
  
Thanks
  Sharon Kimble.  
- -- 
A taste of linux = http://www.sharons.org.uk
TGmeds = http://www.tgmeds.org.uk
DrugFacts = https://www.drugfacts.org.uk
So you want to write a book ... = https://sharonmk.co.uk
Debian 12.11, Fluxbox 1.3.7, emacs 31.0.50, org 9.7.31 
-BEGIN PGP SIGNATURE-

iQJRBAEBCgA7FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmh86ygdHGJvdWRpY2Nh
c0Bza2ltYmxlMDkucGx1cy5jb20ACgkQNoGAGQr4g1uzyA/9Hq0BpeSUol+XxAMa
EeufTnFVTslKZdnSA61xVV8j+Mdh8szQnUvD+Fm7dpj9hVS1wd22y7+aTmyYkyn9
iSOPPSrb9oIVK0Xn7/Ku8fekaubeOTJbcHwA1hczgUOV/GIPVWqsFVQFAI81pKk6
gfEFt5ZtkD7MjpXw3+bjb82/OSMRwq3O0JOP6i7l+TAPd7uHehTwLdUBFLtU4+wP
NQv7FMdI+Xh6vF8VVOJo+ayraKqw1kZ+Sjgp8rQBzevwT45YYlxJV7KJUGjnR3qB
YTT1/3sejuETit/Fsrn5HNn9pg7s7ksx2uoiRKB74IorU/OUUoSJzggapjhpolYp
F6qjozT1XxFM8lLoFHlTiw4t9NW6UPoWGv3vGkgqdoQXbJP7hgTqe2Kq1VnhLtCH
7MnHmEybVobdGq9Lc1Gvmj+BRsbD7LyDsrQy6c8ngRxr+oP+HODnzTN4ySsEwHKh
jrf0noHe2ccLc0z840SLG0ELbAexZSR/UC6w1+2TXwhJ4fj1sUVBSGrfZVg2/TR4
yXDoTaXpZQ21Pmw8zbG0GoWH0icVmEg9GltE+PonmcGYbfGgKt1y89PBQ50LAhmA
xGfmLstSdgx6QRxWiA4TSQ5NKPzlHPXWwXaZRGvWwDRhMQE2izMshkbD8cp1LZdd
8eO3WeqW4pxYtnhpVD6E2+9S7/M=
=ekZy
-END PGP SIGNATURE-

Re: [BUG] reveal-mode and org-mode incompatibility

[Ihor Radchenko]

Brett  writes:

> Create a 3-line file named foobar.org containing exactly this:
> ...
> ...
> But now, pressing TAB does nothing, while it should unfold the second
> heading.  In fact, moving around, folding/unfolding the first heading, etc,
> will never fix the now broken TAB: from now on, if "** bar" is folded and
> point is at the beginning of it, TAB will not unfold it (though C-e will).

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

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

Re: org-refile confusing refiling

[Ihor Radchenko]

jman  writes:

> I don't have the context to figure out things further, all I could do was 
> disabling xclip-mode 
> around executing `org-refile`:
>
> --8<---cut here---start->8---
> ;; disable xclip-mode before executing org-refile
> (advice-add 'org-refile :before (lambda (&rest _)
>  (when xclip-mode
>(xclip-mode -1
>
> ;; enable xclip-mode again after executing org-refile
> (advice-add 'org-refile :after (lambda (&rest _)
>  (when (not xclip-mode)
>(xclip-mode t
> --8<---cut here---end--->8---
>
> Ihor, any thoughts on this?

Can you try the attached patch?
>From a75e575a0ae8172d0d50c738d67b36f518ad5f98 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Sun, 20 Jul 2025 15:30:33 +0200
Subject: [PATCH] org-refile: Do not assume that kill ring cannot change under
 our feet

* lisp/org-refile.el (org-refile): Store region to be refiled in
variable rather than relying upon it being held as the first entry in
the kill ring.

Reported-by: jman 
Link: https://orgmode.org/list/87msaxsn6c@city17.xyz
---
 lisp/org-refile.el | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/lisp/org-refile.el b/lisp/org-refile.el
index 5caed50a6..4bca6ee85 100644
--- a/lisp/org-refile.el
+++ b/lisp/org-refile.el
@@ -484,7 +484,7 @@ (defun org-refile (&optional arg default-buffer rfloc msg)
 	   (region-start (and regionp (region-beginning)))
 	   (region-end (and regionp (region-end)))
 	   (org-refile-keep (if (equal arg 3) t org-refile-keep))
-	   pos it nbuf file level reversed)
+	   pos it nbuf file level reversed tree)
   (setq last-command nil)
   (when regionp
 	(goto-char region-start)
@@ -557,6 +557,9 @@ (defun org-refile (&optional arg default-buffer rfloc msg)
 		  (org-kill-new (buffer-substring region-start region-end))
 		  (org-save-markers-in-region region-start region-end))
 	  (org-copy-subtree 1 nil t))
+;; We cannot rely on the kill remaining intact before we
+;; paste.  See https://orgmode.org/list/87msaxsn6c@city17.xyz
+(setq tree (current-kill 0))
 (let ((origin (point-marker)))
   ;; Handle special case when we refile to exactly same
   ;; location with tree promotion/demotion.  Point marker
@@ -583,7 +586,7 @@ (defun org-refile (&optional arg default-buffer rfloc msg)
 		 (goto-char (point-min))
 		 (or (outline-next-heading) (goto-char (point-max)
 	 (unless (bolp) (newline))
-	 (org-paste-subtree level nil nil t)
+	 (org-paste-subtree level tree nil t)
 	 ;; Record information, according to `org-log-refile'.
 	 ;; Do not prompt for a note when refiling multiple
 	 ;; headlines, however.  Simply add a time stamp.
-- 
2.50.1


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

Re: [BUG] (Experimental LaTeX preview) org-persist-write-all causes Emacs to close very slowly [9.8-pre (cd2269ddb @ c:/Users//.emacs.d/straight/build/org/)]

[Ihor Radchenko]

Kai Bagley via "General discussions about Org-mode."
 writes:

> After installing and using the org latex preview experimental features
> according to https://abode.karthinks.com/org-latex-preview/, I get
> severe freezing when closing Emacs, due to the `org-persist-write-all`
> function in the `kill-emacs-hook`. I write a lot of math, so I have a
> significant number of LaTeX fragments in my =~/.cache/org-persist=.

Could you please record and share a profile if you call
org-persist-write-all manually?
See https://orgmode.org/manual/Feedback.html#How-to-profile-Org-performance-1

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

Re: question about latex export and title

[Ihor Radchenko]

Przemysław Kamiński  writes:

> ...
> This worked well for many months. However, sometime around April 2025 I 
> have my PDF files containing a TITLE which is some kind of 
> concatenation of current file name and the template-defined #+TITLE.
> ...
> However, when I have these 2 files:
>
> <2025-06.org>
>
> #+INCLUDE "template.org"
>
> 
>
> #+TITLE: template
>
>
> Then the PDF title on 2025-06.pdf is: "2025-06 template", i.e. main 
> file name gets prepended.

This is expected. According to Org manual section 13.2 Export Settings:

‘TITLE’
 Org displays this title.  For long titles, use multiple ‘#+TITLE’
 lines.

In other words, Org mode concatenates multiple #+TITLE lines together
into a single title.

Why not simply removing #+TITLE from the template or include the
template partially?

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

Re: [BUG] Error "Marker does not point anywhere" in Emacs 30.1 after export source block in latex or pdf [9.7.11 (release_9.7.11 @ /opt/homebrew/Cellar/emacs-plus@30/30.1/share/emacs/30.1/lisp/org/)]

[Ihor Radchenko]

Иван Чижов  writes:

> You need to do the following to reproduce the problem.
> ...
> ...
> 5. In the file.org put the cursor in the source block and press C-c
>  '. You will get the error message "Marker does not point anywhere" and
>  the buffer will not open.

Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=da69c444c

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

Re: Org mode version 9.8-pre (9.8-pre-n/a-g5b419c @ ~/.config/emacs/elpaca/builds/org/); org-persist: merging with disk file fails. Incorrect usage of cl-set-difference?

[Ihor Radchenko]

Umar Ahmad  writes:

> I've recently started facing some issues where all org files refuse to
> load with the error message:
> ```
> Debugger entered--Lisp error: (wrong-number-of-arguments # org-persist--find-index> 2)
> ```
> I think the culprit is the use of cl-set-difference with
> org-persist--find-index as the :test function.
> Since the :test function (like `equal`) is expected to take two
> objects to compare and the org-persist--find-index takes a single
> argument

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dabf68258

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

Re: [BUG] Given timestamp with repeater, then it gets broken when it is manually updated [9.6.15 (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Diego Ezequiel Vommaro  writes:

> SCHEDULED timestamp gets broken when I update it manually if it has a
> repeater:
>
> 1. Given an entry like this
>  TODO do something
>  SCHEDULED: <2025-07-04 Fri .+1d>
>
> 2. Then I move forward the date manually
>  SCHEDULED: <2025-07-05 Fri .+1d>
>
> 3. Then I press C-c C-c to get day name updated too
>
> 4. Results:
>  the whole date is updated as expected -> SCHEDULED: <2025-07-05 Sat .+1d>
>
>  but timestamp is no longer highlighted. To recover it, I have to 
> revert-buffer.

I am unable to reproduce.
What if you try with emacs -Q?
See https://orgmode.org/manual/Feedback.html#Feedback

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

Re: org element bug filling

[Samuel Wales]

i got the error upon scroll-up-command.

[i am not sure if i was in the buffer being reported on for sure, but
i always have only one window, so if so, it woudl be oerhaps strange
that it would try to font lock something not visible.  one thing that
would help is if th4e warnings buffer could contain timestamps, so i
can know whether the previous warning was just recent or not.]

i set teh variables and tried to repro and was not able to.

here is the entire warnings buffer, for recent.  i think there are 2
warnings in it.

⛔ Warning (org-element): org-element--cache: Org parser error in
prompt-blob.org::52956. Resetting.
 The error was: (error "Invalid search bound (wrong side of point)")
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point()
  org-adaptive-fill-function()
  fill-match-adaptive-prefix()
  fill-context-prefix(52956 52985)
  visual-wrap-fill-context-prefix(52956 52985)
  visual-wrap-prefix-function(52956 52986)
  #f(compiled-function (fun) #)(visual-wrap-prefix-function)
  jit-lock--run-functions(52956 52986)
  jit-lock-fontify-now(52956 53766)
  jit-lock-function(52956)
  redisplay_internal\\ \\(C\\ function\\)()
"
 Please report this to Org mode mailing list (M-x org-submit-bug-report).
⛔ Warning (org-element): org-element--cache: Org parser error in
executive--a.org::150096. Resetting.
 The error was: (wrong-type-argument integer-or-marker-p nil)
 Backtrace:
"  backtrace-to-string(nil)
  org-element-at-point()
  org-adaptive-fill-function()
  fill-match-adaptive-prefix()
  fill-context-prefix(150096 150155)
  visual-wrap-fill-context-prefix(150096 150155)
  visual-wrap-prefix-function(150096 151596)
  #f(compiled-function (fun) #)(visual-wrap-prefix-function)
  jit-lock--run-functions(150096 151596)
  jit-lock-fontify-now(150096 151596)
  jit-lock-function(150096)
  redisplay_internal\\ \\(C\\ function\\)()
"
 Please report this to Org mode mailing list (M-x org-submit-bug-report).

On Sun, Jul 20, 2025 at 4:15 PM Samuel Wales  wrote:
>
> i will try, but i doubt that i wil be able to retrigger immediately
> aft4r the first trigger.
>
> On Sun, Jul 20, 2025 at 8:04 AM Ihor Radchenko  wrote:
> >
> > Samuel Wales  writes:
> >
> > > ⛔ Warning (org-element): org-element--cache: Org parser error in
> > > fix.org::22506. Resetting.
> > >  The error was: (wrong-type-argument integer-or-marker-p nil)
> > >  Backtrace:
> > > "  backtrace-to-string(nil)
> > >   org-element-at-point()
> > >   org-adaptive-fill-function()
> > >   fill-match-adaptive-prefix()
> > >   fill-context-prefix(22506 22558)
> > >   visual-wrap-fill-context-prefix(22506 22558)
> > >   visual-wrap-prefix-function(22557 22558)
> > >   #f(compiled-function (fun) # > > 0x1baff79c90b670bf>)(visual-wrap-prefix-function)
> > >   jit-lock--run-functions(22557 22558)
> > >   jit-lock-fontify-now(22557 24057)
> > >   jit-lock-function(22557)
> > >   redisplay_internal\\ \\(C\\ function\\)()
> > > "
> > >  Please report this to Org mode mailing list (M-x org-submit-bug-report).
> >
> > When this happens, could you evaluate
> > (setq backtrace-on-redisplay-error t)
> > (setq debug-on-error t)
> > and try to trigger again?
> > This should give more meaningful backtrace in *Redisplay-trace* buffer.
> >
> > --
> > Ihor Radchenko // yantar92,
> > Org mode maintainer,
> > Learn more about Org mode at .
> > Support Org development at ,
> > or support my work at 
>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com



-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Modifying org-mode links

[Heime]

Have been using the general link format to make internal links
for use with the mouse.

[[LINK][DESCRIPTION]]

But then, how can I see it in its original text.  I find it
difficult to modify it when I use the delete key to remove 
the first "[".

Re: [BUG] Exporting an org buffer from the source editor breaks editing

[Ihor Radchenko]

"Jacob S. Gordon"  writes:

> After exporting an `org` buffer in the editor of a source block, I
> find that `org-edit-special` stops working in some places. To
> reproduce:
>...
> ...
> 5. At this point `org-edit-special` fails on the source blocks and
>`LaTeX` equation with message “Marker does not point anywhere”.
>Editing the table formula still works.

Duplicate of 
https://list.orgmode.org/orgmode/CACKynC_Kmezc6wT8ia=tkemrbO5+6fRyfgyQdOE7zfiidA=d...@mail.gmail.com/
Fixed.

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

Re: org-open-at-point fails to open files externally with double prefix

[Ihor Radchenko]

Max Nikulin  writes:

>> https://list.orgmode.org/t7aqif$c2f$1...@ciao.gmane.io/
>> [PATCH] org.el: Use `call-process' to launch external viewers (was: Re: 
>> [BUG] org-open-file immediately termininates when calling xdg-open that 
>> calls emacsclient).
>> Fri, 3 Jun 2022 00:04:12 +0700
>> 
>> Comments should be updated.
>
> The question is which way switching to `call-process' may affect macOS 
> and Windows users. (I am in doubts if anybody opens file from Org while 
> using DOS.) Are there Windows users who have something besides 
> system/default in `org-file-apps'? Certainly error handling becomes 
> completely impossible.
> ...
> The main question is effect of the patch on macOS, other complications 
> may be postponed.

What about updating your patch to only use `call-process' on gnu systems
and fallback to the existing code otherwise?

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

Re: [BUG] org-mode warning [9.7.11 (release_9.7.11 @ c:/bin/emacs/emacs/share/emacs/30.1/lisp/org/)]

[Ihor Radchenko]

Adrian Chira  writes:

> Emacs  : GNU Emacs 30.1 (build 2, x86_64-w64-mingw32)
>  of 2025-02-23
> Package: Org mode version 9.7.11 (release_9.7.11 @
> c:/bin/emacs/emacs/share/emacs/30.1/lisp/org/)
> ...
>  org--warnings '("org-element--cache: Org parser error in all.org::165185.
> Resetting.\n The error was: (wrong-type-argument integer-or-marker-p nil)\n
> Backtrace:\nnil\n Please report this to Org mode mailing list (M-x
> org-submit-bug-report).")

Thanks for reporting!
Do you see this warning frequently?

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

Re: org-persist causes delay when terminating emacs

[Ihor Radchenko]

mahmood sheikh  writes:

> this is related to
> https://lists.gnu.org/archive/html/emacs-orgmode/2025-03/msg00166.html
> i make heavy usage of the new org-latex-preview (not sure if its related)
> the profiler report upon exiting (using `(add-hook 'kill-emacs-hook 'debug
> 99)`) is included in this email.
> this isnt new, but i couldnt possibly say since when the issue started.
> thanks

Thanks for the report!
Unfortunately, it does not reveal anything new.
Note that we installed a couple of improvements onto Org main branch as
a result of the referenced thread.

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

Re: Org mode version 9.8-pre (9.8-pre-n/a-g5b419c @ /Users/tsujp/.config/emacs/elpaca/builds/org/); Org parser error

[Ihor Radchenko]

Jordan Ellis Coppard  writes:

> I'm mostly submitting this because the *Warnings* log requests I do so.
> It happens sometimes, and the org-file in-question is quite large and
> (dare I say) complex.
> ...
> Package: Org mode version 9.8-pre (9.8-pre-n/a-g5b419c
>  @ /Users/tsujp/.config/emacs/elpaca/builds/org/)
> ...
>  org--warnings '("org-element--cache: Org parser error in
> noir_grammar.org::9101. Resetting.\n The error was:
> (wrong-type-argument integer-or-marker-p nil)\n Backtrace:\n\"
> backtrace-to-string(nil)\n  org-element-at-point()\n
> org-adaptive-fill-function()\n  fill-match-adaptive-prefix()\n
> visual-wrap--apply-to-line()\n  visual-wrap-prefix-function(9101
> 9102)\n  #f(compiled-function (fun) # 0x1ba291230a28e93f>)(visual-wrap-prefix-function)\n
> jit-lock--run-functions(9101 9102)\n  jit-lock-fontify-now(9101
> 9258)\n  jit-lock-function(9101)\n  scroll-down(2)\n
> mwheel-scroll((triple-wheel-up (# 15534
> (553 . 498) 27716355 nil 15534 (69 . 24) nil (1 . 18) (8 . 20)) 67 2
> (0.0 . 23.0)) nil)\n  funcall-interactively(mwheel-scroll
> (triple-wheel-up (# 15534 (553 . 498)
> 27716355 nil 15534 (69 . 24) nil (1 . 18) (8 . 20)) 67 2 (0.0 . 23.0))
> nil)\n  command-execute(mwheel-scroll)\n\"\n Please report this to Org
> mode mailing list (M-x org-submit-bug-report)."

Thanks for reporting!
It looks like the problem happens repeatedly (when it happens)

Next time you see the warning, can you run

(setq backtrace-on-redisplay-error t)
(setq debug-on-error t)

trigger the warning again (mouse wheel movement?)
and post the contents of *Redisplay-trace* buffer?

(I cannot see any problems with your file)

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

Re: Slow marking item DONE with many LOGBOOK entries

[Ihor Radchenko]

Yasushi SHOJI  writes:

> I've been experiencing slow `C-c t d` (org-todo DONE) with more than
> 2000 LOGBOOK entries. Has anybody seen the same syndrome?
>
> I've narrowed it down to about 10 commits but around these commits I
> started to have the following error and can't go down any more.
>
>File mode specification error: (void-variable 
> org-element-drawer-re-nogroup)
>
>  - last good: dfd36d1969ce2c33f5899e97c02fa62544735977
>  - bad: 7c549f48419e62b1bd35208d5744df64de8a2dd0

FYI, I have an entry with over 6000 logbook entries and it works fine.
Could you record a profile? See 
https://orgmode.org/manual/Feedback.html#How-to-profile-Org-performance-1

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

Re: org element bug filling

[Ihor Radchenko]

Samuel Wales  writes:

> ⛔ Warning (org-element): org-element--cache: Org parser error in
> fix.org::22506. Resetting.
>  The error was: (wrong-type-argument integer-or-marker-p nil)
>  Backtrace:
> "  backtrace-to-string(nil)
>   org-element-at-point()
>   org-adaptive-fill-function()
>   fill-match-adaptive-prefix()
>   fill-context-prefix(22506 22558)
>   visual-wrap-fill-context-prefix(22506 22558)
>   visual-wrap-prefix-function(22557 22558)
>   #f(compiled-function (fun) # 0x1baff79c90b670bf>)(visual-wrap-prefix-function)
>   jit-lock--run-functions(22557 22558)
>   jit-lock-fontify-now(22557 24057)
>   jit-lock-function(22557)
>   redisplay_internal\\ \\(C\\ function\\)()
> "
>  Please report this to Org mode mailing list (M-x org-submit-bug-report).

When this happens, could you evaluate
(setq backtrace-on-redisplay-error t)
(setq debug-on-error t)
and try to trigger again?
This should give more meaningful backtrace in *Redisplay-trace* buffer.

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

Re: Bug in org-element with jit-lock and visual lines, and folding

[Ihor Radchenko]

Samuel Wales  writes:

> 2] as a heads up, upgrading to this version of org has caused a rise
> in folding glitches.  now, list actions, includign creating a new list
> item, can intermittently and brokenly [e.g. in middle of headings]
> fold headings, making it necessary to go up levels and toggle folding,
> then remember what the canonical folding scheme was and restore it,
> then remember where one was and search for it to place point.  these
> glitches are intermittent.

Do you use any isearch-related packages?
What happens if you do take `org-fold-core-region' and comment out
(overlay-put o 'isearch-open-invisible #'org-fold-core--isearch-show)
line there?

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

Re: [BUG] org-element--cache [9.7.31 (9.7.31-??-4e6d38d1a @ /home/buntu/.config/emacs/.local/straight/build-29.4/org/)]

[Ihor Radchenko]

Buntu Ngcebetsha  writes:

> Emacs  : GNU Emacs 29.4 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, 
> cairo version 1.16.0)
>  of 2024-11-04
> Package: Org mode version 9.7.31 (9.7.31-??-4e6d38d1a @ 
> /home/buntu/.config/emacs/.local/straight/build-29.4/org/)

>  org--warnings '("org-element--cache: Got empty parent while parsing. Please 
> report it to Org mode mailing list (M-x org-submit-bug-report).\n 
> Backtrace:\nnil" "org-element--cache: Got empty parent while parsing. Please 
> report it to Org mode mailing list (M-x org-submit-bug-report).\n 
> Backtrace:\nnil" "org-element--cache: Got empty parent while parsing. Please 
> report it to Org mode mailing list (M-x org-submit-bug-report).\n 
> Backtrace:\nnil" "org-element--cache: Got empty parent while parsing. Please 
> report it to Org mode mailing list (M-x org-submit-bug-report).\n 
> Backtrace:\nnil")

Thanks for reporting!
May I know if you are seeing this warning frequently?

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

Re: Error Emacs told me to report

[Ihor Radchenko]

Jeffrey Brown  writes:

> Wait I was wrong about being wrong -- I *am* on 9.7.30. How strange. I
> obliterated it from my .emacs.d/ folder, and the string "9.7.30" is not
> present therein, and 9.7.30 still isn't part of the NixOS channel I'm on.
>
> And I see there's a new channel available. I'm upgrading to that now. Maybe
> everything I said here today is stale; my apologies.

If you see it again, please do M-x toggle-debug-on-error
and post the backtrace that will pop up after the next saving attempt.

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

Re: [BUG] Invalid search bound (wrong side of point) [9.7.11 (release_9.7.11 @ d:/Programs/emacs-30.1/share/emacs/30.1/lisp/org/)]

[Ihor Radchenko]

Amit Tendulkar  writes:

> Emacs  : GNU Emacs 30.1 (build 2, x86_64-w64-mingw32)
>  of 2025-02-23
> Package: Org mode version 9.7.11 (release_9.7.11 @ 
> d:/Programs/emacs-30.1/share/emacs/30.1/lisp/org/)
>  org--warnings '("org-element--cache: Org parser error in TODO.org::# at 284247 in TODO.org>. Resetting.\n The error was: (error \"Invalid search 
> bound (wrong side of point)\")\n Backtrace:\nnil\n Please report this to Org 
> mode mailing list (M-x org-submit-bug-report).")

Thanks for reporting!
If you see the warning again, could you please do M-x
toggle-debug-on-error and try to trigger it one more time?
Then, you should see a more complete backtrace that should reveal what
is going on.

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

Re: [BUG] Misuse of `latexenc-find-file-coding-system` in `org-latex-compile` (Org 9.7.11)

[Ihor Radchenko]

Stephen Wheeler  writes:

> I am writing to report a bug in the LaTeX export pipeline in Org Mode 9.7.11 
> as packaged with the Snap version of Emacs 31.0.50. The issue appears to stem 
> from a recent change in `org-latex-compile` which results in the following 
> error when exporting to PDF:
>
> Debugger entered--Lisp error: (wrong-type-argument sequencep t)
> latexenc-find-file-coding-system((insert-file-contents
> "/path/to/file.tex" nil nil nil nil))
>
>
> This appears to result from a malformed call to 
> `latexenc-find-file-coding-system`, where the return value of 
> `(insert-file-contents ...)` — likely `t` or a cons cell — is passed instead 
> of a string (filename) or buffer.

Is it a full backtrace?
I am confused because Org mode does not call `latexenc-find-file-coding-system'.

> Please let me know if you require a minimal .org file or further details to 
> reproduce the issue.

A reproducer would indeed be helpful.

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

Re: [BUG] org-element--list-struct: Tab width in Org files must be 8, not 4 [9.7.11 (release_9.7.11 @ /Applications/MacPorts/Emacs.app/Contents/Resources/lisp/org/)]

[Ihor Radchenko]

"Y. E."  writes:

>> Could you please upgrade and let me know if you still experience any 
>> problems?
>> 
>
> It's good to know the issue has already been addressed, thank you.
> I encountered this only with one small project setup and currently use 
> whatever Macports-shipped Emacs app is packaged with, so will most probably 
> wait until the package is upgraded upstream.

Ok. Closing.
Canceled.

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

Re: [BUG] Org mode fails when export to latex buffer with auctex

[Ihor Radchenko]

Vangelis Evangelou  writes:

> Scenario 2:
>
>1. Load auctex and set TeX-parse-self to t
>2. Create a scratch buffer and type in "\documentclass{amsart}". Note
>that this is different from Scenario 1. The difference is that amsart uses
>the amstex package. Org export to latex also uses the amstex package.
>3. Load LaTeX-mode with M-x LaTeX-mode
>
> With Scenario 1 I don't get an error but with Scenario 2 I
> do. reftex-TeX-master-file: Wrong type argument: stringp, nil
>
> As I said in a previous email, this may also be a bug with reftex. Looking
> at the code of reftex-TeX-master-file, I can see that
>
> (let ((master
> (cond
>  ;; AUCTeX is loaded.  Use its mechanism.
>  ((fboundp 'TeX-master-file)
>   (condition-case nil
>   (TeX-master-file t)
> (error (buffer-file-name)))
>
> and then later it says
> (cond
>  ((null master)
>   (error "Need a filename for this buffer, please save it first"))

This second part has been removed on Emacs master in
03fc0e0fd51990570759601fa7e64f1cc5b76932: Add RefTeX support for non-file 
buffers

> However, TeX-master-file returns "" if the file is not saved instead
> of nil, so it seems that reftex-TeX-master-file uses TeX-master-file
> wrongly. However, even if reftex-TeX-master-file did use TeX-master-file
> correctly, org-mode would still have a problem because it would hit
> the (error "Need a filename for this buffer, please save it first").
> Because of this I believe that both reftex and org have a bug.

I added a workaround for Emacs <31.
Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c4eb9b45c

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

Re: [BUG] Org mode fails when export to latex buffer with auctex when TeX-parse-self is t [9.7.11 (release_9.7.11 @ /usr/local/share/emacs/30.1/lisp/org/)]

[Ihor Radchenko]

Vangelis Evangelou  writes:

> I started with emacs -q. Then in the scratch buffer, I evaluated the
> following code
>
> (use-package reftex-auc)
> (use-package tex
>   :load-path "site-lisp/auctex-14.0.9"
>   :custom
>   (TeX-parse-self t))
>
> Then, I created an org buffer which I exported to latex buffer (C-c C-e l
> L). I get the error message
>
> reftex-TeX-master-file: Wrong type argument: stringp, nil

Fixed, on bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=c4eb9b45c

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

Re: renumbering chapters

[Jean Louis]

* Sharon Kimble  [2025-07-20 16:14]:
> Hi folks.
> 
> I've written a book and just created a new chapter by splitting one in half.
> 
> They are numbered Chapter 1, Chapter 2, etc, and they're all level one 
> headings.
> 
> So how can I auto-renumber them please?

#+TITLE: My Book
#+OPTIONS: num:t

* Chapter 1
:PROPERTIES:
:CHAPTER: 1
:END:
This is my first chapter content...

* Chapter 2
:PROPERTIES:
:CHAPTER: 2
:END:
Second chapter content...

* Chapter 3
:PROPERTIES:
:CHAPTER:  3
:END:
Second chapter content...

* Chapter 3
:PROPERTIES:
:CHAPTER:  3
:END:
Second chapter content...

* Chapter 3
:PROPERTIES:
:CHAPTER:  3
:END:
Second chapter content...

* Chapter 4
:PROPERTIES:
:CHAPTER:  4
:END:
Third chapter content...

Put this function in your init file:

(defun org-update-chapter-numbers ()
  "Update all chapter numbers sequentially in the current buffer."
  (interactive)
  (save-excursion
(goto-char (point-min))
(let ((counter 0))
(while (re-search-forward "^\* " nil t)
  (when (= (org-current-level) 1)
(setq counter (1+ counter))
;; Update the property
(org-set-property "CHAPTER" (number-to-string counter))
;; Update the heading text
(org-edit-headline (format "Chapter %d" counter)))

Now you can do M-x org-update-chapter-numbers to update numbers of chapters.

-- 
Jean Louis

Re: [BUG] Numeric priorities only partially supported

[Derek Chen-Becker]

Sounds good. I'm happy to update the documentation, the regexp, and
other mentioned locations to match one of A-Z or 0-64. Are we OK
restricting it to uppercase only?

Thanks!

Derek

On Sat, Jul 19, 2025 at 10:29 AM Ihor Radchenko  wrote:

> Derek Chen-Becker  writes:
>
> > I guess looking at https://orgmode.org/manual/Priorities.html, it's not
> > clearly defined what valid ranges are. Are upper and lower cases
> considered
> > equivalent? Is it strictly A-Z, or a-z, or 1-64? If it's not numeric, do
> > we just allow any character whose value is >= 65? For example, 一，二， 三， 四?
> > Technically, is 1 the highest possible numeric priority or would zero
> (or a
> > negative number) be valid? I feel like maybe we should update the manual
> at
> > the same time, and precisely specify what the allowed values are. I can
> > sort of reverse engineer from the code, but is this documented anywhere
> > other than the manual?
>
> Well. You cannot reverse engineer.
>
> 1. org-priority-regexp is ".*?\\(\\[#\\([A-Z0-9]+\\)\\] ?\\)"
> 2. org-element.el is
>(priority (and (looking-at "\\[#.\\][ \t]*")
> (progn (goto-char (match-end 0))
>(aref (match-string 0) 2
> 3. https://orgmode.org/worg/org-syntax.html (following the parser)
>PRIORITY (optional)
>A single alphanumeric character preceded by a hash sign # and
>enclosed within square brackets (e.g. [#A] or [#1]). This is called a
>“priority cookie”.
>
> 4. 5.4 Priorities in the manual says, "A", "B", "C", "integers, which
>must all be strictly inferior to 65", "earlier in alphabet" (implying
>some kind of ordered alphabet, but not CJK)
>
> 5. org-priority-highest
>If you set org-priority-highest to a numeric value inferior to
>65, Org assumes you want to use digits for the priority cookie.
>If you set it to >=65, Org assumes you want to use alphabetical
>characters.
>
> 6. org-priority-get-priority-function is a defcustom, implying that
>priority might be less restrictive
>
> 7. (org-element-property :priority (org-element-at-point)) always
>returns a number/character (and must be interpreted back by
>org-element-interpret-data)
>
> 8. Some places in the code
>(`org-latex-format-headline-default-function') plainly assume that
>priority is formattable with (format "%c" ...)
>
> I'd say that the simplest approach will be using the most restrictive
> definition of priority: either a number between 0-64 or a single
> alphabetic character (with code >=65).
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
+---+
| Derek Chen-Becker |
| GPG Key available at https://keybase.io/dchenbecker and   |
| https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org |
| Fngrprnt: EB8A 6480 F0A3 C8EB C1E7  7F42 AFC5 AFEE 96E4 6ACC  |
+---+

Suggestion: Document `org-extend-today-until` in Clock Table section

[Flinner Yuu]

Hi Org Maintainers,


In the Clock Table[1] documentation, I think that 
`org-extend-today-until` should be documented. For users that don't 
start their day at 00:00 midnight due to overnight shifts. People seem 
to be applying hacks around this [2] to get the desired effect.


In fact I patched `org-matcher-timer` to support custom  
syntax for myself, but then realized I could (setq 
org-extend-today-until 4)!


Should it be added to documentation? I would be happy to do so.

Apologies if this is posted on the wrong mailing list!

Best,
Flinner



[1]: https://orgmode.org/manual/The-clock-table.html
[2]: 
https://emacs.stackexchange.com/questions/29968/org-mode-clock-report-shift-day-range

Re: Bug in org-element with jit-lock and visual lines, and folding

[Samuel Wales]

i use emacs isearch.  no other packages related to isearch that i am aware of.

is commenting out that line intended to fix the bug or cause a bug?
it did not ause a bug.  the bug is intermittent.

On Sun, Jul 20, 2025 at 8:09 AM Ihor Radchenko  wrote:
>
> Samuel Wales  writes:
>
> > 2] as a heads up, upgrading to this version of org has caused a rise
> > in folding glitches.  now, list actions, includign creating a new list
> > item, can intermittently and brokenly [e.g. in middle of headings]
> > fold headings, making it necessary to go up levels and toggle folding,
> > then remember what the canonical folding scheme was and restore it,
> > then remember where one was and search for it to place point.  these
> > glitches are intermittent.
>
> Do you use any isearch-related packages?
> What happens if you do take `org-fold-core-region' and comment out
> (overlay-put o 'isearch-open-invisible #'org-fold-core--isearch-show)
> line there?
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 



-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: org element bug filling

[Samuel Wales]

i will try, but i doubt that i wil be able to retrigger immediately
aft4r the first trigger.

On Sun, Jul 20, 2025 at 8:04 AM Ihor Radchenko  wrote:
>
> Samuel Wales  writes:
>
> > ⛔ Warning (org-element): org-element--cache: Org parser error in
> > fix.org::22506. Resetting.
> >  The error was: (wrong-type-argument integer-or-marker-p nil)
> >  Backtrace:
> > "  backtrace-to-string(nil)
> >   org-element-at-point()
> >   org-adaptive-fill-function()
> >   fill-match-adaptive-prefix()
> >   fill-context-prefix(22506 22558)
> >   visual-wrap-fill-context-prefix(22506 22558)
> >   visual-wrap-prefix-function(22557 22558)
> >   #f(compiled-function (fun) # > 0x1baff79c90b670bf>)(visual-wrap-prefix-function)
> >   jit-lock--run-functions(22557 22558)
> >   jit-lock-fontify-now(22557 24057)
> >   jit-lock-function(22557)
> >   redisplay_internal\\ \\(C\\ function\\)()
> > "
> >  Please report this to Org mode mailing list (M-x org-submit-bug-report).
>
> When this happens, could you evaluate
> (setq backtrace-on-redisplay-error t)
> (setq debug-on-error t)
> and try to trigger again?
> This should give more meaningful backtrace in *Redisplay-trace* buffer.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 



-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [BUG] Tags following a timestamp does not work.

[Miki Kawabe]

Thanks a lot for the quick fix !  It works.

On 2025/07/20 18:17, Ihor Radchenko wrote:
>Miki Kawabe  writes:
>
>> I'm wondering if it's allowed to use both timestamp and tag in the same 
>> headline in Org mode.
>> Although I read the manual on Tags and Timestamps, I couldn't find any 
>> explanation for these limitation.
>>
>> org-open-at-point does not work for tags, when the tags are following a 
>> timestamp.
>>
>> Example
>>
>> * Headline <2020-04-01>:tag1:
>> tag1 is "no found link". Is this a bug ?
>> ...
>
>Thanks for reporting!
>Fixed, on main.
>https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=791c2285e
>
>-- 
>Ihor Radchenko // yantar92,
>Org mode maintainer,
>Learn more about Org mode at .
>Support Org development at ,
>or support my work at 

Re: [BUG] Misuse of `latexenc-find-file-coding-system` in `org-latex-compile` (Org 9.7.11)

[Ihor Radchenko]

Stephen Wheeler  writes:

> You're right that Org itself does not call 
> `latexenc-find-file-coding-system`, but the error appears during PDF export 
> when using Org 9.7.11 bundled with the Snap version of Emacs 31.0.50.
>
> Here is the **full backtrace**, obtained with `debug-on-error` enabled, using 
> the default `org-latex-export-to-pdf` without any redefinition of 
> `org-latex-compile`:
>
> Debugger entered--Lisp error: (wrong-type-argument sequencep t)
> latexenc-find-file-coding-system((insert-file-contents 
> "/home/steve/UniDrop/Projects/SEPSE/Critique/migrationRedesignPlan.tex" nil 
> nil nil nil))
> org-latex-compile("migrationRedesignPlan.tex")
> org-export-to-file(latex "migrationRedesignPlan.tex" nil nil nil nil nil 
> org-latex-compile)
> ...
> My environment:
>
> Emacs: 31.0.50 (via Snap)

I am pretty sure that it has nothing to do with Org mode.
Looking at the recent changes in that function, I see two commits:
22daed7ce0e and db46d5e8333 that fixes the previous commit.
Considering that you are on the bleeding edge Emacs, you might be, for
example, between 22daed7ce0e and db46d5e8333.
I recommend to: (1) upgrade Emacs from the latest master; (2) if that
does not help, report the bug to Emacs devs.

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

Re: Modifying org-mode links

[Zoey Hewll]

Hi Heime,

`org-insert-link' (bound to C-c C-l by default) lets you edit the link 
URL and display text for the link at point, if there is one. Otherwise, 
it inserts a link at point. This is what I use to edit links in all my 
org documents.


Regards,

Zoey

On 21/7/25 09:11, Heime wrote:

Have been using the general link format to make internal links
for use with the mouse.

[[LINK][DESCRIPTION]]

But then, how can I see it in its original text.  I find it
difficult to modify it when I use the delete key to remove
the first "[".

Re: Bug in org-element with jit-lock and visual lines, and folding

[Samuel Wales]

i discovered another major bug by coincidence.  is it related?

  * folded
  lorem
  * unfolded
  point

if i do an isearch backward, isearch will not notice lorem.  it seems
to act as if isearch-invisible were nil.

isearch-invisible is its standard value of open.  search-visible is
its standard value of
open.  isearch-hide-immediately is its standard value of t.  reveal-mode is nil.

On Sun, Jul 20, 2025 at 4:12 PM Samuel Wales  wrote:
>
> i use emacs isearch.  no other packages related to isearch that i am aware of.
>
> is commenting out that line intended to fix the bug or cause a bug?
> it did not ause a bug.  the bug is intermittent.
>
> On Sun, Jul 20, 2025 at 8:09 AM Ihor Radchenko  wrote:
> >
> > Samuel Wales  writes:
> >
> > > 2] as a heads up, upgrading to this version of org has caused a rise
> > > in folding glitches.  now, list actions, includign creating a new list
> > > item, can intermittently and brokenly [e.g. in middle of headings]
> > > fold headings, making it necessary to go up levels and toggle folding,
> > > then remember what the canonical folding scheme was and restore it,
> > > then remember where one was and search for it to place point.  these
> > > glitches are intermittent.
> >
> > Do you use any isearch-related packages?
> > What happens if you do take `org-fold-core-region' and comment out
> > (overlay-put o 'isearch-open-invisible #'org-fold-core--isearch-show)
> > line there?
> >
> > --
> > Ihor Radchenko // yantar92,
> > Org mode maintainer,
> > Learn more about Org mode at .
> > Support Org development at ,
> > or support my work at 
>
>
>
> --
> The Kafka Pandemic
>
> A blog about science, health, human rights, and misopathy:
> https://thekafkapandemic.blogspot.com



-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [FR] Org export: expanding links to included files (was: [BUG] Export backend cross-references are broken [9.7.30 (release_9.7.30 @ /home/user/org-mode-git/lisp/)])

[Samuel Wales]

could the duplicate issue, at least, be fixed by adding the feature of
allowing id links?

On Sun, Jul 20, 2025 at 5:27 AM Ihor Radchenko  wrote:
>
> Louis Vigneras  writes:
>
> > Following yantar92’s suggestion on the matrix channel, I am reporting
> > here what appears to be a bug.
> >
> > I have an index.org file with the following:
> > #+include: chapter-1.org
> > #+include: chapter-2.org
> >
> > In chapter-1.org I have the following:
> > * Heading
> > [[file:chapter-2.org::*Heading 1][Link to heading 1]]
> >
> > In chapter-2.org I have the following:
> > * Heading 1
> >
> > Text
> >
> > When exporting to both PDF and HTML, links are rendered as follows:
> >
> > ```latex
> > \href{chapter-2.org}{Link to heading 1}
> > ...
>
> I checked the sources, and it is not a bug. Rather a missing feature.
>
> > I believe the expected behavior should output links referring to
> > headings of the output document. It should not refer to the org file for
> > the PDF output, nor the chapter-2.html file for the HTML output as it
> > only produces an index.html file.
>
> I agree that it would be expected.
> On the other hand, it would not be trivial to implement.
> Consider, for example,
> #+include: chapter-1.org
> #+include: chapter-2.org :lines 2-20
>
> What should we do in such situation?
>
> In addition, there could be duplicates in heading names and a link that
> would otherwise be unique as  may no
> longer be, after we include multiple files, if another included file
> also contains * Heading 1.
>
> Note also that the reference is not broken - the reference should still
> be valid.
>
> --
> Ihor Radchenko // yantar92,
> Org mode maintainer,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: [BUG] Error about org-link-types when creating a link [9.7.31 (9.7.31-4e6d38 @ /home/dsmasterson/.emacs.d/elpa/org-9.7.31/)]

[David Masterson]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>> But there is no such variable in Org mode - `org-link-types'. There is a
>> *function*. Bug in org-ac.
>
> Looks like there used to be such variable long time ago.
> But it has been removed in
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=9bc294003
> 9 years ago.

Boy, that's been hanging around a long time!  I've had org-ac
(v20170401.1307) in my packages for quite sometime.  It seems old, so
perhaps it's time to remove it.  I'll have to look at how (or if) it's
loaded again by my use-package setup.  I'm not sure why this bug
suddenly got tickled.

Thanks.
-- 
David Masterson

Re: [FR] Org export: expanding links to included files (was: [BUG] Export backend cross-references are broken [9.7.30 (release_9.7.30 @ /home/user/org-mode-git/lisp/)])

[Ihor Radchenko]

Samuel Wales  writes:

> could the duplicate issue, at least, be fixed by adding the feature of
> allowing id links?

What do you mean by "duplicate issue"?

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

Re: org element bug filling

[Ihor Radchenko]

Samuel Wales  writes:

> i set teh variables and tried to repro and was not able to.

Then, you can try adding those variable into init.el and then monitor
*Redisplay-trace* buffer.

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

Re: Bug in org-element with jit-lock and visual lines, and folding

[Ihor Radchenko]

Samuel Wales  writes:

> is commenting out that line intended to fix the bug or cause a bug?
> it did not ause a bug.  the bug is intermittent.

It might fix the bug, if my blind guess on what the bug is about is right.

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

Re: Bug in org-element with jit-lock and visual lines, and folding

[Ihor Radchenko]

Samuel Wales  writes:

> i discovered another major bug by coincidence.  is it related?
>
>   * folded
>   lorem
>   * unfolded
>   point
>
> if i do an isearch backward, isearch will not notice lorem.  it seems
> to act as if isearch-invisible were nil.

Sorry, I am unable to reproduce. Could you please provide more detailed
instructions starting from emacs -Q?


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