Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> Though ideally all the necessary fonts should be provided by
> TeXLive. I am not sure why they are not yet there in 2023.

First problem: Is there any free/libre font out there that has a
really broad and comprehensive coverage of Unicode glyphs? I really
don't know, but from time to time I hear about fonts that I assumed to
have good Unicode coverage that this is not the case (e.g. TeX Gyre).
I think, it is just an enormous amount of work to produce a complete
Unicode font (even more so, if it should look nice).

The other problem: Not everyone does a full installation of TeX Live.
So even if good fonts are available, they are not always installed on
every system (but this part could be mitigated by documentation and/or
error messages and hints).

But I'm no Unicode or font expert (I only need latin letters). I'm
just impressed what is already possible and about all the work done by
volunteers. And sometimes I'm astonished by how much work is still to
do for a complete and smooth Unicode experience. :)

-- 
Until the next mail...,
Stefan.

[PATCH] ob-python: support header argument `:results file graphics'

[Liu Hui]

Hi,

This patch adds graphics output support for ob-python via matplotlib.
Specifically, it allows to use header argument `:results file
graphics' as follows:

#+begin_src python :file "test.png" :results graphics file
import matplotlib.pyplot as plt
plt.plot([1,2,3,4,5])
#+end_src

The feature is described in the documentation as follows and has been
supported by ob-R, ob-julia, etc.

> ‘graphics’
>  When used along with ‘file’ type, the result is a link to the file
>  specified in ‘:file’ header argument.
From ee8d236310cd4bde4e33610b2b794022861fbd6a Mon Sep 17 00:00:00 2001
From: Liu Hui 
Date: Mon, 3 Jul 2023 11:13:58 +0800
Subject: [PATCH] ob-python: support header argument `:results file graphics'

* lisp/ob-python.el (org-babel-execute:python): Save current figure to
file when the result type is `file graphics'.
(org-babel-python-save-graphics): New helper function to generate code
to save graphics.
---
 lisp/ob-python.el | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/lisp/ob-python.el b/lisp/ob-python.el
