Re: New try at multi-lingual export to latex/pdf using pdflatex and babel

[Pedro Andres Aranda Gutierrez]

Hi,

Attached is a _proof of concept_ for supporting AUTO in
\usepackage{fontenc}. Just an idea of how things could evolve.
This only uses a variable you can define as directory or file local to
control what is generated in the LaTeX file.
Could be expanded in the future to check #+language:

Best, /PA

On Mon, 22 Jan 2024 at 14:40, Juan Manuel Macías 
wrote:

> Ihor Radchenko writes:
>
> > Juan Manuel Macías  writes:
> >
> >> Pedro Andres Aranda Gutierrez writes:
> >>
> >>> +#+begin_example
> >>> +,#+latex_class_options: [greek,spanish,oneside]
> >>> +,#+language: es
> >>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> >>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> >>> +#+end_example
> >>
> >> I think this example doesn't take advantage of the AUTO facility, which
> >> is what the section is about.
>
> > Do you have any suggestions how to improve the patch?
>
> I would give an example that did include the AUTO 'facility', to unify
> with the rest of the examples in the section:
>
> #+language: es
> #+latex_header: \usepackage[greek,ngerman,AUTO]{babel}
> #+latex_header: \usepackage{alphabeta} % to support greek script
>
> It is also said in the patch that this example is for pdfTeX, but it
> works equally well for LuaTeX and XeTeX, since Babel and alphabeta
> packages support both engines. However, the alphabeta package is not a
> specific package for writing texts in Greek. Rather, according to the
> package documentation: "The alphabeta package makes the standard macros
> for Greek letters in mathematical mode also available in text mode." In
> pdfTeX it is useful because you can enter the Greek input directly in
> Unicode. But in LuaTeX or XeTeX it would be unnecessary, since Greek can
> be written directly, without the help of additional packages.
>
> >> ... Btw, maybe it would be nice to extend ''AUTO'' to
> >> latex_class_options and \PassOptionsToPackage? Something like:
> >
> > It would really be nice to have an ox-latex maintainer who is deeply
> > familiar with LaTeX :)
>
> My knowledge of LaTeX (and Elisp) has huge gaps :-). Of course, I am
> willing to learn everything I can. And, naturally, I would like to help
> in any way I can. But my main problem (currently) is the lack of time to
> dedicate myself to it. My presence on this list is intermittent, and
> that for a maintainer is horrible. Maybe in a few months (spring
> perhaps), when my personal situation stabilizes a little, I could
> consider it...
>
> Best regards,
>
> Juan Manuel
>
>

-- 
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
From 66634498275a4dbea4cb8dc225db28bdea1bdf1a Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Tue, 23 Jan 2024 08:31:46 +0100
Subject: [PATCH] PoC: support AUTO for the fontenc package in LaTeX exports

