Re: [ANN] Emergency bugfix release: Org mode 9.7.5

[Steven Allen]

Greg Troxel  writes:

> (Thanks for fixing and your efforts on org.  I've been an org user since
> at least July of 2010.)
>
> Just to be clear, is this the commit that needs applying to emacs
> sources, 29.3, 28.x, and so on?

Yes, that's the correct commit.

> It seems so, but I would rather not guess. I'm asking on behalf of
> pkgsrc, where I am managing the release process for our 2024Q2 branch,
> due on 30 June. Believe it or not we have 20, 21, 26, 27, 28, 29 and a
> from-git version. While some should be pruned, some people use it on
> vaxes. Any idea how far back this goes?

It was introduced in org 7.9 (commit [1] from July of 2012). From what I
can tell, it has been present in Emacs since emacs-24.2.

[1]: ef3d4b5965b828e85a535ef3f32999473c6a2a7a 

>
> Thanks,
> Greg
>
> commit f4cc61636947b5c2f0afc67174dd369fe3277aa8
> Author: Ihor Radchenko 
> Date:   Tue Jun 18 13:06:44 2024 +0200
>
> org-link-expand-abbrev: Do not evaluate arbitrary unsafe Elisp code
> 
> * lisp/ol.el (org-link-expand-abbrev): Refuse expanding %(...) link
> abbrevs that specify unsafe function.  Instead, display a warning, and
> do not expand the abbrev.  Clear all the text properties from the
> returned link, to avoid any potential vulnerabilities caused by
> properties that may contain arbitrary Elisp.
>
> diff --git a/lisp/ol.el b/lisp/ol.el
> index 7a7f4f558..8a556c7b9 100644
> --- a/lisp/ol.el
> +++ b/lisp/ol.el
> @@ -1152,17 +1152,35 @@ Abbreviations are defined in `org-link-abbrev-alist'."
>(if (not as)
> link
>   (setq rpl (cdr as))
> - (cond
> -  ((symbolp rpl) (funcall rpl tag))
> -  ((string-match "%(\\([^)]+\\))" rpl)
> -   (replace-match
> -(save-match-data
> -  (funcall (intern-soft (match-string 1 rpl)) tag))
> -t t rpl))
> -  ((string-match "%s" rpl) (replace-match (or tag "") t t rpl))
> -  ((string-match "%h" rpl)
> -   (replace-match (url-hexify-string (or tag "")) t t rpl))
> -  (t (concat rpl tag)))
> +;; Drop any potentially dangerous text properties like
> +;; `modification-hooks' that may be used as an attack vector.
> +(substring-no-properties
> +  (cond
> +   ((symbolp rpl) (funcall rpl tag))
> +   ((string-match "%(\\([^)]+\\))" rpl)
> +   (let ((rpl-fun-symbol (intern-soft (match-string 1 rpl
> + ;; Using `unsafep-function' is not quite enough because
> + ;; Emacs considers functions like `genenv' safe, while
> + ;; they can potentially be used to expose private system
> + ;; data to attacker if abbreviated link is clicked.
> + (if (or (eq t (get rpl-fun-symbol 'org-link-abbrev-safe))
> + (eq t (get rpl-fun-symbol 'pure)))
> + (replace-match
> +   (save-match-data
> + (funcall (intern-soft (match-string 1 rpl)) tag))
> +   t t rpl)
> +   (org-display-warning
> +(format "Disabling unsafe link abbrev: %s
> +You may mark function safe via (put '%s 'org-link-abbrev-safe t)"
> +rpl (match-string 1 rpl)))
> +   (setq org-link-abbrev-alist-local (delete as 
> org-link-abbrev-alist-local)
> + org-link-abbrev-alist (delete as org-link-abbrev-alist))
> +   link
> +)))
> +   ((string-match "%s" rpl) (replace-match (or tag "") t t rpl))
> +   ((string-match "%h" rpl)
> +(replace-match (url-hexify-string (or tag "")) t t rpl))
> +   (t (concat rpl tag
>  
>  (defun org-link-open (link  arg)
>"Open a link object LINK.

Re: [ANN] Emergency bugfix release: Org mode 9.7.5

[Greg Troxel]

(Thanks for fixing and your efforts on org.  I've been an org user since
at least July of 2010.)

Just to be clear, is this the commit that needs applying to emacs
sources, 29.3, 28.x, and so on?  It seems so, but I would rather not
guess.  I'm asking on behalf of pkgsrc, where I am managing the release
process for our 2024Q2 branch, due on 30 June.  Believe it or not we
have 20, 21, 26, 27, 28, 29 and a from-git version.  While some should
be pruned, some people use it on vaxes.   Any idea how far back this
goes?

Thanks,
Greg

commit f4cc61636947b5c2f0afc67174dd369fe3277aa8
Author: Ihor Radchenko 
Date:   Tue Jun 18 13:06:44 2024 +0200

org-link-expand-abbrev: Do not evaluate arbitrary unsafe Elisp code

* lisp/ol.el (org-link-expand-abbrev): Refuse expanding %(...) link
abbrevs that specify unsafe function.  Instead, display a warning, and
do not expand the abbrev.  Clear all the text properties from the
returned link, to avoid any potential vulnerabilities caused by
properties that may contain arbitrary Elisp.

diff --git a/lisp/ol.el b/lisp/ol.el
index 7a7f4f558..8a556c7b9 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1152,17 +1152,35 @@ Abbreviations are defined in `org-link-abbrev-alist'."
   (if (not as)
  link
(setq rpl (cdr as))
-   (cond
-((symbolp rpl) (funcall rpl tag))
-((string-match "%(\\([^)]+\\))" rpl)
- (replace-match
-  (save-match-data
-(funcall (intern-soft (match-string 1 rpl)) tag))
-  t t rpl))
-((string-match "%s" rpl) (replace-match (or tag "") t t rpl))
-((string-match "%h" rpl)
- (replace-match (url-hexify-string (or tag "")) t t rpl))
-(t (concat rpl tag)))
+;; Drop any potentially dangerous text properties like
+;; `modification-hooks' that may be used as an attack vector.
+(substring-no-properties
+(cond
+ ((symbolp rpl) (funcall rpl tag))
+ ((string-match "%(\\([^)]+\\))" rpl)
+   (let ((rpl-fun-symbol (intern-soft (match-string 1 rpl
+ ;; Using `unsafep-function' is not quite enough because
+ ;; Emacs considers functions like `genenv' safe, while
+ ;; they can potentially be used to expose private system
+ ;; data to attacker if abbreviated link is clicked.
+ (if (or (eq t (get rpl-fun-symbol 'org-link-abbrev-safe))
+ (eq t (get rpl-fun-symbol 'pure)))
+ (replace-match
+ (save-match-data
+   (funcall (intern-soft (match-string 1 rpl)) tag))
+ t t rpl)
+   (org-display-warning
+(format "Disabling unsafe link abbrev: %s
+You may mark function safe via (put '%s 'org-link-abbrev-safe t)"
+rpl (match-string 1 rpl)))
+   (setq org-link-abbrev-alist-local (delete as 
org-link-abbrev-alist-local)
+ org-link-abbrev-alist (delete as org-link-abbrev-alist))
+   link
+  )))
+ ((string-match "%s" rpl) (replace-match (or tag "") t t rpl))
+ ((string-match "%h" rpl)
+  (replace-match (url-hexify-string (or tag "")) t t rpl))
+ (t (concat rpl tag
 
 (defun org-link-open (link  arg)
   "Open a link object LINK.

Re: ox-icalendar: Filter todo-types

[Jack Kamm]

Michaël Cadilhac  writes:

> I have a task that was recurring, which I KILLED a few weeks ago.  It
> now looks like:
>
> ** KILLED Do the right thing
>SCHEDULED: <2023-07-14 Fri +1w>
>
> ox-icalendar still exports it every week, because I have
> 'event-if-not-todo in org-icalendar-use-scheduled (which is the
> behavior I want for some other headers).
>
> BEGIN:VEVENT
> DTSTAMP:20240622T163042Z
> UID:SC-671b3d13-f985-472a-be33-b4eeb298f2cd
> DTSTART;VALUE=DATE:20230714
> DTEND;VALUE=DATE:20230715
> RRULE:FREQ=WEEKLY;INTERVAL=1
> SUMMARY:S: KILLED Do the right thing :
> CATEGORIES:todos
> END:VEVENT
>
> Would it be acceptable to add a variable to filter todo-types, e.g.,
> with a variable org-icalendar-excluded-todo-types?  More generally,
> one could think of introducing a variable:
>org-icalendar-entry-filter
> which receives the ENTRY argument of org-icalendar-entry, and would
> return non-nil if the entry is to be treated.  (This is basically what
> I do using an advice.)

I agree ox-icalendar should have an option to exclude certain
todo-keywords from export.

However I think the option should also be flexible to allow exporting
todo-keywords as different STATUS:

https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.1.11

For example, in your case it might make more sense to export the task as
CANCELLED in iCalendar.

I think I'd rather have a customization option for this than a filter
function. That way, other Lisp programs that import ICS to Org (such as
org-caldav) could refer to this option to interoperate with ox-icalendar
for 2-way sync.

Perhaps we could have an option ox-icalendar-export-todo-keywords-as
which could determine whether a keyword should be exported, and if so
with what status, e.g.:

(defcustom ox-icalendar-export-todo-keywords-as
 '((no-export . ("SKIP"))
   (cancelled . ("KILLED" "CANCELLED"))
   (in-process . ("PROG"

By default, todo-keywords not in the list would be exported with status
"NEEDS-ACTION" or "COMPLETED", depending on whether the keyword is a
done state.

What do you think?

Re: [ANN] Emergency bugfix release: Org mode 9.7.5

[Ihor Radchenko]

emacs-orgm...@city17.xyz writes:

> Will a CVE be released?

Should be, I think.
If nobody reports it independently by tomorrow, I will look into how to
request a CVE number myself.

> ... I am interested if there are mitigating factors
> such as using `emacs -nw` (without GUI), thus no possible preview of the
> attachments (IIUC).

AFAIK, previewing attachments is not disabled by "no GUI" - preview in
this context simply means fontification using major mode of the attached
files.

To disable email previews, see `mm-inline-media-tests'.

Note that you cannot easily work around the problem when opening an
actual Org file. You would either have to advice the problematic Org
function, or cherry-pick the relevant commit from the release.

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

Re: [ANN] Emergency bugfix release: Org mode 9.7.5

[emacs-orgmode]

Ihor Radchenko  writes:


I just released Org mode 9.7.5 that fixes a critical vulnerability.
The release is coordinated with emergency Emacs 29.4 release.


Thanks for the release and the anouncement.

Will a CVE be released? I am interested if there are mitigating factors
such as using `emacs -nw` (without GUI), thus no possible preview of the
attachments (IIUC).

Best,

Re: [ANN] Emergency bugfix release: Org mode 9.7.5

[Ihor Radchenko]

Ihor Radchenko  writes:

> Please upgrade your Org mode *and* Emacs ASAP.

*Org mode or Emacs.

The fix is purely in Org code, so upgrading Emacs is only needed when
you want to use built-in Org mode.

Otherwise, it is enough to upgrade Org mode via ELPA (the tarball will
be available soon, after ELPA scripts fetch the latest release tag).

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

ox-icalendar: Filter todo-types

[Michaël Cadilhac]

I have a task that was recurring, which I KILLED a few weeks ago.  It
now looks like:

** KILLED Do the right thing
   SCHEDULED: <2023-07-14 Fri +1w>

ox-icalendar still exports it every week, because I have
'event-if-not-todo in org-icalendar-use-scheduled (which is the
behavior I want for some other headers).

BEGIN:VEVENT
DTSTAMP:20240622T163042Z
UID:SC-671b3d13-f985-472a-be33-b4eeb298f2cd
DTSTART;VALUE=DATE:20230714
DTEND;VALUE=DATE:20230715
RRULE:FREQ=WEEKLY;INTERVAL=1
SUMMARY:S: KILLED Do the right thing :
CATEGORIES:todos
END:VEVENT

I do not see any way to filter on todo-type in org-calendar-entry, the
relevant bit thereof reading:

(and scheduled
 (pcase todo-type
   (`todo (or (memq 'event-if-todo-not-done use-scheduled)
  (memq 'event-if-todo use-scheduled)))
   (`done (memq 'event-if-todo use-scheduled))
   (_ (memq 'event-if-not-todo use-scheduled)))
 (org-icalendar--vevent
  entry scheduled (concat "SC-" uid)
  (concat scheduled-summary-prefix summary)
  loc desc cat tz class)))

Would it be acceptable to add a variable to filter todo-types, e.g.,
with a variable org-icalendar-excluded-todo-types?  More generally,
one could think of introducing a variable:
   org-icalendar-entry-filter
which receives the ENTRY argument of org-icalendar-entry, and would
return non-nil if the entry is to be treated.  (This is basically what
I do using an advice.)

Cheers,
Michaël

[ANN] Emergency bugfix release: Org mode 9.7.5

[Ihor Radchenko]

Dear all,

I just released Org mode 9.7.5 that fixes a critical vulnerability.
The release is coordinated with emergency Emacs 29.4 release.

Please upgrade your Org mode *and* Emacs ASAP.

The vulnerability involves arbitrary Shell code evaluation when
previewing attachments in Emacs MUA (gnus-based: at least, mu4e,
Notmuch, Gnus itself) or when opening third-party Org files. All the
earlier versions of Org mode are affected.

Note that the vulnerability solved in this release has nothing to do
with recent Org 9.6.23 release
(https://list.orgmode.org/871q7zbldp.fsf@localhost/). It existed since
long time ago and was discovered by accident.

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

[PATCH] lisp/lisp/ob-core.el (org-babel-merge-params): Rename plists to alists

[Matthias Hetzenberger]

Hello!

I noticed that in the function org-babel-merge-params the arguments are
alists rather than plists.
To this end, I created a patch that updates the relevant variable names as
well as the docstring (see attachment).
From db9d5b77aedfb87aa0a3382f6be9d5921eef2ffd Mon Sep 17 00:00:00 2001
From: Matthias Hetzenberger 
Date: Sat, 22 Jun 2024 16:06:41 +0200
Subject: [PATCH] org-babel-merge-params: Rename plists to alists

---
 lisp/ob-core.el | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index db75f1f0a..5b32f503b 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2959,9 +2959,9 @@ used as a string to be appended to #+begin_example line."
   (goto-char body-start)
   (insert body
 
-(defun org-babel-merge-params ( plists)
-  "Combine all parameter association lists in PLISTS.
-Later elements of PLISTS override the values of previous elements.
+(defun org-babel-merge-params ( alists)
+  "Combine all parameter association lists in ALISTS.
+Later elements of ALISTS override the values of previous elements.
 This takes into account some special considerations for certain
 parameters when merging lists."
   (let* ((results-exclusive-groups
@@ -2990,8 +2990,8 @@ parameters when merging lists."
 	 ;; Some keywords accept multiple values.  We need to treat
 	 ;; them specially.
 	 vars results exports)
-(dolist (plist plists)
-  (dolist (pair plist)
+(dolist (alist alists)
+  (dolist (pair alist)
 	(pcase pair
 	  (`(:var . ,value)
 	   (let ((name (cond
-- 
2.45.1

Re: [BUG] Trailing dash is not included in link [9.7.3 (9.7.3-2f1844 @ /home/mwillcock/.emacs.d/elpa/org-9.7.3/)]

[Ihor Radchenko]

Max Nikulin  writes:

>> If you can, please do not make such assertions without testing.
>
> I am sorry, I had no intention to offend you. I missed that the removed 
> line with explicit list of punctuation characters was commented out. I 
> have tried the regexp used before (a part of v6.34)

>  facedba05 2009-12-09 15:13:50 +0100 Carsten Dominik: Use John 
> Gruber's regular expression for URL's
>
> and it seems trailing dash was allowed.

Hmm. That's a really long time ago, earlier than built-in Org in Emacs
versions that are available in various distros. My reading of "prior to
v9.5" was more like "not too far before v9.5" (and I tested everything
down to Org mode included into Emacs 26).

 +: https://domain/test-
>>>
>>> example.org, example.net, example.com are domains reserved for usage in
>>> examples:
>>> 
>> 
>> And so?
>
> http://example.org/dash- may be a bit better for docs. (For IPv6 
> addresses the difference should be more noticeable, but I do not 
> remember what range is reserved for usage in examples there.)

I see. I would not mind installing a patch, if you submit it.

>>> I have realized that some Org regexps use [:punct:] *regexp class* and
>>> others *syntax class*, see latex math regexp. I am in doubts if the
>>> discrepancy is intentional.
>> 
>> It is not intentional, but using syntax classes can sometimes be
>> fragile.
>
> Do you mean that result depends on current buffer? I do not have strong 
> opinion what variant should be used.

Not current buffer. Current syntax table, inherited from
outline-mode. And that syntax table is customized by some users, leading
to Org parser behaving unexpectedly in some scenarios.

Also, there is 'syntax-table text property, and I have managed to break
Org parser in the past by trying to apply 'syntax-table property to code
blocks in Org mode (I was trying to solve `forward-sexp' bug people
frequently report).

So, we should generally avoid using syntax tables, so that Org syntax
becomes independent of user customizations in that area. Or, at least,
we should not introduce more syntax class uses when possible.

> ... What I do not like is that in the 
> case of $n$-th the character after second "$" is tested against syntax 
> class, while regexp class is used for links. This subtle difference is 
> almost certainly ignored in alternative implementations of the parser. 
> However I am not sure what characters besides dash and apostrophe are 
> affected and whether it depends on locale.

These kinds of inconsistencies should be solved eventually. We should not
use locale, but UTF syntax classes; and document it in org-syntax
document.

>>> 09ced6d2c 2024-02-03 15:15:46 +0100 Ihor Radchenko: org-link-plain-re:
>>> Improve regexp heuristics
> [...]
>>>   (link http://example.org/a [...]
>> It is heuristics. We cannot be 100% right. So, it is what it is.
>
>  From my point of view it is at least close to a regression. I do not 
> have any argument against http://example.org/a, but the regexp should 
> not match whole "http://example.org/a>> I would consider [:space:] or \s-.
>> 
>> Do you mean "[^[:punct:][:space:]\t\n]"?
>
> I believe it might be an improvement ([:space:] includes \t).

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

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

Re: [PATCH] Ability to specify :html-head as a function

[Ihor Radchenko]

Nathan Nichols  writes:

>> This looks like a copy-paste of `org-element-normalize-string'.
>> Why not simply calling `org-element-normalize-string'?
>
> I changed it at one point, but then changed it back and didn't realize that
> it was ultimately unchanged.
> Here's a patch that uses `org-element-normalize-string` instead.

Thanks!

> +(defun org-html-normalize-str-or-fn (input  trailing)
> +  "If INPUT is a string, it is passed to `org-element-normalize-string'.

Ideally, the first line of the docstring should fully describe what
function does.

Maybe you can add something like

   Normalize INPUT function or string.  Return a string or nil.

> +If INPUT is a function, it is applied to arguments TRAILING, and the result 
> is
> +passed to `org-element-normalize-string'."
> +  (let ((s (if (functionp input) (format "%s" (apply input trailing)) 
> input)))
> +(org-element-normalize-str s)))
   ^org-element-normalize-string

TRAILING name is confusing because it is not what one expects to be a
name of function arguments.  Maybe

(defun org-html-normalize-str-or-fn (input  args)


Also, you need to update docstrings and type definitions for
`org-html-head' and `org-html-head-extra', update the Org manual, and
announce the new allowed values in etc/ORG-NEWS.

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

[SUMMARY] #8 [[bbb:OrgMeetup]] on Wed, June 12, 19:00 UTC+3

[Ihor Radchenko]

It was a long discussion this time (almost 3 hours).
We ended up talking in-depth about Org mode development and some very
technical aspects of it.

- As usual, we started from posting Sacha's News, but with a bit of a twist
  - Since recently, https://orgmode.org shows Org mode-related news on the 
front page
- Mailing list feature discussions, polls, and announcements
- Org mode section of Sacha's News

- Suhail asked about the status of 3 bugs reports posted on Org mailing list 
recently

  - https://yhetil.org/orgmode/87h6e134sp@gmail.com/
- This one is about completion of :async header argument in
  "shell" blocks, where "shell" is not literally shell, but
  "bash", "csh", etc. The completion only works for "shell"
  blocks, but not for other blocks.
  - This is simply an omission in ob-shell.el
  - ob-shell is implemented in the following way
1. Generic "shell" backend is defined
2. Other backends like "bash", "csh", "fish" (full list in
   ~org-babel-shell-names~) are defined based on the generic
   backend in ~org-babel-shell-initialize~
3. ~org-babel-shell-initialize~ fails to define
   ~org-babel-header-args:~ - variable used to
   compute completions.
4. The fix is easy; just need time to get there.
   - [2024-06-22 Sat] Fixed.
 - 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=e60c

  - https://yhetil.org/orgmode/87cyop3445@gmail.com/
- This is a similar issue related to ~org-babel-shell-initialize~
- This time, ~org-babel--initiate-session~ is not
  defined for specific shells
- The problem is more severe than completion though. It renders
  =C-u C-c '= (~org-edit-special~) unusable.
  - ~org-edit-special~ /without/ prefix argument opens code block at point 
for editing
  - ~org-edit-special~ /with/ prefix argument should instead open
associated session for code block with =:session ...= header arg
- Because of the bug, this does not currently work for shell blocks
  - [2024-06-22 Sat] Fixed.
- 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5b366a73
- 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=5e9ac146

  - https://yhetil.org/orgmode/87cyonhuq3@gmail.com/
- This report is about regression of =#+bind: ...= keywords in the new Org 
9.7
- Fixed. 
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=96113f3b5

- Karl Voit (publicvoit) shared his recent bug report for helm-org-rifle

  - https://github.com/alphapapa/org-rifle/issues/85

  - The problem he experiences is with parts of outline path being
invisible in the candidates buffer as long as they are folded

  - The likely reason with the way folding is done in Org mode 9.6.
Org 9.6 (and Org 9.7 for Emacs <29) use 'invisible text property
to fold headings. If such folded headings are copied verbatim from
the Org buffer, they may remain invisible.
- If my guess is right, setting ~org-fold-core-style~ to ~overlays~
  should make things work again in helm-org-rifle

  - Note that Org 9.7 now moves towards restoring the old approach -
using overlays to fold staff. This is because built-in isearch.el,
query-replace-regexp, and a number of external packages (like
evil) only support searching (and revealing!) invisible text when
it is hidden via overlays. (I was hoping that it can be possible
to work around such limitation, but constant stream of bug reports
and growing pile of fragile workarounds proved that text hidden
via text properties cannot reliably searched in practice; alas...)
- As an unfortunate side effect of this, I had to revert feature
  introduced in Org 9.6 - searching inside hidden parts of the
  links
- See https://orgmode.org/Changes.html (It is no longer possible
  to reveal hidden parts of the links during isearch)


- We went on talking about org-ql vs. helm-org-rifle

  - org-ql is generally more flexible as it allows more than just
plain text + outline search
- In org-ql, one can quickly match headings by specific
  properties, tags, timestamps, etc
- In addition, org-ql, since recently, has integration with
  built-in completion frameworks, and their extensions like vertico.
- Of course, helm interface is also there - helm-org-ql

  - However, as it turns out, org-ql lacks one important feature Karl
particularly likes.

In helm-org-rifle, when you enter search string interactively, if
the match is inside a heading, the line containing match is
displayed in addition to the outline path to the heading. This
provides a valuable additional context - you can briefly look what
exactly inside a heading is matched.

- [2024-06-15 Sat] alphapapa, in
  https://github.com/alphapapa/org-rifle/issues/85, pointed out
  that one can 

Re: [BUG] error "Invalid search bound (wrong side of point)" [9.6.15, (release_9.6.15 @ /usr/share/emacs/29.3/lisp/org/)]

[Ihor Radchenko]

Ihor Radchenko  writes:

> Vidianos Giannitsis  writes:
>
>> I got this error while working on an org file. It appears to be
>> something related to org-fragtog, or the creation of the latex
>> preview. Its the first time I see it and I am not sure how it happened
>> (can't reproduce it), but the error itself asked that I report this to
>> the mailing list, so here I am, in case this is helpful.
>
> Thanks for the report!
> There will be improvements to the cache in the next Org mode release. I
> hope that the inflow of cache-related problems will cease once Org 9.7
> is released.

Closing.
Canceled.

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