index 0e0539d7a..9fae49a4d 100644
--- a/lisp/ob-python.el
+++ b/lisp/ob-python.el
@@ -72,6 +72,8 @@ (defun org-babel-execute:python (body params)
 		   (cdr (assq :session params
  (result-params (cdr (assq :result-params params)))
  (result-type (cdr (assq :result-type params)))
+ (graphics-file (and (member "graphics" result-params)
+ (org-babel-graphical-output-file params)))
 	 (return-val (when (eq result-type 'value)
 		   (cdr (assq :return params
 	 (preamble (cdr (assq :preamble params)))
@@ -81,6 +83,8 @@ (defun org-babel-execute:python (body params)
 	   (org-babel-expand-body:generic
 	body params
 	(org-babel-variable-assignments:python params))
+   (when graphics-file
+ (org-babel-python-save-graphics graphics-file params))
 	   (when return-val
 	 (format (if session "\n%s" "\nreturn %s") return-val
  (result (org-babel-python-evaluate
@@ -149,6 +153,21 @@ (defun org-babel-python-table-or-string (results)
 res)
   res)))
 
+(defun org-babel-python-save-graphics (out-file _)
+  "Return the code for saving graphics to `OUT-FILE'."
+  (format "
+try:
+import matplotlib.pyplot
+if len(matplotlib.pyplot.get_fignums()) > 0:
+matplotlib.pyplot.gcf().savefig('%s')
+else:
+raise RuntimeError('No figure is found. You need to use matplotlib\
+ functions, such as plot and imshow, to produce the graphics.')
+except ModuleNotFoundError:
+raise RuntimeError('ob-python depends on matplotlib for saving graphics')
+"
+  out-file))
+
 (defvar org-babel-python-buffers '((:default . "*Python*")))
 
 (defun org-babel-python-session-buffer (session)
-- 
2.25.1

Re: Cache must be active error

[Max Nikulin]

On 03/07/2023 00:44, Colin Baxter wrote:

Ihor Radchenko writes:

 > Just for context, the new version `org-element-cache-map' uses a
 > new macro `org-element-with-enabled-cache' that temporarily
 > enabled cache for the duration of `org-element-cache-map'.



I add org-mode (from git) early to the load-path in order to compile new
org-mode versions on the fly without closes emacs.


You may try to add

(message "org? %S" (featurep 'org))

before the line adding Org to load path. Check the *Messages* buffer 
that it reports "nil" to ensure that Org is not loaded through some 
dependencies.


When pulled commits includes changes related to macros, .elc files 
affected by macro expansions must be removed before compilation. 
*Incremental* builds may result in inconsistent code. Emacs developers 
prefer fast, but sometimes incorrect builds and they are rather 
skeptical in relation to proper support of incremental builds.


Without removing *.elc files functions like `byte-recompile-directory' 
and `batch-byte-compile' may produce files that uses old macro versions.

Re: Cache must be active error

[Colin Baxter]

> Ihor Radchenko  writes:

> Colin Baxter  writes:
>> > This should not matter and should not cause the error.  Please
>> > provide more details.
>> 
>> The debugger output on the error is:
>> 
>> --8<---cut here---start->8---
>> Debugger entered--Lisp error: (error "Cache must be active.")
>> (signal error ("Cache must be active."))  (error "Cache must be
>> active.")  (org-element-cache-map #f(compiled-function (el)
>> #))

> Just for context, the new version `org-element-cache-map' uses a
> new macro `org-element-with-enabled-cache' that temporarily
> enabled cache for the duration of `org-element-cache-map'.

>> There is an odd feature. If I reload org-mode on a org buffer,
>> using "C- C-x !" then the error vanishes on using "C-c C-a m". If
>> I launch a new emacs (28.2 or 30.50.0) then the error returns and
>> only vanishes if I reload org-mode again.

> This sounds like you got mixed Org installation or org-element.el
> from built-in Org. If it is the case, you may need to check your
> config.

> You can also try WIP branch feature/shadowcheck that tries more to
> fight mixed version issue:
> https://git.sr.ht/~yantar92/org-mode/tree/feature/shadowcheck

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

I add org-mode (from git) early to the load-path in order to compile new
org-mode versions on the fly without closes emacs.

I'll first experiment by moving

--8<---cut here---start->8---
(add-to-list 'load-path (expand-file-name "/path/to/git/org-mode/lisp"))
--8<---cut here---end--->8---

to different points in my ~/.emacs to see if that solves the issue.

Colin Baxter.

Re: Cache must be active error

[Ihor Radchenko]

Colin Baxter  writes:

> > This should not matter and should not cause the error.  Please
> > provide more details.
>
> The debugger output on the error is:
>
> --8<---cut here---start->8---
> Debugger entered--Lisp error: (error "Cache must be active.")
>   (signal error ("Cache must be active."))
>   (error "Cache must be active.")
>   (org-element-cache-map #f(compiled-function (el) #))

Just for context, the new version `org-element-cache-map' uses a new
macro `org-element-with-enabled-cache' that temporarily enabled cache
for the duration of `org-element-cache-map'. 

> There is an odd feature. If I reload org-mode on a org buffer,
> using "C- C-x !" then the error vanishes on using "C-c C-a m". If I
> launch a new emacs (28.2 or 30.50.0) then the error returns and only
> vanishes if I reload org-mode again.

This sounds like you got mixed Org installation or org-element.el from
built-in Org. If it is the case, you may need to check your config.

You can also try WIP branch feature/shadowcheck that tries more to fight
mixed version issue:
https://git.sr.ht/~yantar92/org-mode/tree/feature/shadowcheck

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

Re: Cache must be active error

[Colin Baxter]

> Ihor Radchenko  writes:

> Colin Baxter  writes:
>> I now find that when I enter `m' to match an agenda
>> TAG/PROP/TODO, I get an error telling me that the "cache must be
>> active". This error is new today and I assume the result of
>> commit 948c89644.
>> 
>> I have
>> 
>> (setq org-element-use-cache nil) (setq
>> org-element-cache-persistent nil)

> This should not matter and should not cause the error.  Please
> provide more details.

The debugger output on the error is:

--8<---cut here---start->8---
Debugger entered--Lisp error: (error "Cache must be active.")
  (signal error ("Cache must be active."))
  (error "Cache must be active.")
  (org-element-cache-map #f(compiled-function (el) #))
  (org-get-buffer-tags)
  (org-make-tags-matcher nil)
  (org-tags-view nil)
  (funcall-interactively org-tags-view nil)
  (call-interactively org-tags-view)
  (org-agenda nil)
  (funcall-interactively org-agenda nil)
  (call-interactively org-agenda nil nil)
  (command-execute org-agenda)
--8<---cut here---end--->8---

There is an odd feature. If I reload org-mode on a org buffer,
using "C- C-x !" then the error vanishes on using "C-c C-a m". If I
launch a new emacs (28.2 or 30.50.0) then the error returns and only
vanishes if I reload org-mode again.

Colin Baxter.

Re: exporting to PDF multi-lingual document

[Ihor Radchenko]

Stefan Nobis  writes:

> Ihor Radchenko  writes:
>
>> AFAIR, the basic problem is that we cannot guarantee that any given
>> UTF font is installed.
>
> Yes, indeed. Probably the best route is to make tweaking as easy as
> possible. There are still too few (if any) really comprehensive (and
> good looking) Unicode fonts available.

We might suggest installing some Libre fonts (if there are good ones)
when we detect relevant compilation errors. Though ideally all the
necessary fonts should be provided by TeXLive. I am not sure why they
are not yet there in 2023.

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

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> AFAIR, the basic problem is that we cannot guarantee that any given
> UTF font is installed.

Yes, indeed. Probably the best route is to make tweaking as easy as
possible. There are still too few (if any) really comprehensive (and
good looking) Unicode fonts available.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

"Dr. Arne Babenhauserheide"  writes:

> Isn’t the speed more relevant for large documents?

I always had the impression that luatex has mostly a rather fixed
overhead. Maybe that's because many of my larger documents make quite
some use of TikZ and most time may be spend there. Therefore I assumed
the fixed overhead does not matter that much for larger documents. But
I did no real benchmarks or performance comparisons and it might
depend of the kind of document and packages used.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[andrés ramírez]

Hi. Stefan.
> "Stefan" == Stefan Nobis  writes:


[...]


Stefan> That's quite strange. I just re-tested with emacs -Q (Emacs 28.2 
with integrated Org
Stefan> 9.5.5). It generates the following tex file:

[...]


Stefan> Maybe there are some other configurations on the Emacs or LaTeX 
side on your system that
Stefan> changes some of the defaults?

I tested your tex file with lualatex from command line, and It gave an
error about the font lmroman10-regular. So after installing
'otf-latin-modern' package. The pdf rendered with all the paragraphs.

Thanks.
Best Regards
ps: lualatex is really slow compared with pdflatex. But It works which
is the important part

Re: Cache must be active error

[Ihor Radchenko]

Colin Baxter  writes:

> I now find that when I enter `m' to match an agenda TAG/PROP/TODO, I get
> an error telling me that the "cache must be active". This error is new
> today and I assume the result of commit 948c89644.
>
> I have
>
> (setq org-element-use-cache nil)
> (setq org-element-cache-persistent nil)

This should not matter and should not cause the error.
Please provide more details.

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

Cache must be active error

[Colin Baxter]

I now find that when I enter `m' to match an agenda TAG/PROP/TODO, I get
an error telling me that the "cache must be active". This error is new
today and I assume the result of commit 948c89644.

I have

(setq org-element-use-cache nil)
(setq org-element-cache-persistent nil)

Is there a solution for those of us who do not wish to use org cache
(and org-persist)?

Colin Baxter.

Re: exporting to PDF multi-lingual document

[Ihor Radchenko]

Stefan Nobis  writes:

> But only recently I discovered a package called "fontsetup". And this
> package seems to provide a big step towards the goal discussed in the
> above mentioned thread: Provide default fonts for most common
> situations. The goal of fontsetup is more about easy switching between
> different fonts, e.g. with the option "cambria" set everything up such
> that the Microsoft Cambria font family is used and fall back to proper
> fonts where Cambria has gaps. But that's also something that would be
> nice for Org. Maybe we should have a closer look at this (I have no
> real world experience with this package, only played a little bit with
> it).

This sounds similar to
https://list.orgmode.org/orgmode/87pmiblo2v@gmail.com/

AFAIR, the basic problem is that we cannot guarantee that any given UTF
font is installed.

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

Re: exporting to PDF multi-lingual document

[Dr. Arne Babenhauserheide]

Stefan Nobis  writes:

> Ihor Radchenko  writes:
>
>> The downside of lualatex is that it is slower:
>> https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/
>
> Yes, for sure. But I have the impression that newer versions of luatex
> have become a bit faster (maybe it's just a subjective impression that
> I want to be true, because I don't want to regret the complete switch
> to luatex). :)
>
> On the other hand: Luatex is much more flexible and has better support
> for modern fonts and modern font render engines.
>
> It depends what one assumes to be the most common use case for Org. If
> it's many rather short and simple documents then pdftex should suffice
> most of the time and the fast compile speed will matter. If we want to

Isn’t the speed more relevant for large documents? Small documents don’t
need the speed that much, but for my 300 page roleplaying book I already
feel the compile times a lot (with pdflatex).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de


signature.asc
Description: PGP signature

Re: exporting to PDF multi-lingual document

[Ihor Radchenko]

Stefan Nobis  writes:

> On the other hand: Luatex is much more flexible and has better support
> for modern fonts and modern font render engines.

So does xelatex, AFAIU.

> It depends what one assumes to be the most common use case for Org. If
> it's many rather short and simple documents then pdftex should suffice
> most of the time and the fast compile speed will matter. If we want to
> support as many different situations out of the box, I think luatex
> would be the better/easier way - at the cost of slower compilation
> speeds.

The problem with luatex (and xelatex) is export to .tex files. Org is
sometimes used when writing research papers and journals generally
demand pdflatex, not luatex.

Also, some people explicitly add LaTeX headers to their documents -
headers that may or may not be compatible with LuaTeX.

What could be done is having #+LATEX_COMPILER set to something like
'auto by default - use luatex for some non-English #+LANGUAGE settings,
but fall back when headers are customized.

> Additionally, we might try to detect situations in which
> luatex would be the better choice (e.g. certain languages). But this
> would certainly be more work and lead to more complex code.

The most immediate problem to solve is figuring out a good universal
preamble that will work with UTF8 Org sources that can contain arbitrary
(known) languages.

The code will be more complex, but Timothy's work on conditional
preamble should make things much easier. So, complexity should not stop
us - the necessary infrastructure will be in place sooner or later.
https://list.orgmode.org/orgmode/875yc95rxp@tec.tecosaur.net/

> Another approach: Use pdftex for simple/short documents and make
> selection of luatex as backend engine per document as easy as
> possible.

It is already easy - #+LATEX_COMPILER

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

Re: [PATCH] org-id: implement arbitrary cross-file references

[Ihor Radchenko]

Sergei Kosyrev  writes:

> Yes, I saw your comments, thank you for them.
>
> Since they imply a non-trivial reformulation, it would require another deep 
> dive, which I cannot commit to right now.

Thanks for the update!
If you need any help with Org internals, feel free to ask questions.

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

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> The downside of lualatex is that it is slower:
> https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/

BTW: One of the discussion points in that thread has been the problem
of default fonts. With pdflatex the default font is CM (Computer
Modern) and if the appropriate packages are installed, you
automatically get cyrillic letters. That's why Max is a fan of this
solution.

With lualatex the default font is LM (Latin Modern; quite similar to
CM, but some metrics differ). And AFAIK LM is still worse in the range
of supported Unicode characters.

But only recently I discovered a package called "fontsetup". And this
package seems to provide a big step towards the goal discussed in the
above mentioned thread: Provide default fonts for most common
situations. The goal of fontsetup is more about easy switching between
different fonts, e.g. with the option "cambria" set everything up such
that the Microsoft Cambria font family is used and fall back to proper
fonts where Cambria has gaps. But that's also something that would be
nice for Org. Maybe we should have a closer look at this (I have no
real world experience with this package, only played a little bit with
it).

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Ihor Radchenko  writes:

> The downside of lualatex is that it is slower:
> https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/

Yes, for sure. But I have the impression that newer versions of luatex
have become a bit faster (maybe it's just a subjective impression that
I want to be true, because I don't want to regret the complete switch
to luatex). :)

On the other hand: Luatex is much more flexible and has better support
for modern fonts and modern font render engines.

It depends what one assumes to be the most common use case for Org. If
it's many rather short and simple documents then pdftex should suffice
most of the time and the fast compile speed will matter. If we want to
support as many different situations out of the box, I think luatex
would be the better/easier way - at the cost of slower compilation
speeds.

Another approach: Use pdftex for simple/short documents and make
selection of luatex as backend engine per document as easy as
possible. Additionally, we might try to detect situations in which
luatex would be the better choice (e.g. certain languages). But this
would certainly be more work and lead to more complex code.

-- 
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

andrés ramírez  writes:

> I have tried the snippet. But It shows just Japanese and the other
> paragraphs are not present on the PDF.

That's quite strange. I just re-tested with emacs -Q (Emacs 28.2 with
integrated Org 9.5.5). It generates the following tex file:

--8<---cut here---start->8---

% Created 2023-07-02 Sun 16:49
% Intended LaTeX compiler: lualatex
\documentclass[11pt]{article}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{wrapfig}
\usepackage{rotating}
\usepackage[normalem]{ulem}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{capt-of}
\usepackage{hyperref}
\usepackage{luatexja}
\date{}
\title{Doc multi-lingual}
\hypersetup{
 pdftitle={Doc multi-lingual},
 pdfkeywords={},
 pdfsubject={},
 pdfcreator={Emacs 28.2 (Org mode 9.5.5)}, 
 pdflang={Jp}}
\begin{document}

\maketitle

\section*{Español}
\label{sec:orgfec75bb}
Hola
\section*{English}
\label{sec:org36763e7}
Hi
\section*{French}
\label{sec:org8e5a1dd}
Ceci c'est en Français
\section*{Japanese}
\label{sec:org70cd53d}
ダウンロード
\end{document}

--8<---cut here---end--->8---

When I compile this file with lualatex, everything looks as expected
to me. BTW: I'm using TeX Live 2023 with all recent updates.

Also, from the LaTeX perspective I see nothing that should prevent the
latin letters from being shown in the final PDF. Here are the fonts
used:

--8<---cut here---start->8---

% pdffonts foo.pdf
name type  encoding emb sub 
uni object ID
 -  --- --- 
--- -
BRVOXH+LMRoman17-Regular CID Type 0C   Identity-H   yes yes 
yes  8  0
XVVEIR+LMRoman12-BoldCID Type 0C   Identity-H   yes yes 
yes 10  0
HIWCUH+LMRoman10-Regular CID Type 0C   Identity-H   yes yes 
yes 11  0
EPCPZB+HaranoAjiMincho-Regular   CID Type 0C   Identity-H   yes yes 
yes 15  0

--8<---cut here---end--->8---

Maybe there are some other configurations on the Emacs or LaTeX side
on your system that changes some of the defaults?

--
Until the next mail...,
Stefan.

Re: exporting to PDF multi-lingual document

[andrés ramírez]

Hi. Stefan.

> "Stefan" == Stefan Nobis  writes:

Stefan> Hi.  I got curious and it seems if you are willing to use lualatex 
(which is, I think,
Stefan> currently the most actively developed engine and nowadays a really 
good choice), the
Stefan> following solution should work:


[...]

I have tried the snippet. But It shows just Japanese and the other
paragraphs are not present on the PDF.

Best Regards
Andrés Ramírez

Re: [PATCH] org-id: implement arbitrary cross-file references

[Sergei Kosyrev]

Hello,

Yes, I saw your comments, thank you for them.

Since they imply a non-trivial reformulation, it would require another deep 
dive, which I cannot commit to right now.

On Sun, Jul 2, 2023 at 13:58, Ihor Radchenko <[yanta...@posteo.net](mailto:On 
Sun, Jul 2, 2023 at 13:58, Ihor Radchenko < wrote:

> Hello,
>
> It has been over one month since the last message in this thread.
> May I know if you had a chance to look at my comments?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 

Re: [PATCH] lisp/org-id.el: Add new relative timestamp feature for `ts' `org-id-method'

[Ihor Radchenko]

Hi Kierin,

It has been over one month since the last email in this thread.
May I know if you had a chance to work on your patch any further?

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

Re: [PATCH] org-id: implement arbitrary cross-file references

[Ihor Radchenko]

Hello,

It has been over one month since the last message in this thread.
May I know if you had a chance to look at my comments?

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

Re: exporting to PDF multi-lingual document

[Ihor Radchenko]

Stefan Nobis  writes:

> I have no experience with Japanese output and I'm unable to read
> Japanese, so I could not judge the correctness or quality. But the
> above approach seems to work quite well and it might be possible to
> support this solution from the Org side (because only a single package
> has to be loaded). The requirements seem to be OK (roughly TeXlive
> 2020 or newer). The package automatically sets up required fonts (but
> it is still possible to override the default font settings) and even
> with the default configuration it is possible to use Japanese fonts
> inside math mode.

The downside of lualatex is that it is slower:
https://list.orgmode.org/orgmode/87a69j9c6s.fsf@localhost/

Yet, better multi-language support would be welcome as an option.

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

Re: [PATCH] org-element-timestamp-interpreter: Return daterange anyway, if DATERANGE is non-nil

[Ihor Radchenko]

Ilya Chernyshov  writes:

> In the new patch I added :range-type timestamp property, adjusted
> interpreter,
> parser functions, added tests for the property.

Thanks!

Some general stylistic comments:

1. You left some whitespace-only blank lines and spaces at the end of
   lines. Please, clean them up.
2. Please, use double space between sentences in the commit message and
   link to this thread. See
   https://orgmode.org/worg/org-contribute.html#commit-messages
3. I noticed some (let((...) forms. Please put spaces between sexps like
   (let ((...)
   ^ space here

> * lisp/org-element (org-element-timestamp-parser): Add :range-type property

Dot is missing at the end of the sentence here.

>  (defun org-element-timestamp-interpreter (timestamp _)
>"Interpret TIMESTAMP object as Org syntax."
> ...
> +  (concat
> +  "<" start-date (and start-time (concat " " start-time))
> +  (if date-range-p
> +  (concat ">--<" end-date (and end-time (concat " " 
> end-time)))
> +(if time-range-p (concat "-" end-time)))
> +  ">")))

Here, you are manually constructing time part of the timestamp,
bypassing `org-time-stamp-format' and `org-timestamp-formats'. Please,
use `org-time-stamp-format' for times as well.
If necessary, feed free to extend `org-time-stamp-format' and the value
of `org-timestamp-formats' constant.

> + (dolist (s (list repeat-string warning-string))
> +   (when (org-string-nw-p s)
> + (setq ts (string-replace ">" (concat " " s ">") ts
> + (pcase (org-element-property :type timestamp)
> +  ((or `active `active-range)
> +   ts)
> +  ((or `inactive `inactive-range)
> +   (string-replace
> +"<" "["
> +(string-replace ">" "]" ts)))

`string-replace' is fragile here. If we ever need to put "<" or ">"
inside timestamp, random breakages may happen. Please, rewrite.



>(should
> (string-match
> -"\\[2012-03-29 .* 16:40\\]--\\[2012-03-29 .* 16:41\\]"
> +"\\[2012-03-29 .* 16:40-16:41\\]"
>  (org-element-timestamp-interpreter
>   '(timestamp
> (:type inactive-range :year-start 2012 :month-start 3 :day-start 29
> :hour-start 16 :minute-start 40 :year-end 2012 :month-end 3
> :day-end 29 :hour-end 16 :minute-end 41)) nil)))
> +  
>;; Diary.
>(should (equal (org-test-parse-and-interpret "<%%diary-float t 4 2>")
>"<%%diary-float t 4 2>\n"))
> -- 
> 2.40.1

> * lisp/org-element (org-element-timestamp-interpreter): For ranges:
> When :range-type is nil or `timerange', return timerange ( HH:MM-HH:MM>) if date-start and date-end are equal; return
> daterange(<...>--<...>) otherwise. When :range-type is `daterange',
> return daterange anyway. Refactor the code.

Interpreting timestamps with :time-range nil and
:day-end/:year-end/:month-end non-nil as timerange is a breaking change.
Let's avoid it.

With the new version of the parser, the test example will never happen,
but the tested AST structure might happen in the wild - we do not want
to break anything when it is not necessary.

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

Re: exporting to PDF multi-lingual document

[Stefan Nobis]

Hi.

I got curious and it seems if you are willing to use lualatex (which
is, I think, currently the most actively developed engine and nowadays
a really good choice), the following solution should work:

--8<---cut here---start->8---

#+TITLE: Doc multi-lingual
#+options: author:nil email:nil toc:nil num:nil date:nil
#+LATEX_COMPILER: lualatex
#+LANGUAGE: jp
#+LaTeX_Header: \usepackage{luatexja}

* Español
Hola
* English
Hi
* French
Ceci c'est en Français
* Japanese
ダウンロード

--8<---cut here---end--->8---

The crucial parts are using lualatex and loading the package
"luatexja". It seems, that the package luatexja is currently one of
the best options to produce Japanese output and it is actively
developed. There is also quite a bit of documentation (see e.g. with
"texdoc luatexja" on the CLI or https://www.ctan.org/pkg/luatexja).

I have no experience with Japanese output and I'm unable to read
Japanese, so I could not judge the correctness or quality. But the
above approach seems to work quite well and it might be possible to
support this solution from the Org side (because only a single package
has to be loaded). The requirements seem to be OK (roughly TeXlive
2020 or newer). The package automatically sets up required fonts (but
it is still possible to override the default font settings) and even
with the default configuration it is possible to use Japanese fonts
inside math mode.

-- 
Until the next mail...,
Stefan.

Re: [Bug] org-insert-link removes on one link from 2 added by org-store-link

[Ihor Radchenko]

Max Nikulin  writes:

> When some heading has the CUSTOM_ID property
>
>  8< 
> * title
> :PROPERTIES:
> :CUSTOM_ID: a-heading
> :END:
>  >8 
>
> M-x org-store-link adds 2 entries:
> - [[*title][title]]
> - [[#a-heading][title]]
>
> however `org-insert-link' (C-c C-l) removes from the stored link only 
> one of them. As a result the number of unused stored links increases 
> during an Emacs session.

Confirmed.
Not Urgent.

> My expectation is that
> - either `org-store-links' adds a single option (my preference is 
> #custom_id)

That could be a defcustom, maybe.

> - or `org-insert-link' removes the whole group.

> I have no idea how to implement second variant keeping backward 
> compatibility.

We can, for example, group the links into sub-lists in org-stored-links.
Or maintain a separate helper register that will keep track of the links
to be removed together.
That said, removing multiple lines by `org-insert-link' will most likely
be unexpected for some users.

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

[Bug] org-insert-link removes on one link from 2 added by org-store-link

[Max Nikulin]

When some heading has the CUSTOM_ID property

 8< 
* title
:PROPERTIES:
:CUSTOM_ID: a-heading
:END:
 >8 

M-x org-store-link adds 2 entries:
- [[*title][title]]
- [[#a-heading][title]]

however `org-insert-link' (C-c C-l) removes from the stored link only 
one of them. As a result the number of unused stored links increases 
during an Emacs session.


My expectation is that
- either `org-store-links' adds a single option (my preference is 
#custom_id)

- or `org-insert-link' removes the whole group.

I have no idea how to implement second variant keeping backward 
compatibility.



Ihor Radchenko. Re: [BUG] org-store-link-functions advertizes that the 
first non-nil return value is used, but it is not how org-store-link 
handles it. Wed, 28 Sep 2022 09:03:59 +0800.

https://list.orgmode.org/87bkr0gvi8.fsf@localhost


Would you mind reporting this and MWE in a new thread?
It will be easier to track then.

Re: org-insert-link completion by description (Re: what is the purpose of "This link has already been stored"?)

[Samuel Wales]

there is not supposed to be any connection between org refile or org
goto with the code in org insert link.

completion works to select ol paths for org refile and also for org
refile when it is doing goto.  i just want the same for links.

On 7/1/23, Max Nikulin  wrote:
> On 02/07/2023 12:02, Samuel Wales wrote:
>> another window would not work for me but using completion as i do with
>> e.g. refile goto would.
>
> Samuel, you claimed that completion by description does not work for
> `org-insert-link'. I expect that it is fixed in Org-9.6 since I do not
> see the issue with the default completion. It is the reason why I asked
> you to confirm that *default completion* works for you as well. I
> suspect that the cause of your problem is either ido or your customization.
>
> I see no connection of `org-refile' and `org-goto' with the code in
> `org-insert-link'.
>
>
>


-- 
The Kafka Pandemic

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