* lisp/org.el: Add `org-latex-fontenc' to support translation for
  \usepackage[AUTO]{fontenc}

* lisp/ox-latex.el: Implement rudimentary translation for the above

---
 lisp/org.el  | 17 -
 lisp/ox-latex.el | 36 
 2 files changed, 36 insertions(+), 17 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index cf9abafac..d4356e15d 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3401,9 +3401,16 @@ header, or they will be appended."
 	  x))
 	  (default-value var)))
 
+(defcustom org-latex-fontenc "T1"
+  "The fontenc for the file. Customise to LGR,T1 when including
+Greek, etc."
+  :group 'org-export-latex
+  :type 'string
+  :safe #'stringp)
+
 (defcustom org-latex-default-packages-alist
   '(("AUTO" "inputenc"  t ("pdflatex"))
-("T1"   "fontenc"   t ("pdflatex"))
+("AUTO" "fontenc"   t ("pdflatex"))
 ("" "graphicx"  t)
 ("" "longtable" nil)
 ("" "wrapfig"   nil)
@@ -15159,20 +15166,20 @@ INCREMENT-STEP divisor."
 	(setq hour (mod hour 24))
 	(setq pos-match-group 1
   new (format "-%02d:%02d" hour minute)))
-   
+
((org-pos-in-match-range pos 6) ;; POS on "dmwy" repeater char.
 	(setq pos-match-group 6
   new (car (rassoc (+ nincrements (cdr (assoc (match-string 6 ts-string) idx))) idx
-   
+
((org-pos-in-match-range pos 5) ;; POS on X in "Xd" repeater.
 	(setq pos-match-group 5
   ;; Never drop below X=1.
   new (format "%d" (max 1 (+ nincrements (string-to-number (match-string 5 ts-string)))
-   
+
((org-pos-in-match-range pos 9) ;; POS on "dmwy" repeater in warning interval.
 	(setq pos-match-group 9
   new (car (rassoc (+ nincrements (cdr (assoc (match-string 9 ts-string) idx))) idx
-   
+
((org-pos-in-match-range pos 8) ;; POS on X in "Xd" in warning interval.
 	(setq pos-match-group 8
   ;; Never drop below X=0.
diff --git a/lisp/ox-l

Re: Inconsistent handling of multi-line properties

[Jack Kamm]

Ihor Radchenko  writes:

> Ihor Radchenko  writes:
>
>>> I have noticed that properties that stretch over multiple lines using 
>>> the :value+: syntax are ignored by org-element-property and therefore 
>>> also by e.g. org-export-get-node-property when exporting to ics via 
>>> ox-icalendar.el (see example below). I was wondering now whether this is 
>>> intentional and to be expected or a bug?
>
>> 3. Change ox-icalendar to consider :LOCATION+ properties and merge them
>>during export.
>
> I went with this approach.
> See the attached tentative patch.

Thanks Ihor -- this is a nice improvement for ox-icalendar.

My only suggestion would be to add this information and your small
location example to the manual.

> CCing Jack - you expressed interest in ox-icalendar in the past.
>
> P.S. We need a maintainer for ox-icalendar ;)

Sure, I'm happy to help with this :)

Please forward/CC any issues you'd like me to look at.  I'll setup an
email filter to try and catch iCalendar related subjects, but sometimes
I miss things on the list.

Possible LaTeX export bug: Footnotes in items

[Eric Anderson]

Hi All,

I'm new to the developers' mailing list, so I hope this is the right place
to post potential bugs.  I don't claim to know exactly why, but at least
for certain TOC options, the LaTeX exporter produces invalid code for item
titles containing footnotes.  I've attached a minimal (non)working example.

The resulting LaTeX code (also attached) uses \footnote inside \section and
\paragraph macros, producing compiler errors.  A little googling turns up
the following comp.text.tex usenet post
https://comp.text.tex.narkive.com/lkZWQYaS/using-footnotes-in-paragraph,
explaining that \footnote is fragile and cannot be used in those contexts
without \protect.  Manually adding \protect before \footnote in the
automatically-generated tex file appears to produce correct results.

I don't know if the best fix is to always \protect \footnotes in LaTeX
export, or if more contextual smarts are required, but this seems like an
issue worth addressing.

Cheers!
Eric Anderson


org-bug-mwe.org
Description: Binary data


org-bug-mwe.tex
Description: Binary data

Re: Slowness of org-agenda-redo in org 9.7 vs 9.6.7

[Ihor Radchenko]

dark.key8...@151e.ai writes:

> make repro still can't load the correct org because make apparently
> launches emacs from my $HOME instead of the repo directory (I tested
> manually that `default-directory' is correct when calling emacs -Q) so
> I'm think make is reverting to $HOME when launching emacs and I have no
> idea why.

May you post the output of

make -d repro

?

>> This is normally not required - Emacs package manager should take care
>> about this. Although, if you have problems with make autoloads and use
>> Org mode from git folder, I don't know what happens.
>
> I'm using straight.el. Even though I nuked the build and repo org folders
> from straight, the above (about git manual cloning) makes me think it's
> interfering somehow.

