RFI: LaTeX - AUTO for \usepackage{inputenc}

[Pedro Andres Aranda Gutierrez]

HI,

some days ago I sent a proof-of-concept for customising the coding for the
inputenc package. Before continuing with this, I'd like to know what other
people think and/or need.

The simplest approach was in the PoC: a custom variable you can set in your
document/workspace/emacs configuration. AN alternative approach would be to
derive it from language.

What would be the best way to go forward?

Thx, /PA

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

Re: Async Python src block behavior with :dir header property

[Jack Kamm]

Ihor Radchenko  writes:

> [ CCing ob-python maintainer ]
>
> Nasser Alkmim  writes:
>
>> Here is a clearer description of the unwanted behavior:
>>
>> 1. emacs -Q ~/Desktop/testasync.org
>>
>> Then evaluate (require 'ob-python) and paste this source block:
>>
>> #+begin_src python :dir otherdir :async yes :session pysession :return 
>> figname :results file value :mkdirp yes
>> import matplotlib.pyplot as plt
>> plt.figure(figsize=(1, 1))
>> plt.plot([1, 2])
>> figname = 'fig.svg'
>> plt.savefig(figname)
>> #+end_src
>>
>> Execute the source block, which results in 
>>
>> #+RESULTS:
>> [[file:fig.svg]]
>
> I don't even see this.
> Confirmed.

Does the attached patch fix the issue?

It seems the problem is with async sessions generally (not just
ob-python), and happens because `org-babel-comint-async-filter' does not
set `default-directory' before calling `org-babel-insert-result', unlike
`org-babel-execute-src-block'.

>From 1430a27e4416d5e88094a64360015a6a2ae7315c Mon Sep 17 00:00:00 2001
From: Jack Kamm 
Date: Wed, 31 Jan 2024 20:06:00 -0800
Subject: [PATCH] ob-comint: Make file results from async sessions respect :dir
 header

* lisp/ob-comint.el (org-babel-comint-async-filter): Set
default-directory before calling `org-babel-insert-result'

https://list.orgmode.org/875xz9o4nj.fsf@localhost/T/#t
---
 lisp/ob-comint.el | 17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index 7d258ea0e..ecce18a95 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -248,7 +248,14 @@ (defun org-babel-comint-async-filter (string)
 (let* ((info (org-babel-get-src-block-info))
(params (nth 2 info))
(result-params
-(cdr (assq :result-params params
+(cdr (assq :result-params params)))
+   (tmp-file (expand-file-name tmp-file))
+   (dir (cdr (assq :dir params)))
+   (default-directory
+(if dir
+(file-name-as-directory
+ (expand-file-name dir))
+  default-directory)))
   (org-babel-insert-result
(funcall file-callback
 (nth
@@ -291,7 +298,13 @@ (defun org-babel-comint-async-filter (string)
(let* ((info (org-babel-get-src-block-info))
   (params (nth 2 info))
   (result-params
-   (cdr (assq :result-params params
+   (cdr (assq :result-params params)))
+  (dir (cdr (assq :dir params)))
+  (default-directory
+   (if dir
+   (file-name-as-directory
+(expand-file-name dir))
+ default-directory)))
  (org-babel-insert-result
   res-str result-params info))
    t
-- 
2.43.0

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[joseph]

January 17, 2024 at 5:15 AM, "Ihor Radchenko"  wrote:



> 
> Joseph Turner  writes:
> 
> > 
> > > 
> > > May you please provide an example with an Org file containing file links
> > > 
> > >  and how you envision to transform them? Will they be transformed
> > > 
> > >  depending on the directory the Org file is located in?
> > > 
> > 
> >  I don't want to transform the file links. The idea is that an Org file
> > 
> >  "foo.org" could be copied into a hyperdrive, and [[./bar.org]] would
> > 
> >  point to a file called "bar.org" in the same folder in the hyperdrive.
> > 
> >  That way, you could copy both "foo.org" and "bar.org" from your local
> > 
> >  directory into a hyperdrive, the links between them would work as-is.
> > 
> >  Pseudo-code for a hyperdrive.el :follow function for file: links:
> > 
> >  (defun hyperdrive--org-file-link-follow (url  _prefix _link)
> > 
> >  (when hyperdrive-mode
> > 
> >  (hyperdrive-open
> > 
> >  (hyperdrive-convert-path-to-hyper-url url option)) ;; Turns "/foo" into 
> > "hyper://PUBLIC-KEY/foo"
> > 
> >  t))
> > 
> >  (org-link-set-parameters "file" :follow #'hyperdrive--org-file-link-follow)
> > 
> 
> You do not really need Org mode to do this. Instead, it may be
> 
> sufficient to define a file handler in order to make things work
> 
> "magically". Check out 26.12 Making Certain File Names "Magic" section
> 
> of Elisp manual.

Thank you!  I've added a note to look into that: 
https://todo.sr.ht/~ushin/ushin/168#event-288786

> > 
> > > 
> > > What we can do then is pass an extra argument to :follow function - the
> > > 
> > >  link object. That way, :follow function can get all the information it
> > > 
> > >  needs.
> > > 
> > 
> >  I like this idea! Would this change break existing :follow functions
> > 
> >  which only expect max two args?
> > 
> 
> No. We can preserve backwards-compatibility by checking :follow function
> 
> arity and only passing the extra argument with the :follow function
> 
> supports that many arguments.

Good to know.  If the goals of hyperdrive.el can be accomplished without adding 
complexity to Org mode, it may be best to avoid avoid adding another argument 
to :follow functions.  WDYT?

> -- 
> 
> Ihor Radchenko // yantar92,
> 
> Org mode contributor,
> 
> Learn more about Org mode at  https://orgmode.org/%3E .
> 
> Support Org development at , 
> https://liberapay.com/org-mode%3E, 
> 
> or support my work at  
> https://liberapay.com/yantar92%3E
>

Re: [PATCH] Silently remove lockfiles from org-agenda-files

[Joseph Turner]

Hi Ihor,

Ihor Radchenko  writes:

> Joseph Turner  writes:
>
>> My Emacs setup broke today due to the presence of a lockfile inside
>> "~/.local/share/org/todo".  I use EXWM, and I show org-agenda on startup:
>>
>> (add-hook 'after-init-hook
>> (lambda () (org-agenda nil "t")))
>> (setq initial-buffer-choice (lambda () (get-buffer "*Org Agenda*")))
>>
>> org-agenda-files contained a non-existent file, so org-check-agenda-file
>> attempted to prompt me.  For some reason (maybe EXWM didn't fully load),
>> Emacs simply hung without prompting, leaving me with a black screen.
>
> You may consider reporting the hang to Emacs or EXWM bug tracker.

>> My configuration contains the equivalent of
>>
>> (setopt org-agenda-files
>>(directory-files-recursively "~/.local/share/org/todo" ".org$"))
>
> I'd recommend using a different approach - use org-agenda-file-regexp
> instead of ".org$"; or use #'file-directory-p as predicate - Org mode
> then select Org files inside all the listed directories by itself.

Good to know about org-agenda-file-regexp.

>> The attached patch silently removes lockfiles from org-agenda-files.
>
>> -  "Make sure FILE exists.  If not, ask user what to do."
>> +  "Make sure FILE exists.  If not, ask user what to do.
>> +Automatically exclude lockfiles."
>>(unless (file-exists-p file)
>> +(when (string-match-p (rx bos ".#") file) ; Exclude lockfiles
>> +  (org-remove-file file)
>> +  (throw 'nextfile t))
>
> I feel slightly reluctant about this patch:
>
> 1. You are only working around the actual problem with agenda file being
>deleted from disk while Emacs is loading. So, the patch is not
>solving a real Org mode problem - Org mode prompting about
>non-existing file is not wrong; your bug has nothing to do with Org
>mode itself.
>
> 2. In theory, there might be users with actual Org files starting from
>".#" for whatever reason. The probability is not high, but if users
>choose to set org-agenda-files directly, file-by-file, that's a
>choice we should better respect in order to not create a blocker.

Yes, I think you're right.  Thanks for your caution :)

Joseph

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

[Stefan Kangas]

Max Nikulin  writes:

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

It's been many moons since I last looked at email attachements in any
detail, so I have some questions.

With this patch, what happens if someone is emailing using an old
version of Emacs?  Does that matter, or is this stuff based only on the
file ending?  IOW, I'm asking if it is backwards-compatible to remove
"text/org", in either direction.  Will .org files be displayed in the
same way as before or not on both new and old versions?

I've noticed on my machine that .org files have been interpreted as
application/vnd.lotus-organizer.  Presumably that's due to some local
configuration in /etc/mime.types on my distro.  Is that correct?  Is it
documented somewhere how to override that system configuration in Emacs?

But thinking about this more, why not do that unconditionally for users?
Lotus Organizer is dead, long gone, and not really relevant to anyone,
certainly not to the overwhelming majority of Emacs users.  On the off
chance that someone is opening such files from Emacs, they could just
revert that locally.  WDYT?

>"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 v2] org-id: allow using parent's existing id in links to headlines

[Rick Lupton]

On Mon, 29 Jan 2024, at 1:00 PM, Ihor Radchenko wrote:
>>> 3. Consider
>>>(setq org-id-link-consider-parent-id t)
>>>(setq org-id-link-to-org-use-id t)
>>>
>>>Then, create a new empty Org file
>>>M-x org-store-link with create a top-level properties drawer with ID
>>>and store the link. However, that link will not be a simple ID link,
>>>but also have ::PROPERTIES search string, which is not expected.
>>
>> This is because it is trying to link to the current line of the file, which 
>> contains the text "PROPERTIES".  On main, with (setq 
>> org-id-link-to-org-use-id nil), you see the equivalent behaviour (a link to 
>> [[file:test.org:::PROPERTIES:]]) when point is before the first heading.  
>> So, this seems consistent with non-org-id links?
>
> No. Do note that my instructions start from _empty_ file. With
> org-id-link-to-org-use-id, PROPERTIES drawer is not created. This is
> different from what happens with your patch - it is unexpected in your
> patch that the search string is added for text that did not exist in the
> buffer previously.

I see.  Updated to get the search string first, before the possible properties 
draw appears.

To make this work I changed `org-link-precise-link-target': instead of 
accepting the RELATIVE-TO argument and rejecting unsuitable targets internally, 
it now sets a marker `org-link-precise-target-marker' showing where the target 
that was found is, so the caller can decide if the found target is suitable.  I 
copied the approach from `org-entry-property-inherited-from', hope that doesn't 
cause any other issues.

> That's a good catch.
> The fact that links stored via `org-store-link' cannot be open with
> default settings is not good.
> Also, your patch disregards this setting - it should not match
> non-headline search strings with the default value of
> `org-link-search-must-match-exact-headline'.

`org-link-search-must-match-exact-headline' affects `org-link-search', which is 
called by `org-id-open' -- so I think the behaviour for these org-id links 
should be the same as for other file links? Am I missing something?

Or, maybe you mean links that rely on 
`org-link-search-must-match-exact-headline' should not be stored.  That would 
seem reasonable, but also doesn't need to be part of these changes here?

> Probably, changing the default value of
> `org-link-search-must-match-exact-headline' to nil is due.

It seems like the behaviour below would be desirable, but doesn't currently 
exist with any setting of `org-link-search-must-match-exact-headline'?

(org-link-search "plain text")  -->  fuzzy search for all text
(org-link-search "*heading")-->  search only headings, optionally creating 
if missing

>> Subject: [PATCH 2/2] org-id.el: Extend links with search strings, inherit
>>  parent IDs
>
> I ran make test, and it looks like one test is failing with your patch:

Oops, fixed now I think.

> `org-context-in-file-links' is an obsolete name. Use
> `org-link-context-for-files'.
>
> Also, please add `org-id-link-use-context' to #+vindex.

Updated

> Please update the docstring of `org-store-link-functions' to specify
> that an argument is passed to :store functions.

Updated

>> -  (org-insert-heading nil t t)
>> +  ;; Find appropriate level for new heading
>> +  (let ((level (save-excursion
>> + (goto-char (point-min))
>> + (+ 1 (or (org-current-level) 0)
>
> This is fragile. You assume that `point-min' always contains a heading.
> That may or may not be the case - `org-link-search' may be called by
> third-party code that does not care about setting narrowing in certain
> ways.

I don't think it's a problem. (org-current-level) returns something suitable 
whether or not point-min contains a heading. Both the situations below seem 
reasonable choices for the level of the newly created heading at the end:

---start of narrowing---
Text
* H1
** H2
* A new level 1 heading is created at the end
---end of narrowing---

---start of narrowing---
* H1
** H2
** A new level 2 heading is created at the end
---end of narrowing---

(this is how it currently works, unless I'm missing something)

>> +(defun org-link-precise-link-target ( relative-to)
>> +  "Determine search string and description for storing a link.
>> +
>> +If a search string (see 'org-link-search') is found, return cons
>
> Quoting: `org-link-search'.

Fixed

>> +   (let* ((element (org-element-at-point))
>> +  (name (org-element-property :name element))
>> +  (heading (org-element-lineage element 'headline t))
>
> What about inlinetasks?

I added inlinetasks to the element types, so they are picked up the same as 
headlines now.

>> +  (custom-id (org-entry-get nil "CUSTOM_ID")))
>
> May as well pass HEADING as the first argument of `org-entry-get'. It
> will be slightly more efficient.

Ok

>> +(org-link--add-to-stored-links link desc)
>> +;; In org 

[PATCH] lisp/ox-latex.el: improve org-latex-toc-command docstring

[gerard . vermeulen]

Hi,

I have read the docstring of `org-latex-toc-command' too literally
to discover that specifying anything else than "toc:nil" works.

The attached patch contains a proposal for improvement.

Below there is a not so small mwe.

--- begin mwe ---
#+title: Table of Contents Test
#+latex_class: article
#+options: author:nil date:nil toc:1
#+latex_header: \usepackage{listings}
#+latex_header: \usepackage{minted}
* Test ~toc:~ and ~org-latex-toc-command~
Anything else than ~toc:nil~ in ~#+options:~ above exports the TOC.
#+caption: Execute this block before exporting to a LaTeX buffer or 
file.

#+begin_src emacs-lisp :results silent
  (when (require 'ox-latex nil 'noerror)
(setq-local org-latex-src-block-backend 'listings)
(setq-local org-latex-toc-command
 (cond
  ((eq org-latex-src-block-backend 'verbatim)
   "\\tableofcontents\n\\vspace{10pt}\n")
  ((eq org-latex-src-block-backend 'listings)
   "\\tableofcontents\n\\lstlistoflistings\n\\vspace{10pt}\n")
  ((memq org-latex-src-block-backend '(minted engraved))
   "\\tableofcontents\n\\listoflistings\n\\vspace{10pt}\n"
#+end_src
--- end mwe ---

Regards -- Gerard

0001-lisp-ox-latex.el-improve-org-latex-toc-command-docst.patch
Description: Binary data

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

[Max Nikulin]

On 26/01/2024 14:23, Eli Zaretskii wrote:

Max Nikulin writes:



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?


Changing of `mm-display-org-inline' may be postponed. I am curious 
however if there are a lot of users overriding their /etc/mime.types to 
avoid application/vnd.lotus-organizer.


However I am unsure whether `mm-uu-org-src-code-block-extract' is used 
to send messages. If it purpose to decode received messages then the 
change should be safe. I had a hope to receive some comments from 
developers familiar with Emacs mail clients.


I have realized that I missed `mm-automatic-display' there "text/org" 
should be added similar to `mm-inline-media-tests'.

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

[Ihor Radchenko]

Max Nikulin  writes:

> On 30/01/2024 19:13, Ihor Radchenko wrote:
>> Even when text/org is rendered using Org mode, there is nothing
>> pressuring people to use Org mode there. It is just visuals. Org major
>> mode is not activated.
>
> I am not familiar with gnus & Co code, so I am confused by (funcall 
> mode) in `mm-display-inline-fontify'. Doesn't it activate the major mode 
> through `mm-display-org-inline'?

It creates temporary buffer, activates Org mode there, and copies back
the fontified text for display inside message.
I do not know about any security issues when one merely opens Org file
without actually executing Org mode commands.

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

[Max Nikulin]

On 30/01/2024 19:13, Ihor Radchenko wrote:

Even when text/org is rendered using Org mode, there is nothing
pressuring people to use Org mode there. It is just visuals. Org major
mode is not activated.


I am not familiar with gnus & Co code, so I am confused by (funcall 
mode) in `mm-display-inline-fontify'. Doesn't it activate the major mode 
through `mm-display-org-inline'?


On the other hand, I am afraid, changing `mm-inline-media-tests' to use

("text/org" mm-inline-text identity)
("text/x-org" mm-inline-text identity)

by default instead of `mm-display-org-inline' for safety and to avoid 
loading of Org mode will cause a lot of complains from Org users.

Re: Async Python src block behavior with :dir header property

[Ihor Radchenko]

[ CCing ob-python maintainer ]

Nasser Alkmim  writes:

> Here is a clearer description of the unwanted behavior:
>
> 1. emacs -Q ~/Desktop/testasync.org
>
> Then evaluate (require 'ob-python) and paste this source block:
>
> #+begin_src python :dir otherdir :async yes :session pysession :return 
> figname :results file value :mkdirp yes
> import matplotlib.pyplot as plt
> plt.figure(figsize=(1, 1))
> plt.plot([1, 2])
> figname = 'fig.svg'
> plt.savefig(figname)
> #+end_src
>
> Execute the source block, which results in 
>
> #+RESULTS:
> [[file:fig.svg]]

I don't even see this.
Confirmed.

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

Re: Async Python src block behavior with :dir header property

[Nasser Alkmim]

Ihor Radchenko  writes:

> Do you mean that you have no problem after you add :mkdirp yes?

No. Just that I can reproduce the examples in the first message.

Here is a clearer description of the unwanted behavior:

1. emacs -Q ~/Desktop/testasync.org

Then evaluate (require 'ob-python) and paste this source block:

#+begin_src python :dir otherdir :async yes :session pysession :return figname 
:results file value :mkdirp yes
import matplotlib.pyplot as plt
plt.figure(figsize=(1, 1))
plt.plot([1, 2])
figname = 'fig.svg'
plt.savefig(figname)
#+end_src

Execute the source block, which results in 

#+RESULTS:
[[file:fig.svg]]

However, the figure is in ~/Desktop/otherdir/fig.svg and the link is
wrong.  If I run the same block without the ':async' and ':session', I
get the right relative path to the figure:

#+RESULTS:
[[file:otherdir/fig.svg]]

Best regards,

-- 
Nasser Alkmim 
 +43 677 6408 9171

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Max Nikulin  writes:

>>> I would suggest to strip leading and trailing newlines before processing
>>> of the block content.
>> 
>> May you elaborate?
>
> I expect that
>
> #+BEGIN_VERSE
>
>
>  From fairest creatures we desire increase,
> That thereby beauty’s rose might never die,
>
>
>
> #+END_VERSE
>
> is exported to
>
> \begin{verse}
>  From fairest creatures we desire increase,\\
> That thereby beauty’s rose might never die,
> \end{verse}
>
> and internally at some point it is represented as
> "From fairest creatures we desire increase,\nThat thereby beauty’s rose 
> might never die,"
> without leading and trailing newlines.

This has nothing to do with what happens when exporting verse blocks.

If you try a simple example like

#+options: toc:nil
* Heading
First.

Foo
#+BEGIN_VERSE

 From fairest creatures we desire increase,
That thereby beauty’s rose might never die,

#+END_VERSE
Bar

Foo
#+BEGIN_VERSE
 From fairest creatures we desire increase,
That thereby beauty’s rose might never die,
#+END_VERSE
Bar

you will see that lading and trailing spaces are insignificant:

\section{Heading}
\label{sec:orgc54e19b}
First.

Foo
\begin{verse}
\hspace*{1\fontdimen2\font}From fairest creatures we desire increase,\\
That thereby beauty’s rose might never die,\\
\end{verse}
Bar

Foo
\begin{verse}
\hspace*{1\fontdimen2\font}From fairest creatures we desire increase,\\
That thereby beauty’s rose might never die,\\
\end{verse}
Bar

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

Re: Org Table Header bug?

[Ihor Radchenko]

Ihor Radchenko  writes:

>> The \Oslash is not viewed as the Unicode character ⊘ with 
>> "org-table-header-line-mode". And the first line of the table appears in 
>> the heading.
>>
>> https://i.ibb.co/jht3HL0/Captura.png
>
> Confirmed.

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

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

Re: [BUG] org-beamer :BEAMER_ACT: ignored on columns

[Ihor Radchenko]

Ihor Radchenko  writes:

>> The org-beamer--normalize-argument function ensures that the action is
>> enclosed in [<...>] and [...] for options.
>
> Or <...>. In particular,
> (org-beamer--normalize-argument raw-actions 'action)
> , will return  (possibly stripping duplicate <>)
> Looking at 12.7 Splitting a Frame into Multiple Columns section of the
> beamer manual, it should be safe to use .

I unified the code duplication and adjusted the patch to avoid duplicate
beamer action spec when user also defines inner environment via
BEAMER_ENV.

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

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

I addressed everything in a series of commits on Org mode's bugfix.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ede8294cf
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=4aced687b
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=a5e84c2fb
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=75b6f2712
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ad90ff7cb
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=f1978ede2
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ee0196e6a
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=28e38a47a
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d4eaf8fe5

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

Re: Async Python src block behavior with :dir header property

[Ihor Radchenko]

Nasser Alkmim  writes:

>>> #+begin_src python :dir asyncpy :async :session :return figname :results 
>>> file value
>>
>> These header arguments are not correctly formatted.
>> Try M-x org-lint
>
> I tried org-lint and it says that the header argument is "unknown".

You should have got
 1 low   Empty value in header argument ":session"
 1 low   Empty value in header argument ":async"
 1 nil   Unknown header argument ":async"

You need to specify (1) :session name; (2) :async yes.

> However, I can execute the source blocks.

There is no guarantee that execution will work as expected in malformed
src blocks like yours.

> I tried with 'emacs -Q' and '(require 'ob-python)' and I noticed that I
> missed the header argument ':mkdirp "yes"'.
> With that I can reproduce the examples.

Do you mean that you have no problem after you add :mkdirp yes?

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

Re: Async Python src block behavior with :dir header property

[Nasser Alkmim]

Ihor Radchenko  writes:

> Nasser Alkmim  writes:
>
>> This does not work.
>> Even though the python execution is in the right directory and the file is 
>> saved
>> correctly.
>> The =return= does not produces the right file path considering the directory.
>>
>> #+begin_src python :dir asyncpy :async :session :return figname :results 
>> file value
>
> These header arguments are not correctly formatted.
> Try M-x org-lint

I tried org-lint and it says that the header argument is "unknown".
However, I can execute the source blocks.
I tried with 'emacs -Q' and '(require 'ob-python)' and I noticed that I
missed the header argument ':mkdirp "yes"'.
With that I can reproduce the examples.

In any case, thanks for taking a look.

-- 
Nasser Alkmim 

Re: [PATCH] testing: Delete duplicate tests

[Ihor Radchenko]

Ilya Chernyshov  writes:

> Ihor Radchenko  writes:
>
>> What about the attached amendment?
>> It should simplify things significantly.
>
> Sorry, in my previous patch the test that checks the detector itself was not
> even run in 'make test' because of incorrect test prefix.
>
> Your patch does not work as you expect. Could you please revise it?

Sure. I erroneously checked car of sub-form when testing whether to
ignore testing duplicates in children.

See the attached series of patches to be applied on top the previous 3.

Note that your
`test-org-tests/test-duplicates-detector-testing-find-duplicates' does
not look right. I had to adjust the `equal' condition in order to make
it pass. May you please check if the return value of
`test-duplicates-detector--find-duplicates' is what you intended?

>From 316c36d2b388a81e43fabf392a75af85532f56ba Mon Sep 17 00:00:00 2001
Message-ID: <316c36d2b388a81e43fabf392a75af85532f56ba.1706703212.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 31 Jan 2024 13:11:31 +0100
Subject: [PATCH 1/3] testing/lisp/test-duplicates-detector.el: Fix recursion,
 add more ignored forms

*
testing/lisp/test-duplicates-detector.el (test-duplicates-detector--search-forms-recursively):
Do not test for duplicates according to parent form, not current form.

*
testing/lisp/test-duplicates-detector.el (test-duplicates-progn-forms):
Add more progn-like forms.
---
 testing/lisp/test-duplicates-detector.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/testing/lisp/test-duplicates-detector.el b/testing/lisp/test-duplicates-detector.el
index aed8034ee..b23fbce1e 100644
--- a/testing/lisp/test-duplicates-detector.el
+++ b/testing/lisp/test-duplicates-detector.el
@@ -42,9 +42,10 @@ (require 'org-test "../testing/org-test")
  Variables
 
 (defvar test-duplicates-progn-forms
-  '( progn
+  '( progn prog1 let dolist dotimes
  org-test-with-temp-text
  org-test-with-temp-text-in-file
+ org-test-at-id
  org-test-ignore-duplicate)
   "List of forms equivalent to `progn'.
 Immediate children inside these are not checked for duplicates.")
@@ -232,7 +233,7 @@ (defun test-duplicates-detector--search-forms-recursively (form form-path)
   (let ((idx 0))
 (dolist (sub-form form)
   (when (consp sub-form)
-(unless (memq (car-safe sub-form) test-duplicates-progn-forms)
+(unless (memq (car-safe form) test-duplicates-progn-forms)
   (push idx (alist-get
 		 sub-form
  (alist-get form-path test-duplicates-detector-forms
-- 
2.43.0

>From 77ec5f6e3834253a3ba872140f32b148b1135887 Mon Sep 17 00:00:00 2001
Message-ID: <77ec5f6e3834253a3ba872140f32b148b1135887.1706703212.git.yanta...@posteo.net>
In-Reply-To: <316c36d2b388a81e43fabf392a75af85532f56ba.1706703212.git.yanta...@posteo.net>
References: <316c36d2b388a81e43fabf392a75af85532f56ba.1706703212.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 31 Jan 2024 13:12:49 +0100
Subject: [PATCH 2/3] ob-haskell/session-named-none-means-one-shot-sessions:
 Remove duplicate

*
testing/lisp/test-ob-haskell-ghci.el (ob-haskell/session-named-none-means-one-shot-sessions):
Remove duplicate from the test.
---
 testing/lisp/test-ob-haskell-ghci.el | 2 --
 1 file changed, 2 deletions(-)

diff --git a/testing/lisp/test-ob-haskell-ghci.el b/testing/lisp/test-ob-haskell-ghci.el
index cbd5f6f9a..990addcd4 100644
--- a/testing/lisp/test-ob-haskell-ghci.el
+++ b/testing/lisp/test-ob-haskell-ghci.el
@@ -117,8 +117,6 @@ (ert-deftest ob-haskell/sessions-must-not-share-variables ()
 (ert-deftest ob-haskell/session-named-none-means-one-shot-sessions ()
   "When no session, use a new session.
 \"none\" is a special name that means `no session'."
-  (test-ob-haskell-ghci ":session none" "x=2" nil)
-  (should-not (equal 2 (test-ob-haskell-ghci ":session \"none\"" "x" nil)))
   (test-ob-haskell-ghci ":session none" "x=2" nil)
   (should-not (equal 2 (test-ob-haskell-ghci ":session \"none\"" "x" nil
 
-- 
2.43.0

>From 1f1c576cf5934e1c590faa7b0cad488aa8ffb9eb Mon Sep 17 00:00:00 2001
Message-ID: <1f1c576cf5934e1c590faa7b0cad488aa8ffb9eb.1706703212.git.yanta...@posteo.net>
In-Reply-To: <316c36d2b388a81e43fabf392a75af85532f56ba.1706703212.git.yanta...@posteo.net>
References: <316c36d2b388a81e43fabf392a75af85532f56ba.1706703212.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Wed, 31 Jan 2024 13:13:11 +0100
Subject: [PATCH 3/3] 
 test-org-tests/test-duplicates-detector-testing-find-duplicates: Fix test

*
testing/lisp/test-duplicates-detector.el (test-org-tests/test-duplicates-detector-testing-find-duplicates):
Fix test condition.
---
 testing/lisp/test-duplicates-detector.el | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/testing/lisp/test-duplicates-detector.el b/testing/lisp/test-duplicates-detector.el
index b23fbce1e..25293f185 100644
--- a/testing/lisp/test-duplicates-detector.el
+++ b/testing/lisp/test-duplicates-detector.el
@@ -254,13 

Re: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Ihor Radchenko]

Ihor Radchenko  writes:

> Given that `org-latex-line-break-safe' also introduced the problem with
> verse blocks, I decided that it is better to remove it at the end.
>
> See the attached tentative patchset.

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

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

Re: Async Python src block behavior with :dir header property

[Ihor Radchenko]

Nasser Alkmim  writes:

> This does not work.
> Even though the python execution is in the right directory and the file is 
> saved correctly.
> The =return= does not produces the right file path considering the directory.
>
> #+begin_src python :dir asyncpy :async :session :return figname :results file 
> value

These header arguments are not correctly formatted.
Try M-x org-lint

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

Org mode code evaluation (was: bug#68687: [PATCH] Use text/org media type)

[Mike Kupfer]

Ihor Radchenko wrote:

> Max is referring to various security issues with evaluating code inside
> Org mode buffers. They are known, but not relevant to Org text being
> displayed in email MUA - Org never evaluates any code automatically
> without user explicitly asking for it. And in MUA, Org mode is simply
> used to apply faces. No other interaction with the displayed text/org
> mime part is allowed.

I can believe that Org text snippets are safe in an email MUA.  

But in the general case, I don't think Org mode is quite as safe as you
implied.  The last I heard, conversion from Org mode to another format
(e.g., plain text or HTML) can result in code evaluation, without the
user authorizing it (see
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48676).  I would not
expect random users to understand that format conversion is a
potentially risky operation.

mike

Async Python src block behavior with :dir header property

[Nasser Alkmim]

Hi,

I'm in the latest Emacs GUI.
This works, the =return figname= apparently can recognizee that we are in the 
=:dir=.

#+begin_src python :dir asyncpy :return figname :results file value
import matplotlib.pyplot as plt
plt.figure(figsize=(4*.5, 3*.5))
plt.plot([1, 2])
figname = 'fig.svg'
plt.savefig(figname, transparent=True, bbox_inches='tight')
#+end_src


This does not work.
Even though the python execution is in the right directory and the file is 
saved correctly.
The =return= does not produces the right file path considering the directory.

#+begin_src python :dir asyncpy :async :session :return figname :results file 
value
import matplotlib.pyplot as plt
plt.figure(figsize=(4*.5, 3*.5))
plt.plot([1, 2])
figname = 'fig.svg'
plt.savefig(figname, transparent=True, bbox_inches='tight')
#+end_src

If we inform the right path to the return statement, it works.

#+begin_src python :dir asyncpy :async :session :epilogue 
figdir='asyncpy/'+figname :return figdir :results file value
import matplotlib.pyplot as plt
plt.figure(figsize=(4*.5, 3*.5))
plt.plot([1, 2])
figname = 'fig.svg'
plt.savefig(figname, transparent=True, bbox_inches='tight')
#+end_src

Another alternative, we can use the =os= package to get the current directory.

#+header: :epilogue import os;figdir=os.getcwd()+'/'+figname 
#+begin_src python :dir asyncpy :async :session :return figdir :results file 
value
import matplotlib.pyplot as plt
plt.figure(figsize=(4*.5, 3*.5))
plt.plot([1, 2])
figname = 'fig.svg'
plt.savefig(figname, transparent=True, bbox_inches='tight')
#+end_src

Is this behavior as expected?
Is there a better way to have the figures from the python block with async 
execution?

-- 
Nasser Alkmim 
 +43 677 6408 9171