Re: bug#68687: [PATCH] Use text/org media type

[Eli Zaretskii]

> Cc: 68...@debbugs.gnu.org, Max Nikulin ,
>  emacs-orgmode@gnu.org
> From: Ihor Radchenko 
> Date: Thu, 25 Jan 2024 23:43:14 +
> 
> However, AFAIU, text/org will fall into "standards tree" in IANA media
> type specification, which means that it MUST be registered, as described
> in https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1
> 
> Registering text/org media type requires syntax spec. We are
> still working on format Org mode syntax specifications. See
> https://list.orgmode.org/orgmode/871rjhha8t@gmail.com/ and
> https://orgmode.org/worg/org-syntax.html
> 
> The spec is still not fully finalized, so we are not yet initiating the
> registration, as we will need to repeat it again if we decide to make
> further changes (https://www.rfc-editor.org/rfc/rfc6838.html#section-5.5)

I hope the process of finalizing the Org spec and moving to its
registration will not fall between the cracks.

Re: bug#68687: [PATCH] Use text/org media type

[Eli Zaretskii]

> Cc: emacs-orgmode@gnu.org
> From: Stefan Kangas 
> Date: Thu, 25 Jan 2024 15:10:27 -0800
> 
> Max Nikulin  writes:
> 
> > Hi,
> >
> > I suggest to make the media type used for Org mode files consistent with
> > the one used by XDG https://gitlab.freedesktop.org/xdg/shared-mime-info
> > Currently Emacs has text/x-org, however "x-" prefix is not recommended
> > by IANA any more, see https://www.rfc-editor.org/rfc/rfc6648
> > "Deprecating the "X-" Prefix and Similar Constructs in Application
> > Protocols"
> >
> > Ideally somebody should file a request to IANA to register the text/org
> > media type.
> > https://www.iana.org/assignments/media-types/media-types.xhtml
> 
> Eli, Ihor, what do you think?

I agree, but since Ihor indicates that is impossible for now, we will
have to live with the current situation for at least the near future.

So I think we should install these changes, but please audit them
carefully to make sure we don't create any backward-compatibility
problems unnecessarily.  For example:

> > diff --git a/lisp/gnus/mm-uu.el b/lisp/gnus/mm-uu.el
> > index 3c7e3cbdf1a..b10da0c143a 100644
> > --- a/lisp/gnus/mm-uu.el
> > +++ b/lisp/gnus/mm-uu.el
> > @@ -394,7 +394,7 @@ (defun mm-uu-emacs-sources-extract ()
> >
> >  (defun mm-uu-org-src-code-block-extract ()
> >(mm-make-handle (mm-uu-copy-to-buffer start-point end-point)
> > - '("text/x-org" (charset . gnus-decoded
> > + '("text/org" (charset . gnus-decoded
> >
> >  (defvar gnus-newsgroup-name)
> >
> > diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
> > index 5ff75deb4e6..900099433c4 100644
> > --- a/lisp/net/mailcap.el
> > +++ b/lisp/net/mailcap.el
> > @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
> >  (".jpe"   . "image/jpeg")
> >  (".jpeg"  . "image/jpeg")
> >  (".webp"  . "image/webp")
> > -(".org"   . "text/x-org"))
> > +;; May be overridden by application/vnd.lotus-organizer in 
> > /etc/mime.types.
> > +(".org"   . "text/org"))

I'm not sure the removal of text/x-org in these two hunks is a good
idea: could it perhaps cause trouble to someone, e.g. if an email
message is sent from Emacs with this change and read by Emacs without
it?  (I don't use these packages, so I wouldn't know the answer.)  In
general, I'd prefer changes that add text/org without removing support
for text/x-org.

Thanks.

bug#52587: bug#59141: 28.1.90; Face :extend when all the line but trailing \n is invisible

[Eli Zaretskii]

> From: Ihor Radchenko 
> Cc: 59...@debbugs.gnu.org
> Date: Thu, 25 Jan 2024 22:53:45 +
> 
> Kévin Le Gouguec  writes:
> 
> >> I do not see anything wrong on the Org side.
> >> Maybe Emacs should not apply :extent t attribute to the newline when the
> >> text in fontified line is hidden?
> >
> > IIUC, this is bug#52587?
> >
> > The conclusion there, AFAIR, was "it's unfortunate, but that's the
> > design for now; let's rediscuss when we see some patches for outline.el
> > (or the specific modes that use extended backgrounds)".
> 
> I fixed the problem on Org side in bug#65896.
> I think that this bug report and maybe even bug#52587 can be closed.
> Unless it is still of interest to develop some solution on Emacs side.

Thanks, I'm closing both of those bugs.

Re: Inconsistent handling of multi-line properties

[Jack Kamm]

Ihor Radchenko  writes:

> Thanks!
> You can replace Maintainer: line in ox-icalendar.el with your name.

Done.

> Sure.
> I checked my records and found one outstanding issue related to
> ox-icalendar -
> https://list.orgmode.org/orgmode/20211230225919.1a660...@hsu-hh.de/
>
> The patch proposed by Detlef still has outstanding issues to address,
> but the author does not have free time to work on this since the
> beginning of last year (I did several follow-ups off list; latest in
> September).
>
> At this point, we should either cancel that patch or amend it ourselves
> and apply.

Thanks -- I will amend the patch, and send an update to that thread
before applying.

On org-syntax and IANA MIME type registration

[Timothy]

Hi All,

With the recent mention of the text/org mime type, and registering it as an IANA
in-tree MIME type in particular, I’d like to draw attention to this part of
:

> When review is required, a change request may be denied if it renders entities
> that were valid under the previous definition invalid under the new 
> definition.

While the org-syntax document is a work in progress to accurately describe the
current state of affairs, there are currently supported syntactic elements that
I think are broadly seen as “would be nice if we didn’t do that”. For example:
the special switch syntax in babel headers, and support for $-maths.

This does make me wonder if we should actually try to register a slightly
different org-syntax to “what org-mode parses”, without these elements that we
now think we’re better off without, but have org-mode still parse them.

My thinking is we don’t want to lock ourselves into a situation where we would
/like/ to deprecate certain syntax over the long term, but are unable to do so
without diverging from the IANA-registered specification, and can’t register the
change in syntax because of the paragraph I’ve quoted.

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at .
Support Org development at ,
or support my work at .

Re: bug#68687: [PATCH] Use text/org media type

[Ihor Radchenko]

Stefan Kangas  writes:

>> I suggest to make the media type used for Org mode files consistent with
>> the one used by XDG https://gitlab.freedesktop.org/xdg/shared-mime-info
>> Currently Emacs has text/x-org, however "x-" prefix is not recommended
>> by IANA any more, see https://www.rfc-editor.org/rfc/rfc6648
>> "Deprecating the "X-" Prefix and Similar Constructs in Application
>> Protocols"
>> Ideally somebody should file a request to IANA to register the text/org
>> media type.
>> https://www.iana.org/assignments/media-types/media-types.xhtml
>
> Eli, Ihor, what do you think?

I see using text/org as an improvement. text/x-org is likely useless.
At least,
https://github.com/jeremy-compostella/org-msg/blob/master/org-msg.el
uses text/org, which may appear in email parts.

However, AFAIU, text/org will fall into "standards tree" in IANA media
type specification, which means that it MUST be registered, as described
in https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1

Registering text/org media type requires syntax spec. We are
still working on format Org mode syntax specifications. See
https://list.orgmode.org/orgmode/871rjhha8t@gmail.com/ and
https://orgmode.org/worg/org-syntax.html

The spec is still not fully finalized, so we are not yet initiating the
registration, as we will need to repeat it again if we decide to make
further changes (https://www.rfc-editor.org/rfc/rfc6838.html#section-5.5)

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

Re: bug#68687: [PATCH] Use text/org media type

[Stefan Kangas]

Max Nikulin  writes:

> Hi,
>
> I suggest to make the media type used for Org mode files consistent with
> the one used by XDG https://gitlab.freedesktop.org/xdg/shared-mime-info
> Currently Emacs has text/x-org, however "x-" prefix is not recommended
> by IANA any more, see https://www.rfc-editor.org/rfc/rfc6648
> "Deprecating the "X-" Prefix and Similar Constructs in Application
> Protocols"
>
> Ideally somebody should file a request to IANA to register the text/org
> media type.
> https://www.iana.org/assignments/media-types/media-types.xhtml

Eli, Ihor, what do you think?

> However I have no idea concerning a conflict due to the .org file name
> suffix. It was used in the past by early versions of Lotus Organizer.
> https://www.iana.org/assignments/media-types/application/vnd.lotus-organizer
>
> I am unsure if gnus-related code should be committed to some other
> repository at first. I am not a gnus user, so I do not mind if an
> alternative change will be committed.
>
> See also
> emacs-orgmode: Org mode MIME type. Sun, 21 Jan 2024 20:56:15 +0700.
> https://list.orgmode.org/6d94fff4-4d30-4121-bfd1-f267cb5b6...@gmail.com
> From 8b71393625f11590e99896808bbd04ed83f7917e Mon Sep 17 00:00:00 2001
> From: Max Nikulin 
> Date: Wed, 24 Jan 2024 21:16:28 +0700
> Subject: [PATCH] Use text/org media type
>
> Avoid "x-" prefix deprecated by rfc6648 for Org mode media type.
> * lisp/net/mailcap.el (mailcap-mime-extensions):
> * lisp/gnus/mm-uu.el (mm-uu-org-src-code-block-extract): Replace
> text/x-org by text/org.
> * lisp/gnus/mm-decode.el (mm-inline-media-tests): Allow text/org in
> addition to text/x-org.
>
> Make media type defined for Org mode consistent with
> 
>
> See emacs-orgmode: Org mode MIME type. Sun, 21 Jan 2024 20:56:15 +0700.
> https://list.orgmode.org/6d94fff4-4d30-4121-bfd1-f267cb5b6...@gmail.com
> ---
>  lisp/gnus/mm-decode.el | 1 +
>  lisp/gnus/mm-uu.el | 2 +-
>  lisp/net/mailcap.el| 3 ++-
>  3 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lisp/gnus/mm-decode.el b/lisp/gnus/mm-decode.el
> index f91755e967b..cae737e5a3e 100644
> --- a/lisp/gnus/mm-decode.el
> +++ b/lisp/gnus/mm-decode.el
> @@ -246,6 +246,7 @@ (defcustom mm-inline-media-tests
>  ("text/x-sh" mm-display-shell-script-inline identity)
>  ("application/javascript" mm-display-javascript-inline identity)
>  ("text/dns" mm-display-dns-inline identity)
> +("text/org" mm-display-org-inline identity)
>  ("text/x-org" mm-display-org-inline identity)
>  ("text/html"
>   mm-inline-text-html
> diff --git a/lisp/gnus/mm-uu.el b/lisp/gnus/mm-uu.el
> index 3c7e3cbdf1a..b10da0c143a 100644
> --- a/lisp/gnus/mm-uu.el
> +++ b/lisp/gnus/mm-uu.el
> @@ -394,7 +394,7 @@ (defun mm-uu-emacs-sources-extract ()
>
>  (defun mm-uu-org-src-code-block-extract ()
>(mm-make-handle (mm-uu-copy-to-buffer start-point end-point)
> -   '("text/x-org" (charset . gnus-decoded
> +   '("text/org" (charset . gnus-decoded
>
>  (defvar gnus-newsgroup-name)
>
> diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
> index 5ff75deb4e6..900099433c4 100644
> --- a/lisp/net/mailcap.el
> +++ b/lisp/net/mailcap.el
> @@ -989,7 +989,8 @@ (defvar mailcap-mime-extensions
>  (".jpe"   . "image/jpeg")
>  (".jpeg"  . "image/jpeg")
>  (".webp"  . "image/webp")
> -(".org"   . "text/x-org"))
> +;; May be overridden by application/vnd.lotus-organizer in 
> /etc/mime.types.
> +(".org"   . "text/org"))
>"An alist of file extensions and corresponding MIME content-types.
>  This exists for you to customize the information in Lisp.  It is
>  merged with values from mailcap files by `mailcap-parse-mimetypes'.")
> --
> 2.39.2

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:

> This last remark below can’t possibly be true.  Because I did not intend to 
> trigger
> a release, ESS 24.01.0 was not initially tagged.  However, after I received 
> that email
> from ELPA, it was a fait accompli.  So I fixed some cosmetic issues and 
> tagged it post-haste,
> i.e., ELPA’s announcement is definitely pre-tagging.  So I’m not sure
> where the disconnect is.

Hmm. You are right. The exact rule is following package Version:
comment:

https://git.savannah.gnu.org/cgit/emacs/elpa.git/plain/README

*** Release and devel archives
elpa.gnu.org serves the gnu and nongnu package collections (roughly,
gnu requires FSF copyright assign, nongnu doesn't, but these terms are
not fully defined here).

In addition, elpa.gnu.org serves release and devel versions of each
package. The release version is defined by a change in the =Version:=
header of a package; the devel version is the latest commit.

So, you likely changed Version: in lisp/ess.el first and only then added
git tag.

(I always do this in one go, which is why I never noticed this detail)

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

Re: [PATCH] doc/org-manual.org (Checkboxes): move section 'Checkboxes' from 'TODO Items' to 'Plain Lists'

[Ihor Radchenko]

Sławomir Grochowski  writes:

> I propose to move the section "Checkboxes".
> From "5 TODO Items -> 5.6 Checkboxes"
> To: "2 Document Structure -> 2.6 Plain Lists -> 2.6.1 Checkboxes"
>
> Because checkbox can only exist in a plain list, as a plain list feature.
> So the section should be under 'Plain Lists' heading not under 'TODO Items'.

> Link https://orgmode.org/org.html#Checkboxes would stay the same.
> So it's just a move section to a more suitable place.
> Without changing the content.
>
> What do you think?

Both arrangements are logical. Checkboxes are useful as a complement to
TODO items. And they are also indeed a plain list feature.

In fact, Checkboxes section of the manual was previously under Document
structure. This was changed in release_4.45.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=6a9c670d

So, I am slightly reluctant to revert the change that was previously
made - I presume that Carsten had reasons to move things around.

I do not have a strong opinion here though. If more people chime in here
and support re-arrangement, I will not oppose.

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

Re: [BUG] beamer export

[Leo Butler]

On Wed, Jan 24 2024, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
>> I think the documentation and example needs to be corrected. I have
>> attached a patch.
>
> Thanks! Applied.
> https://git.sr.ht/~bzg/worg/commit/aedea59f

Attached is a second patch to de-lint the ox-beamer tutorial.

Leo

From 7a52949ce25c7576896785ba185f9bd6afc7f12b Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Tue, 23 Jan 2024 11:23:18 -0600
Subject: [PATCH] exporters/beamer/tutorial.org: clean lint warnings

* exporters/beamer/tutorial.org:  convert the informal footnote
markers to Org footnotes.
---
 exporters/beamer/tutorial.org | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/exporters/beamer/tutorial.org b/exporters/beamer/tutorial.org
index f40425ed..ae1ec751 100644
--- a/exporters/beamer/tutorial.org
+++ b/exporters/beamer/tutorial.org
@@ -33,7 +33,7 @@ keybindings]].
 
 * First steps
 ** The export template
-Starting with an empty file called =presentation.org= [1], say, the
+Starting with an empty file called =presentation.org= [fn:1], say, the
 first step is to insert the default org export template (=C-c C-e #=
 with the default keybindings). This will generate something that looks
 like this (some specific entries will vary):
@@ -74,7 +74,7 @@ Beamer specific options.  The following options are what I use:
 
 The first line enables the Beamer specific commands for org-mode (more
 on this below); the next two tell the LaTeX exporter to use the
-Beamer class and to use the larger font settings[2].  
+Beamer class and to use the larger font settings[fn:2].
 
 ** Outline levels for frames (slides)
 
@@ -178,7 +178,7 @@ org-mode has a special beamer sub-mode which provides an easy to use
 method for specifying block types (and columns as well, as we shall
 [[*Column view for slide and block customisation][see in the next section]]).
 
-To specify the type of block, you can type =C-c C-b= [3].  This brings up
+To specify the type of block, you can type =C-c C-b= [fn:3].  This brings up
 a keyboard driven menu in which you type a single letter to select the
 option you wish to apply to this headline.  For the above example, I
 typed =C-c C-b t=.  The options selected in this manner are also shown
@@ -348,10 +348,10 @@ changed easily.  Please read [[https://orgmode.org/manual/Beamer-Export.html#Bea
 
 * Footnotes
 
-[1] [[https://orgmode.org/worg/sources/org-tutorials/org-beamer/presentation.org][A previously created example presentation]] is available.
+[fn:1] [[https://orgmode.org/worg/sources/org-tutorials/org-beamer/presentation.org][A previously created example presentation]] is available.
 
-[2] I am a firm believer in using the largest font possible to
+[fn:2] I am a firm believer in using the largest font possible to
 encourage less text on slides. This is obviously a personal view.
 
-[3] org-beamer-mode must be turned on for this keybinding to be available.
+[fn:3] org-beamer-mode must be turned on for this keybinding to be available.
 
-- 
2.43.0

Re: [BUG] conda doesn't work in ob-shell sessions

[Ihor Radchenko]

Matt  writes:

>  > What about the attached second version of the patch?
>
> I spent way too long trying to test it but I'm not sure I applied the patch 
> correctly.
>
> I did the following, then realized that the patch I applied undid
> changes (I assume) from a previous patch and so it must have been
> applied on top of another one. I then wasted a bunch of time trying to
> apply various combinations of the four patches I found in the thread.
> One of the patches has trailing whitespace yet the various --ignore
> options of git am didn't seem to ignore it. I guess I could have
> looked at the timestamps and used git apply in sequence?

The patch should apply cleanly on the latest main.
No previous patches are needed.

To simplify working with email patches, you may consider
https://docs.kyleam.com/piem/Overview.html (Emacs package)
It can apply patches right from inside Emacs email client.

You can also use magit.

> Should make autoloads also be run after applying the patches?

Yes. Or make. Or you can use make repro to run clean Emacs using the
current git branch.

> Here's what I was able to do:
>
> In a VM, installed conda as described by their page.  Specifically, my 
> .bashrc was modified to activate the base environment.   Closed terminal, 
> opened it into the base environment, and created a new environment, 
> emacs-test.
>
> Downloaded the latest org-mode by git-clone and did make autoloads.  Added 
> the org-mode git repo's lisp directory to my early-init.el.
>
> Applied patch with
>
>   git apply --cache --ignore-space-changes --ignore-whitespace 
> 2-v2-0001-lisp-ob-comint.el-Introduce-a-fallback-prompt-reg.patch
>
> Doing plain git apply failed.
>
> With the changes in the org-mode index, the base environment activated, I run 
> 'emacs' and confirm I'm using the org-mode git with the patch applied 
> (ob-shell doesn't set org-babel-comint-prompt in ).
>
> Then
>
> (org-babel-do-load-languages 'org-babel-load-languages '((shell . t)))
>
> #+begin_src shell :results output :session *shell*
> conda activate emacs-test
> #+end_src
>
> It hangs.  C-g and switch to shell buffer shows the following (note, this was 
> typed in and not copy-pasted because VM):

Note that the patch should only make Emacs unhang after 5 seconds delay.

I tested the patch with the following (conda does not available for my system):

#+begin_src bash :results output :session *shell*
PS1="prompt> "
ls
#+end_src

-- 
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

[Pedro A. Aranda]

Hi

I've been reading a bit. What I propose is an alternative way to handle 
all the tricky parts of font and character handling with fontspec in 
lualatex and xetex. This package restricts the use of the ams* packages 
to pdflatex, because fontenc handles that internally and produces 
package collisions.


Attached is the final version of the patch.

Best, /PA

On 25/1/24 14:41, Ihor Radchenko wrote:

"Pedro A. Aranda"  writes:


As stated, this was only a PoC. If you find it useful, I would give it a
go in the free window.

I understand.
My question is to clarify how useful it is.
Because I am not deeply familiar with how fontenc works for non-English
languages, it is hard to judge how useful it will be in practice.


... I'm also playing with
org-latex-default-packages-alist, refining it to use fontspec in
lualatex and xetex and restricting inputenc and fontenc to pdflatex only.

Aren't inputenc and fontenc already restricted to pdflatex only?
From 481a35750fcb4098fe469efc80623c5c289b6f9f Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Thu, 25 Jan 2024 17:47:15 +0100
Subject: [PATCH] Refine font management for lualatex and xetex

---
 lisp/org.el | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

 lisp/org.el: switch to fontspec for character and font management
   in lualatex and xetex. This implies explicitly importing the
   ams* packages is only needed with pdflatex.

diff --git a/lisp/org.el b/lisp/org.el
index cf9abafac..f50531e7e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -3402,15 +3402,16 @@ header, or they will be appended."
 	  (default-value var)))

 (defcustom org-latex-default-packages-alist
-  '(("AUTO" "inputenc"  t ("pdflatex"))
+  '(("" "fontspec"  t ("lualatex" "xetex"))
+("AUTO" "inputenc"  t ("pdflatex"))
 ("T1"   "fontenc"   t ("pdflatex"))
 ("" "graphicx"  t)
 ("" "longtable" nil)
 ("" "wrapfig"   nil)
 ("" "rotating"  nil)
 ("normalem" "ulem"  t)
-("" "amsmath"   t)
-("" "amssymb"   t)
+("" "amsmath"   t ("pdflatex"))
+("" "amssymb"   t ("pdflatex"))
 ("" "capt-of"   nil)
 ("" "hyperref"  nil))
   "Alist of default packages to be inserted in the header.
@@ -3421,6 +3422,7 @@ incompatibility with another package you are using.
 The packages in this list are needed by one part or another of
 Org mode to function properly:

+- fontspec: for font ans character selection in lualatex and xetex
 - inputenc, fontenc:  for basic font and character selection
 - graphicx: for including images
 - longtable: For multipage tables
--
2.34.1

Re: [BUG] beamer export

[Leo Butler]

On Wed, Jan 24 2024, Ihor Radchenko  wrote:

> Leo Butler  writes:
>
 1. ox-latex export bug for src blocks containing direct LaTeX when
org-latex-src-block-backend is set to its default 'verbatim value
>>>
>>> This appears to be Beamer-specific problem with verbatim environments:
>>> https://tex.stackexchange.com/questions/140719/verbatim-in-beamer-showing-error-file-ended-while-scanning-use-of-xverbatim
>>>
>>> The solution might be to use [fragile] frame parameter, but that might
>>> have its own drawbacks:
>>> https://tex.stackexchange.com/questions/136240/drawbacks-of-using-fragile-frames-in-beamer
>>
>> Yes, an *automatic* solution may create more problems than it solves.
>> Although, I do note that ox-beamer does mark some frames as fragile already.
>> I wonder how difficult it would be to add a property drawer to frames,
>> so (amongst other things), they could be marked fragile?
>
> Hmm. Actually, that frame is already marked fragile.
> Yet, it is not enough...



> Apparently, LaTeX has really hard time processing verbatim code inside
> beamer frames.

I looked again at the solution here:

https://tex.stackexchange.com/questions/140719/verbatim-in-beamer-showing-error-file-ended-while-scanning-use-of-xverbatim

and it errors out with a recent version of pdflatex:

   This is pdfTeX, Version 3.141592653-2.6-1.40.25 (TeX Live 2023/Debian) 
(preloaded format=pdflatex)

This is, apparently, a known problem:

https://github.com/josephwright/beamer/issues/360

The end of that issue report includes a work-around that we might apply
in org. I have attached a patch for your feedback. The example that
stimulated this discussion compiles with the patch and the testsuite
shows no errors related to it.

>
 2. ox-beamer export bug as described in the attached org file
>>>
>>> This is not a bug. When you specify ignoreheading environment, you imply
>>> that the contents of the heading is to be included as is.
>>> If you want the contents to become a column, you should specify column
>>> environment.
>>
>> I see. That is not now the ignoreheading property is described. It says
>> [1]:
>>
>> ... As the text in the slide says, the left column is a list and the
>> right one is an image. The left column's headline text is ignored,
>> specified by =C-c C-b i= which tells org to *ignore* the headline
>> text completely.
>>
>> I think the documentation and example needs to be corrected. I have
>> attached a patch.
>
> Thanks! Applied.
> https://git.sr.ht/~bzg/worg/commit/aedea59f

Thanks. I can see the commit on master in git, but the webpage seems to
be unchanged.

https://orgmode.org/worg/exporters/beamer/tutorial.html

Leo

From 9cb3489e3fe80fb2e3996b737f528aa4db9ba62d Mon Sep 17 00:00:00 2001
From: Leo Butler 
Date: Thu, 25 Jan 2024 09:48:20 -0600
Subject: [PATCH] lisp/ox-beamer.el:  randomize the beamer frame environment

* lisp/ox-beamer.el (org-beamer--frame-environment): new variable that
contains the name of an environment that serves as an alias for the
beamer frame environment.  The environment's definition is appended to
the set-up for beamer export.

(org-beamer--format-frame):  Replace the occurrence of \begin{frame}
and \end{frame} with the new environment's name.

Rationale: Code with \begin{frame} or \end{frame} cannot be embedded
in a verbatim environment inside a beamer frame due to a design
decision made by the beamer developers [1].  As suggested in that
report, defining an alias for the beamer frame environment will allow
such verbatim examples to compile correctly [2].

Refs:
[1] https://github.com/josephwright/beamer/issues/360
[2] https://github.com/josephwright/beamer/issues/360#issuecomment-708705250
[3] https://list.orgmode.org/orgmode/87le8eg1hs.fsf@localhost/T/
---
 lisp/ox-beamer.el | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/lisp/ox-beamer.el b/lisp/ox-beamer.el
index 82c8841aa..be3003835 100644
--- a/lisp/ox-beamer.el
+++ b/lisp/ox-beamer.el
@@ -36,11 +36,23 @@
 (require 'cl-lib)
 (require 'ox-latex)
 
+;; Needed to set-up Beamer export.
+(defconst org-beamer--frame-environment
+  (concat "orgframe" (org-id-uuid))
+  "Name of the beamer frame environment.
+This is randomized to prevent collisions.")
+
 ;; Install a default set-up for Beamer export.
 (unless (assoc "beamer" org-latex-classes)
   (add-to-list 'org-latex-classes
-	   '("beamer"
-		 "\\documentclass[presentation]{beamer}"
+	   `("beamer"
+		 ,(concat "\\documentclass[presentation]{beamer}\n"
+  ;; Define an alias for the beamer frame environment
+ "\\newenvironment<>{"
+ org-beamer--frame-environment
+ "}[1][]{\\begin{frame}[environment="
+ org-beamer--frame-environment
+ ",#1]}{\\end{frame}}")
 		 ("\\section{%s}" . "\\section*{%s}")
 		 ("\\subsection{%s}" . "\\subsection*{%s}")
 		 

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

[Sparapani, Rodney]

Hi Idor:

I have never had much success with either MELPA or ELPA.  Something about
my TLS setup that I have not figured how to fix.  But, I did receive an email 
that
we are available at ELPA too (however, I can’t test the veracity of that 
myself).
See the ESS-help thread here….
https://www.mail-archive.com/ess-help@r-project.org/msg01043.html

--
Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
Vice President, Wisconsin Chapter of the American Statistical Association
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus

If this is outside of working hours, then please respond when convenient.

From: Ihor Radchenko 
Date: Thursday, January 25, 2024 at 7:05 AM
To: Martin Maechler 
Cc: Sparapani, Rodney , ess-c...@r-project.org 
, Jack Kamm , emacs-orgmode@gnu.org 
, Liu Hui 
Subject: Re: [PATCH] Add buffer-local setting to request specific ESS 
process/session name (was: [PATCH] Set Python shell in Org edit buffer)
ATTENTION: This email originated from a sender outside of MCW. Use caution when 
clicking on links or opening attachments.


Martin Maechler  writes:

> > Thank you!  May I know which version of ESS will have this
> > commit?
>
> The Melpa version that was just released, does.

Noted. I did not know that ESS is distributed via MELPA.
I am wondering why not ELPA/non-GNU ELPA - ELPA is built-in and users
can simply M-x package-install packages from ELPA repositories.

> As you probably know more than me about emacs package
> maintenance and release cycles:
> Do you think we should also try to get a  Melpa-stable release?

That's up to you to decide if ESS is in stable state or not.
You may find 
https://urldefense.com/v3/__https://orgmode.org/worg/org-maintenance.html*release-types__;Iw!!H8mHWRdzp34!9qd7lXuuGaLyWEAPOcHUmf_Fr_oYuyym5rkIQSSfGycheI8pfc2DqZqFLvG8jwINxn5hSssSSxjLZi_mEg$
useful to see how Org mode handles releases.

> Is the wording we have about MELPA in
>
> https://urldefense.com/v3/__https://ess.r-project.org/Manual/readme.html*Installing-from-a-third_002dparty-repository__;Iw!!H8mHWRdzp34!9qd7lXuuGaLyWEAPOcHUmf_Fr_oYuyym5rkIQSSfGycheI8pfc2DqZqFLvG8jwINxn5hSssSSxhsgRpn0A$
> satisfactory?

Looks fine.

--
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)

[Sparapani, Rodney]

Hi Idor:

This last remark below can’t possibly be true.  Because I did not intend to 
trigger
a release, ESS 24.01.0 was not initially tagged.  However, after I received 
that email
from ELPA, it was a fait accompli.  So I fixed some cosmetic issues and tagged 
it post-haste,
i.e., ELPA’s announcement is definitely pre-tagging.  So I’m not sure where the 
disconnect is.
But, again, I don’t find the package mechanism at all convenient and will have 
to spend some
time debugging since it has never worked for me.  I will put these ELPA/MELPA 
issues on my
growing TODO list.  Thanks for pointing this out!

--
Rodney Sparapani, Associate Professor of Biostatistics, He/Him/His
Vice President, Wisconsin Chapter of the American Statistical Association
Institute for Health and Equity, Division of Biostatistics
Medical College of Wisconsin, Milwaukee Campus

If this is outside of working hours, then please respond when convenient.

From: Ihor Radchenko 
Date: Thursday, January 25, 2024 at 9:30 AM
To: Sparapani, Rodney 
Cc: Martin Maechler , ess-c...@r-project.org 
, Jack Kamm , emacs-orgmode@gnu.org 
, Liu Hui 
Subject: Re: [PATCH] Add buffer-local setting to request specific ESS 
process/session name (was: [PATCH] Set Python shell in Org edit buffer)
Also, unlike MELPA, ELPA uses stable (tagged) releases by default.
Unstable releases (latest commit) are only available on demand, via
ELPA-devel 
(https://urldefense.com/v3/__https://elpa.gnu.org/devel/ess.html__;!!H8mHWRdzp34!98PglwLJJtQrc63k3vrtr0K0MjYZSPEf3WV0GPD_wsxbsO3bM8AYCDRI0W69ZcBg5STqpaG7_h3rF8wlAQ$
 )

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 have never had much success with either MELPA or ELPA.  Something about
> my TLS setup that I have not figured how to fix.  But, I did receive an email 
> that
> we are available at ELPA too (however, I can’t test the veracity of that 
> myself).
> See the ESS-help thread here….
> https://www.mail-archive.com/ess-help@r-project.org/msg01043.html

I see. ESS is indeed listed on ELPA https://elpa.gnu.org/packages/ess.html

Note that ELPA is the official package repository for GNU Emacs. So, it
is worth documenting that ESS is distributed via ELPA in
https://ess.r-project.org/Manual/readme.html#Installing-from-a-third_002dparty-repository

Also, unlike MELPA, ELPA uses stable (tagged) releases by default.
Unstable releases (latest commit) are only available on demand, via
ELPA-devel (https://elpa.gnu.org/devel/ess.html)

-- 
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]

"Pedro A. Aranda"  writes:

> As stated, this was only a PoC. If you find it useful, I would give it a 
> go in the free window.

I understand.
My question is to clarify how useful it is.
Because I am not deeply familiar with how fontenc works for non-English
languages, it is hard to judge how useful it will be in practice.

> ... I'm also playing with 
> org-latex-default-packages-alist, refining it to use fontspec in 
> lualatex and xetex and restricting inputenc and fontenc to pdflatex only.

Aren't inputenc and fontenc already restricted to pdflatex only?

-- 
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]

Jack Kamm  writes:

>>> 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.

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

>> 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 :)

Thanks!
You can replace Maintainer: line in ox-icalendar.el with your name.
(Nicolas informed me that he no longer maintains Org mode libraries)

> 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.

Sure.
I checked my records and found one outstanding issue related to
ox-icalendar -
https://list.orgmode.org/orgmode/20211230225919.1a660...@hsu-hh.de/

The patch proposed by Detlef still has outstanding issues to address,
but the author does not have free time to work on this since the
beginning of last year (I did several follow-ups off list; latest in
September).

At this point, we should either cancel that patch or amend it ourselves
and apply.

-- 
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]

Martin Maechler  writes:

> > Thank you!  May I know which version of ESS will have this
> > commit?
>
> The Melpa version that was just released, does.

Noted. I did not know that ESS is distributed via MELPA.
I am wondering why not ELPA/non-GNU ELPA - ELPA is built-in and users
can simply M-x package-install packages from ELPA repositories.

> As you probably know more than me about emacs package
> maintenance and release cycles: 
> Do you think we should also try to get a  Melpa-stable release?

That's up to you to decide if ESS is in stable state or not.
You may find https://orgmode.org/worg/org-maintenance.html#release-types
useful to see how Org mode handles releases.

> Is the wording we have about MELPA in
>
> https://ess.r-project.org/Manual/readme.html#Installing-from-a-third_002dparty-repository
> satisfactory?

Looks fine.

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

[PATCH] doc/org-manual.org (Checkboxes): move section 'Checkboxes' from 'TODO Items' to 'Plain Lists'

[Sławomir Grochowski]

Dear All,

Dear All,

I propose to move the section "Checkboxes".
>From "5 TODO Items -> 5.6 Checkboxes"
To: "2 Document Structure -> 2.6 Plain Lists -> 2.6.1 Checkboxes"

Because checkbox can only exist in a plain list, as a plain list feature.
So the section should be under 'Plain Lists' heading not under 'TODO Items'.

Link https://orgmode.org/org.html#Checkboxes would stay the same.
So it's just a move section to a more suitable place.
Without changing the content.

What do you think?
Patch in the attachment.

Regards,
Sławomir Grochowski
From ff2c4be8188a5faed6dfb91b2315e58573f91fa8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C5=82awomir=20Grochowski?= 
Date: Thu, 25 Jan 2024 10:03:09 +0100
Subject: [PATCH] doc/org-manual.org (Checkboxes): move section to 'Plain
 Lists'

* doc/org-manual.org (Checkboxes): move section 'Checkboxes' from
'TODO Items' to 'Plain Lists'.  Because checkbox can only exist in a
plain list, as a plain list feature.  So section should be under
'Plain Lists' heading not under 'TODO Items'.
---
 doc/org-manual.org | 330 ++---
 1 file changed, 165 insertions(+), 165 deletions(-)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index d8c7fd737..71e72ddd8 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -1308,6 +1308,171 @@ to disable them individually.
   Sort the plain list.  Prompt for the sorting method: numerically,
   alphabetically, by time, or by custom function.
 
+*** Checkboxes
+:PROPERTIES:
+:DESCRIPTION: Tick-off lists.
+:END:
+#+cindex: checkboxes
+
+#+vindex: org-list-automatic-rules
+Every item in a plain list[fn:17] (see [[*Plain Lists]]) can be made into
+a checkbox by starting it with the string =[ ]=.  This feature is
+similar to TODO items (see [[*TODO Items]]), but is more lightweight.
+Checkboxes are not included into the global TODO list, so they are
+often great to split a task into a number of simple steps.  Or you can
+use them in a shopping list.
+
+Here is an example of a checkbox list.
+
+#+begin_example
+,* TODO Organize party [2/4]
+  - [-] call people [1/3]
+- [ ] Peter
+- [X] Sarah
+- [ ] Sam
+  - [X] order food
+  - [ ] think about what music to play
+  - [X] talk to the neighbors
+#+end_example
+
+A checkbox can be in one of the three states:
+1. not checked =[ ]=
+2. partially checked =[-]=
+3. checked =[X]=
+
+Checkboxes work hierarchically, so if a checkbox item has children
+that are checkboxes, toggling one of the children checkboxes makes the
+parent checkbox reflect if none, some, or all of the children are
+checked.
+
+If all child checkboxes are not checked, the parent checkbox is also not checked.
+#+begin_example
+- [ ] call people
+  - [ ] Peter
+  - [ ] Sarah
+#+end_example
+
+If some but not all child checkboxes are checked, the parent checkbox is partially checked.
+#+begin_example
+- [-] call people
+  - [X] Peter
+  - [ ] Sarah
+#+end_example
+
+If all child checkboxes are checked, the parent checkbox is also checked.
+#+begin_example
+- [X] call people
+  - [X] Peter
+  - [X] Sarah
+#+end_example
+
+#+cindex: statistics, for checkboxes
+#+cindex: checkbox statistics
+#+cindex: @samp{COOKIE_DATA}, property
+#+vindex: org-checkbox-hierarchical-statistics
+The =[2/4]= and =[1/3]= in the first and second line are cookies
+indicating how many checkboxes present in this entry have been checked
+off, and the total number of checkboxes present.  This can give you an
+idea on how many checkboxes remain, even without opening a folded
+entry.  The cookies can be placed into a headline or into (the first
+line of) a plain list item.  Each cookie covers checkboxes of direct
+children structurally below the headline/item on which the cookie
+appears[fn:: Set the variable ~org-checkbox-hierarchical-statistics~
+if you want such cookies to count all checkboxes below the cookie, not
+just those belonging to direct children.].  You have to insert the
+cookie yourself by typing either =[/]= or =[%]=.  With =[/]= you get
+an =n out of m= result, as in the examples above.  With =[%]= you get
+information about the percentage of checkboxes checked (in the above
+example, this would be =[50%]= and =[33%]=, respectively).  In a
+headline, a cookie can count either checkboxes below the heading or
+TODO states of children, and it displays whatever was changed last.
+Set the property =COOKIE_DATA= to either =checkbox= or =todo= to
+resolve this issue.
+
+#+cindex: blocking, of checkboxes
+#+cindex: checkbox blocking
+#+cindex: @samp{ORDERED}, property
+If the current outline node has an =ORDERED= property, checkboxes must
+be checked off in sequence, and an error is thrown if you try to check
+off a box while there are unchecked boxes above it.
+
+The following commands work with checkboxes:
+
+- {{{kbd(C-c C-c)}}} (~org-toggle-checkbox~) ::
+
+  #+kindex: C-c C-c
+  #+findex: org-toggle-checkbox
+  Toggle checkbox status or---with prefix argument---checkbox presence
+  at point.  With a 

[BUG] ox-latex produces broken references to src code listings without caption (was: [BUG] org-lint tells to move #+name to wrong place in results block)

[Ihor Radchenko]

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

> I have found that CAPTION keywords  in the "name-result-example" in the
> manual are essential to produce correct links.

It should not be essential. What you demonstrated is two bugs in Org mode.

> In case the relevant blocks have e.g. ":exports both", Org handles
> this, but:
> 1. HTML export requires captions to produce links with unequivocal
> "link texts" which are numbers in the HTML output.

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

> 2. LaTeX export requires captions to produce captions with labels like
> =\caption{\label{path}desc}=.

`org-latex-link' assumes that it is safe to use
\ref{} in order to refer to an existing src block.
However, it is not true.

`org-latex-src-block--engraved', `org-latex-src-block--minted',
and `org-latex-src-block--listings' only produce a label when src block
has a caption.

We should generally not need to put a caption in order to refer to a
source block listing. At least, it does not look like we need it from
https://tex.stackexchange.com/questions/438260/referencing-without-captions-appearing-but-keeping-numbering

Thoughts? Ideas?

> Tested on example below:
> Produced by listing [[IN]].
>
> #+name: OUT
> #+RESULTS: IN
> #+begin_src emacs-lisp :exports code
> 6
> #+end_src
>
> #+header: :wrap "src emacs-lisp :exports code"
> #+name: IN
> #+begin_src emacs-lisp :exports both
> 6
> #+end_src
>
> Listing [[IN]] produces listing [[OUT]].
>
>  From inspecting HTML or LaTeX output using this example
> for the difference between with and without captions it is
> easy to see that only with captions the output is correct.

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