There was a bug in straight.el + the latest Org -
https://github.com/radian-software/straight.el/issues/1107
I am not sure if the fix landed on stable branch or it is still on the
develop.

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

Re: [BUG] org-lint tells to move #+name to wrong place in results block

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

>>> FR: would it be possible to resolve such links?
>> 
>> What is the purpose? Why not simply leaving the result name same as the
>> source block?
>
> I have Python "IN" blocks generating Python "OUT" blocks that may end up
> on different pages after exporting to LaTeX and PDF.
> The FR would allow to link always to the correct page.

Patches welcome.
Another option is :post argument that will add the necessary #+name. 

> I have 10 org-lint warnings of this type for a 150 page PDF document.
> Most of those "OUT" blocks are on the same page as their corresponding
> "IN" blocks, but I have worked around this limitation.
>
> I can live without the requested feature, but it would be a way to 
> eliminate
> an org-lint test.

"i" in org-lint buffer will remove all the warnings similar to warning
at point.

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

Re: [BUG] org-lint tells to move #+name to wrong place in results block

[gerard . vermeulen]

On 22.01.2024 19:15, Ihor Radchenko wrote:

gerard.vermeu...@posteo.net writes:


For the listings below org-lint tells me to move "#+name: OUT"
downwards:

Line Trust Warning
  17 high   #+name: in results of evaluation will be replaced by
  re-evaluating the src block.  Use #+name in the block instead.

This is not true


Good point.
The real problem is indeed different - when the source block has
:exports code, results will be removed and any links to OUT will become
invalid:


..., but exporting says:  Unable to resolve the link "OUT".



FR: would it be possible to resolve such links?


What is the purpose? Why not simply leaving the result name same as the
source block?


I have Python "IN" blocks generating Python "OUT" blocks that may end up
on different pages after exporting to LaTeX and PDF.
The FR would allow to link always to the correct page.

I have 10 org-lint warnings of this type for a 150 page PDF document.
Most of those "OUT" blocks are on the same page as their corresponding
"IN" blocks, but I have worked around this limitation.

I can live without the requested feature, but it would be a way to 
eliminate

an org-lint test.

Best regards -- Gerard

Re: [BUG] org-lint tells to move #+name to wrong place in results block

[Ihor Radchenko]

gerard.vermeu...@posteo.net writes:

> For the listings below org-lint tells me to move "#+name: OUT"
> downwards:
>
> Line Trust Warning
>   17 high   #+name: in results of evaluation will be replaced by
>   re-evaluating the src block.  Use #+name in the block instead.
>
> This is not true

Good point.
The real problem is indeed different - when the source block has
:exports code, results will be removed and any links to OUT will become
invalid:

> ..., but exporting says:  Unable to resolve the link "OUT".

> FR: would it be possible to resolve such links?

What is the purpose? Why not simply leaving the result name same as the
source block?

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

[BUG] org-lint tells to move #+name to wrong place in results block

[gerard . vermeulen]

For the listings below org-lint tells me to move "#+name: OUT"
downwards:

   Line Trust Warning
 17 high   #+name: in results of evaluation will be replaced by
 re-evaluating the src block.  Use #+name in the block instead.

This is not true, and after I move it below "#+RESULTS: IN"
re-evalution makes "#+name: OUT" disappear.

#+header: :wrap "src emacs-lisp"
#+name: IN
#+begin_src emacs-lisp
3
#+end_src

#+name: OUT
#+RESULTS: IN
#+begin_src emacs-lisp
3
#+end_src

Listing [[IN]] produces listing [[OUT]], clicking each link in Org
jumps to the linked block, TAB-bing on "#+name: OUT" folds the
block, but exporting says:  Unable to resolve the link "OUT".

Org mode version 9.7-pre (release_9.6.17-1081-g83696b)

FR: would it be possible to resolve such links?

Regards -- Gerard

Re: Org mode MIME type

[Max Nikulin]

On 21/01/2024 22:11, Timothy wrote:



However shouldn’t it be “text/x-org”, not just “text/org”? (I am against
“application/*” variants since it is a text based format).


As per  the de-facto mime type for Org is `text/org'.

Why not `text/x-org'? Among other reasons, the `x-' prefix is depreciated as of 
RFC
6648 (2012).


Thanks, I was not aware of this RFC.


Existing MIME type databases that use `text/x-org' should be updated
to use `text/org'.


It's Emacs that has text/x-org.

Out of curiosity I tried to grep local cache of the mailing list. There 
are a few attachments having text/plain, almost the same number for 
text/org and text/x-org. The most popular media type is 
application/vnd.lotus-organizer, its count roughly the sum of other 
variants.


Since Emacs has text/x-org for a decade, perhaps it is still reasonable 
to ask for an alias in shared-mime-info. Anyway it is better to remove 
dash from "Org-mode file" comment there.

Re: Slowness of org-agenda-redo in org 9.7 vs 9.6.7

[dark . key8799]

On Mon, Jan 22, 2024, at 20:05, Ihor Radchenko wrote:
> This is very strange. We try hard to use only GNU make machinery + Emacs
> there. May it help to remove local.mk from org git folder?

Ok, I didn't do that but recloned the repo manually (I was working from a 
clone made by straight.el) and the org-version.el and org-loaddefs.el are
now properly generating.

make repro still can't load the correct org because make apparently
launches emacs from my $HOME instead of the repo directory (I tested
manually that `default-directory' is correct when calling emacs -Q) so
I'm think make is reverting to $HOME when launching emacs and I have no
idea why.

> This is normally not required - Emacs package manager should take care
> about this. Although, if you have problems with make autoloads and use
> Org mode from git folder, I don't know what happens.

I'm using straight.el. Even though I nuked the build and repo org folders
from straight, the above (about git manual cloning) makes me think it's
interfering somehow.

Anyway, all that seems far from org, thanks for pointing me in the right
direction.

-- 
Alexandre Avanian

Re: New try at multi-lingual export to latex/pdf using pdflatex and babel

[Juan Manuel Macías]

Ihor Radchenko writes:

> Juan Manuel Macías  writes:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>>> +#+begin_example
>>> +,#+latex_class_options: [greek,spanish,oneside]
>>> +,#+language: es
>>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
>>> +#+end_example
>>
>> I think this example doesn't take advantage of the AUTO facility, which
>> is what the section is about.

> Do you have any suggestions how to improve the patch?

I would give an example that did include the AUTO 'facility', to unify
with the rest of the examples in the section:

#+language: es
#+latex_header: \usepackage[greek,ngerman,AUTO]{babel}
#+latex_header: \usepackage{alphabeta} % to support greek script

It is also said in the patch that this example is for pdfTeX, but it
works equally well for LuaTeX and XeTeX, since Babel and alphabeta
packages support both engines. However, the alphabeta package is not a
specific package for writing texts in Greek. Rather, according to the
package documentation: "The alphabeta package makes the standard macros
for Greek letters in mathematical mode also available in text mode." In
pdfTeX it is useful because you can enter the Greek input directly in
Unicode. But in LuaTeX or XeTeX it would be unnecessary, since Greek can
be written directly, without the help of additional packages.

>> ... Btw, maybe it would be nice to extend ''AUTO'' to
>> latex_class_options and \PassOptionsToPackage? Something like:
>
> It would really be nice to have an ox-latex maintainer who is deeply
> familiar with LaTeX :)

My knowledge of LaTeX (and Elisp) has huge gaps :-). Of course, I am
willing to learn everything I can. And, naturally, I would like to help
in any way I can. But my main problem (currently) is the lack of time to
dedicate myself to it. My presence on this list is intermittent, and
that for a maintainer is horrible. Maybe in a few months (spring
perhaps), when my personal situation stabilizes a little, I could
consider it...

Best regards,

Juan Manuel 

Re: [PATCH] Re: [feature request] startup variable for link display

[Ihor Radchenko]

Ihor Radchenko  writes:

> See the attached patch.

Applied, onto main; after changing the terms to
literallinks/descriptivelinks as suggested.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=dd4fd0299
Done.

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

Re: [PATCH] Add buffer-local setting to request specific ESS process/session name (was: [PATCH] Set Python shell in Org edit buffer)

[Ihor Radchenko]

"Sparapani, Rodney"  writes:

> I’ve test that and it works for me per your prescription below.
> And, I have committed it to the ESS git repo.

Thank you!
May I know which version of ESS will have this commit?

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

Re: New try at multi-lingual export to latex/pdf using pdflatex and babel

[Ihor Radchenko]

Juan Manuel Macías  writes:

> Pedro Andres Aranda Gutierrez writes:
>
>> +#+begin_example
>> +,#+latex_class_options: [greek,spanish,oneside]
>> +,#+language: es
>> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>> +,#+latex_header: \usepackage{alphabeta} % to support greek script
>> +#+end_example
>
> I think this example doesn't take advantage of the AUTO facility, which
> is what the section is about.

Do you have any suggestions how to improve the patch?

> ... Btw, maybe it would be nice to extend ''AUTO'' to
> latex_class_options and \PassOptionsToPackage? Something like:

It would really be nice to have an ox-latex maintainer who is deeply
familiar with LaTeX :)

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

Re: Slowness of org-agenda-redo in org 9.7 vs 9.6.7

[Ihor Radchenko]

dark.key8...@151e.ai writes:

> Side note about "make repro": it wouldn't load org from the repo.
> Trying to understand why, running "make autoloads", I was expecting
> (perhaps wrongly) that `org-version.el' and `org-loaddefs.el' would be
> generated in the repo directory/sub-directories but that never
> happened (and make didn't output any error). Launching "emacs -Q -l
> init.el" with init.el just having adding the repo to `load-path' and
> requiring org would fail on missing loaddefs.

This is very strange. We try hard to use only GNU make machinery + Emacs
there. May it help to remove local.mk from org git folder?

> Is there a standard procedure to 1/ follow when switching org version and/or 
> 2/ clean all byte-compiled/native-compiled files in this kind of situation?

This is normally not required - Emacs package manager should take care
about this. Although, if you have problems with make autoloads and use
Org mode from git folder, I don't know what happens.

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

Re: org-publish-sitemap-file-entry-format documented despite being obsolete

[Ihor Radchenko]

Stefan Kangas  writes:

> BTW, I see the following symbols that are only mentioned once in
> emacs.git, so I suspect some of them might be typos.
>
> I fixed a few typos on master in emacs.git already (9364c28959a):
>
> org-col-cookies
> org-export--populate-ignore-list
> org-latex--org-align-string-tabbing
> org-publish-sitemap-date-format
> org-table-hide-column
> org-table-increment
> org-translate-link-from-planner
> org-try-structure-completion

Thanks for the heads-up!
It looks like you fixed `org-latex--org-align-string-tabbing', but not
the rest.

I will go through them and see what should be fixed. Not all the
mentions above are obvious to fix.

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

Re: Inconsistent handling of multi-line properties

[Ihor Radchenko]

Ihor Radchenko  writes:

>> I have noticed that properties that stretch over multiple lines using 
>> the :value+: syntax are ignored by org-element-property and therefore 
>> also by e.g. org-export-get-node-property when exporting to ics via 
>> ox-icalendar.el (see example below). I was wondering now whether this is 
>> intentional and to be expected or a bug?

> 3. Change ox-icalendar to consider :LOCATION+ properties and merge them
>during export.

I went with this approach.
See the attached tentative patch.

CCing Jack - you expressed interest in ox-icalendar in the past.

P.S. We need a maintainer for ox-icalendar ;)

>From 84fb56dcbccc2c99be4fed172184c25cfe2a3395 Mon Sep 17 00:00:00 2001
Message-ID: <84fb56dcbccc2c99be4fed172184c25cfe2a3395.1705922024.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Mon, 22 Jan 2024 12:12:16 +0100
Subject: [PATCH] ox-icalendar: Add support for multi-line SUMMARY, LOCATION,
 and DESCRIPTION

* lisp/ox-icalendar.el (org-icalendar-entry): Use `org-entry-get' to
account for both PROP and PROP+ in SUMMARY, LOCATION, and DESCRIPTION
properties.  Use newline as accumulated value separator.
* etc/ORG-NEWS (iCalendar export now supports multiline =SUMMARY=,
=LOCATION=, and =DESCRIPTION= properties): Announce the breaking
change.

Reported-by: Hanno Perrey 
Link: https://orgmode.org/list/87o821dv7o.fsf@localhost
---
 etc/ORG-NEWS | 26 ++
 lisp/ox-icalendar.el | 19 +++
 2 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 847ddf614..dc6886318 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,32 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** Important announcements and breaking changes
+*** iCalendar export now supports multiline =SUMMARY=, =LOCATION=, and =DESCRIPTION= properties
+
+Previously, it was not possible to specify multi-line location,
+summary, or description when exporting to iCalendar.
+
+In the following example, =LOCATION= was exported as "Someplace",
+ignoring the other lines.
+
+#+begin_src org
+,* heading with multi-line property
+:PROPERTIES:
+:LOCATION: Someplace
+:LOCATION+: Some Street 5
+:LOCATION+: 12345 Small Town
+:END:
+#+end_src
+
+Now, =SUMMARY+=, =LOCATION+=, and =DESCRIPTION+= properties can be
+used to create multi-line values.
+
+In the above example, =LOCATION= is now exported as
+
+: Someplace
+: Some Street 5
+: 12345 Small Town
+
 *** ~org-agenda-search-headline-for-time~ now ignores all the timestamp in headings
 
 Previously, ~org-agenda-search-headline-for-time~ made Org agenda
diff --git a/lisp/ox-icalendar.el b/lisp/ox-icalendar.el
index 3dd2c88d8..f6513563d 100644
--- a/lisp/ox-icalendar.el
+++ b/lisp/ox-icalendar.el
@@ -643,13 +643,15 @@ (defun org-icalendar-entry (entry contents info)
(let ((todo-type (org-element-property :todo-type entry))
 	 (uid (or (org-element-property :ID entry) (org-id-new)))
 	 (summary (org-icalendar-cleanup-string
-		   (or (org-element-property :SUMMARY entry)
-			   (org-export-data
-			(org-element-property :title entry) info
-	 (loc (org-icalendar-cleanup-string
-		   (org-export-get-node-property
-		:LOCATION entry
-		(org-property-inherit-p "LOCATION"
+		   (or
+(let ((org-property-separators '(("SUMMARY" . "\n"
+  (org-entry-get entry "SUMMARY"))
+			(org-export-data
+			 (org-element-property :title entry) info
+	 (loc
+  (let ((org-property-separators '(("LOCATION" . "\n"
+(org-icalendar-cleanup-string
+ (org-entry-get entry "LOCATION" 'selective
 	 (class (org-icalendar-cleanup-string
 		 (org-export-get-node-property
 		  :CLASS entry
@@ -658,7 +660,8 @@ (defun org-icalendar-entry (entry contents info)
 	 ;; (headline) or contents (inlinetask).
 	 (desc
 	  (org-icalendar-cleanup-string
-	   (or (org-element-property :DESCRIPTION entry)
+	   (or (let ((org-property-separators '(("DESCRIPTION" . "\n"
+ (org-entry-get entry "DESCRIPTION"))
 		   (let ((contents (org-export-data inside info)))
 		 (cond
 		  ((not (org-string-nw-p contents)) nil)
-- 
2.43.0


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

Re: Patch to allow adjusting latex fragment display scale factor

[Ihor Radchenko]

Matt Huszagh  writes:

> Yep, we can close/cancel this patch. I had been using that feature to
> permit rescaling latex fragments for font size changes, but that's
> already handled by the current implementation.

Canceled.

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