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

[Pedro Andres Aranda Gutierrez]

PS: This is a very limited example. It would be nice to have more control
on fontenc. AFAIK there is not alphabeta for cyrillic encodings and
typesetting 'War and Peace' with its passages in French embedded in the
Russian text is sort of a headache ;-)

/PA

On Mon, 22 Jan 2024 at 07:30, Pedro Andres Aranda Gutierrez <
paag...@gmail.com> wrote:

> HI Juan Manuel,
>
> you are absolutely right. There are many things that should improve in the
> LaTeX exporter and simplifying language treatment is one of them. What I
> show in my example is how to circumvent all the limitations in the exporter
> and give a working example for people who need it.
>
>  Adding AUTO to latex_class_options would be extremely helpful, since then
> you can load babel indicating the main language only and even avoid the
> PassOptions and can live with \usepackage{alphabeta} only.
> This is a MWE for mixing German and Greek which I use to compare with what
> org-mode generates:
>
> ---cut---
> \documentclass[greek,ngerman]{scrartcl}
> %% \documentclass[greek,ngerman]{scrreprt}
> %% \documentclass[greek,ngerman]{scrbook}
> %% \documentclass[greek,ngerman]{article}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> \usepackage[ngerman]{babel}
> %% \PassOptionsToPackage{main=ngerman}{babel}
> \usepackage{alphabeta}
>
> \begin{document}
> Ach, unsere Freunde die Griechen: \textgreek{νους} (mit
> \verb|\textgreek{}|).\par
> Ach, unsere Freunde die Griechen: νους (direkt im Text).
> \end{document}
> ---cut---
> The commented document classes are all I had the time to test.
>
> Best, /PA
>
>
> On Sun, 21 Jan 2024 at 18:47, Juan Manuel Macías 
> wrote:
>
>> Pedro Andres Aranda Gutierrez writes:
>>
>> > +#+begin_example
>> > +,#+latex_class_options: [greek,spanish,oneside]
>> > +,#+language: es
>> > +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
>> > +,#+latex_header: \usepackage{alphabeta} % to support greek script
>> > +#+end_example
>>
>> I think this example doesn't take advantage of the AUTO facility, which
>> is what the section is about. Btw, maybe it would be nice to extend
>> ''AUTO'' to
>> latex_class_options and \PassOptionsToPackage? Something like:
>>
>> #+latex_class_options: [greek,AUTO,oneside]
>> #+language: es
>> ...
>>
>> However, I would only find the \PassOptionsToPackage command useful in
>> classes that already load babel with a main language. From Org, using
>> just pdfTeX, I think it would be simpler:
>>
>> #+language: es
>> #+latex_header: \usepackage[greek,AUTO]{babel}
>> #+latex_header: \usepackage{alphabeta} % to support greek script
>>
>> or this variant, using babelprovide and an INI file:
>>
>> #+language: es
>> #+latex_header: \usepackage[greek]{babel}
>> #+latex_header: \babelprovide[import,main]{AUTO}
>> #+latex_header: \usepackage{alphabeta}
>>
>> Best regards,
>>
>> Juan Manuel
>>
>>
>>
>
> --
> Fragen sind nicht da, um beantwortet zu werden,
> Fragen sind da um gestellt zu werden
> Georg Kreisler
>
> Headaches with a Juju log:
> unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
> a leader-deposed hook here, but we can't yet
>
>

-- 
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: New try at multi-lingual export to latex/pdf using pdflatex and babel

[Pedro Andres Aranda Gutierrez]

HI Juan Manuel,

you are absolutely right. There are many things that should improve in the
LaTeX exporter and simplifying language treatment is one of them. What I
show in my example is how to circumvent all the limitations in the exporter
and give a working example for people who need it.

 Adding AUTO to latex_class_options would be extremely helpful, since then
you can load babel indicating the main language only and even avoid the
PassOptions and can live with \usepackage{alphabeta} only.
This is a MWE for mixing German and Greek which I use to compare with what
org-mode generates:

---cut---
\documentclass[greek,ngerman]{scrartcl}
%% \documentclass[greek,ngerman]{scrreprt}
%% \documentclass[greek,ngerman]{scrbook}
%% \documentclass[greek,ngerman]{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage[ngerman]{babel}
%% \PassOptionsToPackage{main=ngerman}{babel}
\usepackage{alphabeta}

\begin{document}
Ach, unsere Freunde die Griechen: \textgreek{νους} (mit
\verb|\textgreek{}|).\par
Ach, unsere Freunde die Griechen: νους (direkt im Text).
\end{document}
---cut---
The commented document classes are all I had the time to test.

Best, /PA


On Sun, 21 Jan 2024 at 18:47, Juan Manuel Macías 
wrote:

> Pedro Andres Aranda Gutierrez writes:
>
> > +#+begin_example
> > +,#+latex_class_options: [greek,spanish,oneside]
> > +,#+language: es
> > +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> > +,#+latex_header: \usepackage{alphabeta} % to support greek script
> > +#+end_example
>
> I think this example doesn't take advantage of the AUTO facility, which
> is what the section is about. Btw, maybe it would be nice to extend
> ''AUTO'' to
> latex_class_options and \PassOptionsToPackage? Something like:
>
> #+latex_class_options: [greek,AUTO,oneside]
> #+language: es
> ...
>
> However, I would only find the \PassOptionsToPackage command useful in
> classes that already load babel with a main language. From Org, using
> just pdfTeX, I think it would be simpler:
>
> #+language: es
> #+latex_header: \usepackage[greek,AUTO]{babel}
> #+latex_header: \usepackage{alphabeta} % to support greek script
>
> or this variant, using babelprovide and an INI file:
>
> #+language: es
> #+latex_header: \usepackage[greek]{babel}
> #+latex_header: \babelprovide[import,main]{AUTO}
> #+latex_header: \usepackage{alphabeta}
>
> Best regards,
>
> Juan Manuel
>
>
>

-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet

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

[dark . key8799]

On Fri, Jan 19, 2024, at 23:15, Ihor Radchenko wrote:
> I think that the missing lambdas should come from org.el.
> So, may you M-x eval-buffer org-agenda.el, org-element.el, and org.el.
>
> And do the same in Org 9.6. (there are also cryptic lambdas there in the
> profile)
>
> (In theory, you should not need to do this M-x eval-buffer trick if you
> run Org mode from "make repro" command line in the git repo. Not sure if
> it is easier for you or not)

Well bad news then good news.

Either by evaluating buffers as requested or by trying to use "make repro" 
(which I couldn't make work), I was still getting cryptic lambdas.

I ended reinstalling emacs from scratch and the slowness disappeared. So I 
guess some native-compiled files were not updated when I switched to Org 9.7 
(even though I had nuked the straight folder). A profiler report of 
`org-agenda-redo' is also clean of lambdas (it does have # 
statements but the call tree is decently readable).

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

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

-- 
Alexandre Avanian

Re: Patch to allow adjusting latex fragment display scale factor

[Matt Huszagh]

Timothy  writes:

> Hi Matt and Ihor,
> I must admit that with the new system, I don’t see much value in accepting a
> function: we now scale the previews based on a combination of the :scale
> parameter and their actual LaTeX display size.

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

Matt

Re: Patch to allow adjusting latex fragment display scale factor

[Timothy]

Hi Matt and Ihor,

>> Any thoughts? I have not yet updated it for the most recent changes to
>> main, but I can do that.
>
> As you found in another thread, we have a WIP overhaul of the whole
> LaTeX preview system. I hope that it can be merged in the coming few
> months.
>
> AFAIU, the new system will allow setting the scale factor - see
> 
> Although, it does not look like a function is accepted as an allowed
> value.
>
> CCing Timothy and Karthik - they may have comments on the possibility to
> allow function as :scale value.

I must admit that with the new system, I don’t see much value in accepting a
function: we now scale the previews based on a combination of the :scale
parameter and their actual LaTeX display size.

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: [possible patch] Remove the '\\[0pt]' string from the last line of a verse block in LaTeX export

[Juan Manuel Macías]

Ihor Radchenko writes:

> Upon looking closer into selective removal, it turned out to be more
> tricky than I thought. I'm afraid that using \\[0pt] only in some places
> may become a bit of headache to maintain - we may accidentally break
> certain regexp replacements in `org-latex-verse-block'. In particular,
> when verse contents is not straightforward and uses \\[0pt].
>
> 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.

LaTeX code generated without org-latex-line-break-safe is much cleaner.
The decision to make this variable obsolete seems correct to me, if
there is already a better and more discreet solution. I don't know if it
will cause many problems with custom settings and filters written in
relation to this variable, as Maxim commented in a previous email... I
hope not. I have a couple of filters written already, but I don't think
it will take much work for me to readjust them.

Best regards,

Juan Manuel 

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’ve test that and it works for me per your prescription below.
And, I have committed it to the ESS git repo.  Thanks!

1. create and open test.R file containing
   x = "foo"
2. M-: (setq-local ess-gen-proc-buffer-name-function (lambda (_) "session1"))
3. M-x ess-eval-line
4. Observe "session1" R comint buffer displayed
5. create and open test2.R file containing
   y = "bar"
6. M-: (setq-local ess-gen-proc-buffer-name-function (lambda (_) "session2"))
7. M-x ess-eval-line
8. Observe that the line still goes to "session2"

--
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: Sunday, January 21, 2024 at 5:45 AM
To: Sparapani, Rodney 
Cc: Jack Kamm , ess-c...@r-project.org 
, Liu Hui , emacs-orgmode@gnu.org 

Subject: [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.


Ihor Radchenko  writes:

> We recently discovered `ess-gen-proc-buffer-name-function', but it does
> not work as we expected, unfortunately. (which is either because we
> misunderstand something or because there is a bug).

I am attaching tentative patch that will make `ess-request-a-process'
obey `ess-gen-proc-buffer-name-function'.

Re: [BUG] org-open-at-point-global fails on links with multiline descriptions in org-mode buffers [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Omar Antolín Camarena]

Thank you for the quick fix! And I'm happily surprised you decided to check the 
whole paragraph. I hadn't dared suggest that because I thought the decision to 
check only the current line was made for performance reasons. On the other 
hand, I had not thought through my proposal carefully and in particular hadn't 
noticed the points you made in response to Gregor.

-- 
Omar Antolín-Camarena

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

[Juan Manuel Macías]

Pedro Andres Aranda Gutierrez writes:

> +#+begin_example
> +,#+latex_class_options: [greek,spanish,oneside]
> +,#+language: es
> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> +#+end_example

I think this example doesn't take advantage of the AUTO facility, which
is what the section is about. Btw, maybe it would be nice to extend ''AUTO'' to
latex_class_options and \PassOptionsToPackage? Something like:

#+latex_class_options: [greek,AUTO,oneside]
#+language: es
...

However, I would only find the \PassOptionsToPackage command useful in
classes that already load babel with a main language. From Org, using
just pdfTeX, I think it would be simpler:

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

or this variant, using babelprovide and an INI file:

#+language: es
#+latex_header: \usepackage[greek]{babel}
#+latex_header: \babelprovide[import,main]{AUTO}
#+latex_header: \usepackage{alphabeta}

Best regards,

Juan Manuel 

Re: [Pre-PATCH] Overhaul of the LaTeX preview system

[Timothy]

Hi Matt,

Thanks for taking this branch for a spin and reporting back.

I’m a bit mystified by the difference you see between `$$' and `\(\)' 
delimiters (I
can’t detect any difference my end). Regarding the specific comments in your
last email though:

Matt Huszagh  writes:

> When using \(\) delimiters, using a depth adjustment of 0 (instead of
> 0.02) looks correct to me. I checked this by blowing up the fragment
> with a very large scale factor (eg 10) and then baseline misalignments
> become more obvious. This is how I ensured my baseline computation was
> correct when I wrote that patch aligning the baseline several years
> ago. I /think/ that’s a valid method, and I’ve been using my code for
> the last couple years and the baseline has always looked correct.
>
> Anyway, can you explain more why you came to the conclusion of that
> slight depth adjustment?

So, this minor correction factor came abound from blowing up the fontsize and
trying a number of combinations of fonts (as in the comment). The 0.02
correction isn’t a “best with computer modern” value, but a compromise between
the various values that seemed best for the common LaTeX maths fonts tested. A
value of 0.02 seemed to produce consistently good results across the range of
fonts.

This testing was done several months ago, so I forget the particular details,
but that is the methodology used. It’s entirely possible this could benefit from
some tweaking, I’d just like to see some high-res screenshots with a range of
fonts to help convince me that a chance is beneficial.

> Are you using $$ delimiters? That also appears> to produce other visual
> imperfections. For $F=ma$, I see the bottom of the “m” and “a” cut off
> slightly. I wonder why different delimiters produce different results.

I always use `\(\)' myself, but can’t see why that would affect the preview.

> I used> slightly different settings for dvisvgm in my implementation
> (including –exact-bbox). I wonder if that has any relevance…

It does. `--exact-bbox' is known to produce slightly dodgy results with recent
dvisvgm versions (and seems to behave differently on MacOS for some reason). Is
there a particular reason you changed the dvisvgm settings?

> I also used a different document class - standalone in preview mode.

Hmmm, I’m not sure if that could cause any issues.

> Now that I think about it, IIRC that was to address another corner case I ran
> into, which is that for large images, article will crop it before it gets to
> dvisvgm. It’s been a while since I did this and my memory is hazy, but I think
> that’s why I used standalone.

I wonder to what extend this can be resolved by just decreasing the
margins/increasing the page size.

> I can try to investigate that with a minimal issue.

That would be good :)

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: New try at multi-lingual export to latex/pdf using pdflatex and babel

[Pedro Andres Aranda Gutierrez]

Thanks for the feedback, attached is a new version

Best, /PA

On Sun, 21 Jan 2024 at 13:59, Ihor Radchenko  wrote:

> Pedro Andres Aranda Gutierrez  writes:
>
> > hopefully this is more informative. It complements the =polyglossia=
> > example with some =babel= that can be compiled with pdflatex.
>
> Thanks!
> Several minor comments.
>
> > From 4d0dcde4f8f149d3d028164c3cd3c8e9bff2a060 Mon Sep 17 00:00:00 2001
> > From: "Pedro A. Aranda" 
> > Date: Sun, 21 Jan 2024 09:39:35 +0100
> > Subject: [PATCH] Add multi-language babel example
>
> Please indicate that the patch deals with the manual in the first line:
>
>   org-manual: Add multi-language babel example
>
> And add the changelog entry.
>
> > +Another example using ~pdflatex~ and ~babel~ and mixing Latin and
>
> =pdflatex= and =babel= I think - we use ~...~ mostly for Elisp code.
>
> > +Greek fonts in the document using the =\PassOptionsToPackage= command
> > +from =babel= would be:
> > +
> > +#+begin_example
> > +,#+latex_class_options: [greek,spanish,oneside]
> > +,#+language: es
> > +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> > +,#+latex_header: \usepackage{alphabeta} % to support greek script
> > +#+end_example
> > +
> > +Note that you can add more options to the ~latex_class_options~.
>
> =#+latex_class_options:=
>
> > +The important thing is that you include the *translated* name
>
> Maybe just /translated/? Bold is usually considered too strong
> typographically.
>
> Also, I do not really understand what you mean by "translated" here.
>
> > +for the =#+language:# you specify in the other commands for
>
> =#+language:=
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at .
> Support Org development at ,
> or support my work at 
>


-- 
Fragen sind nicht da, um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
a leader-deposed hook here, but we can't yet
From d540ad65d228bfb31a672cc1f7a771504cb3f58c Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Sun, 21 Jan 2024 18:06:19 +0100
Subject: [PATCH] org-manual: Add multi-language babel example

org-manual.org: Add multi-language babel example

* doc/org-manual.org: Add an example for the LaTeX header commands
needed to export multi-language documents to pdflatex. In this case
we need to use and configure the babel package appropriately.

---
 doc/org-manual.org | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index acc6d07ff..71cc8b1a1 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13925,6 +13925,10 @@ general options (see [[*Export Settings]]).
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
   #+end_src
 
+  The value used for =babel= or =polyglossia= is set in
+  ~org-export-default-language~. The default value is ~"en"~, which
+  means American English.
+
 - =LATEX_CLASS= ::
 
   #+cindex: @samp{LATEX_CLASS}, keyword
@@ -14079,6 +14083,37 @@ the =\babelprovide= command:
 ,#+LATEX_HEADER: \babelprovide[import, main]{AUTO}
 #+end_example
 
+Another example using =pdflatex= and =babel= and mixing Latin and
+Greek fonts in the document using the =\PassOptionsToPackage= command
+from =babel= would be:
+
+#+begin_example
+,#+latex_class_options: [greek,spanish,oneside]
+,#+language: es
+,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
+,#+latex_header: \usepackage{alphabeta} % to support greek script
+#+end_example
+
+Note that you can add more options to the ~latex_class_options~.
+You need to include the language resulting from translating the
+=#+language:= statement in the other commands in your LaTeX header.
+In the previous example
+
+#+begin_example
+,#+language: es
+#+end_example
+
+is translated to
+
+#+begin_example
+\usepackage[spanish]{babel}
+#+end_example
+
+and =spanish= is used for the other header commands and in the
+=#+latex_class_options=.
+
+
+
 =Polyglossia=, for this procedure to be effective, must be loaded
 using the same =babel= classic syntax (but note that /this is not/
 the actual polyglossia syntax).  For example, suppose a document
-- 
2.34.1

Re: org-->latex and beamer, avoid blocks

[Fraga, Eric]

On Friday, 19 Jan 2024 at 08:01, Uwe Brauer via "General discussions about 
Org-mode." wrote:
> Well, right. I just realized that for example 
> when I export the document to LatReX article, then cosntructs like
>
>
> *** Code
>  :PROPERTIES:
>  :BEAMER_env: ignoreheading
>  :END:
>
> Get converted in the sense that the properties are not simply ignored
> but transformed to text, which is not what I want.

Strange.  Properties do not get exported for me.  The tags do get
exported if you haven't set the tags:nil option, however.  The heading
itself does get exported which, of course, may not be what you want.

-- 
: Eric S Fraga, with org release_9.6.13-1003-g872c1b in Emacs 30.0.50

Re: Org mode MIME type

[Timothy]

Hi Max,

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

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

Why not `text/x-org'? Among other reasons, the `x-' prefix is depreciated as of 
RFC
6648 (2012). Existing MIME type databases that use `text/x-org' should be 
updated
to use `text/org'.

We are missing IETF MIME type registration, but I hope to get to that at some
point. In the mean time the realistic options are `text/org' and
`application/vnd.emacs.org' — and I think we’ll all agree that the former is
vastly preferable.

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: org-publish-sitemap-file-entry-format documented despite being obsolete

[Stefan Kangas]

Ihor Radchenko  writes:

> Stefan Kangas  writes:
>
>> The variable `org-publish-sitemap-file-entry-format' is documented in
>> org.org in emacs.git, but that variable is obsolete.  Perhaps it should
>> be removed and/or updated.
>
> My grepping through Emacs sources does not show anything:
>
> 3 matches total for "org-publish-sitemap-file-entry-format":
> 2 matches in buffer: org-compat.el
> 762:(defcustom org-publish-sitemap-file-entry-format "%t"
> 772: 'org-publish-sitemap-file-entry-format
> 1 match in buffer: ORG-NEWS
>4056:*** ~org-publish-sitemap-file-entry-format~ is deprecated

Thanks, I must have grepped the wrong directory.  Sorry for the noise.

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

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

[Ihor Radchenko]

Stefan Kangas  writes:

> The variable `org-publish-sitemap-file-entry-format' is documented in
> org.org in emacs.git, but that variable is obsolete.  Perhaps it should
> be removed and/or updated.

My grepping through Emacs sources does not show anything:

3 matches total for "org-publish-sitemap-file-entry-format":
2 matches in buffer: org-compat.el
762:(defcustom org-publish-sitemap-file-entry-format "%t"
772: 'org-publish-sitemap-file-entry-format
1 match in buffer: ORG-NEWS
   4056:*** ~org-publish-sitemap-file-entry-format~ is deprecated

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

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

[Stefan Kangas]

The variable `org-publish-sitemap-file-entry-format' is documented in
org.org in emacs.git, but that variable is obsolete.  Perhaps it should
be removed and/or updated.

Org mode MIME type

[Max Nikulin]

Hi,

I have been surprised when I got

xdg-mime query filetype /tmp/test.org
text/org

for a following file

cat /tmp/test.org
* A section

An example of Org mode file

It is pleasant, however shouldn't it be "text/x-org", not just 
"text/org"? (I am against "application/*" variants since it is a text 
based format).


1. The MIME type has not registered in IANA, so the "x-" prefix should 
be preferable



2. It would be in line with

emacs -Q -l mailcap --batch \
--eval '(prin1 (assoc ".org" mailcap-mime-extensions))' \
--eval '(terpri)'
(".org" . "text/x-org")

I have not found any discussion of the following commit that is a part 
of shared-mime-info 2.2 release:

https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/4dd4fd5cb54d03cb73102c6f1f674675b5186e47
2021-05-27T20:27:31Z David Faure adding org-mode


  
Org-mode file


  


I think, "type" should be "text/x-org" here, perhaps "text/org" alias 
may be added to this entry to not break workflow of those who already 
have text/org e.g. in mail messages.


By the way, shouldn't description be "Org mode file" without a dash? See 
org-mode/doc/Documentation_Standards.org



- Prefer "Org mode" to "Org-mode" or "org-mode".  This is simply
  because it reflects an existing convention in [[info:emacs:Top][The Emacs 
Manual]] which
  consistently documents mode names in this form - "Text mode",
  "Outline mode", "Mail mode", etc.


Actually it is more complicated:

file --mime /tmp/test.org
/tmp/test.org: text/plain; charset=us-ascii

It is expected, since "file" relies solely on file signatures (magic 
bytes) and text files have no specific ones. A more perplexing result is


emacs -Q -l mailcap --batch \
--eval '(prin1 (mailcap-file-name-to-mime-type "/tmp/test.org"))' \
--eval '(terpri)'
"application/vnd.lotus-organizer"

in agreement with run-mailcap that reads /etc/mime.types

see --norun /tmp/test.org
Error: no "view" mailcap rules found for type 
"application/vnd.lotus-organizer"


I am unsure if it is possible to convince maintainers of
https://salsa.debian.org/debian/media-types
and
https://pagure.io/mailcap
to change mapping of .org originating from IANA, but certainly it would 
be easier for text/x-org than for text/org. IBM seized support of Lotus 
Organizer many years ago and only early versions around 1992 used .org 
suffix, later ones used or2...or6 extensions.


In the case of Emacs text/org was replaced by text/x-org:

https://list.orgmode.org/87aaiufaoj@gmail.com/T/#u
Subject: Re: Adding a new text/org mime type
Date: Fri, 21 Jan 2011 18:06:52 +0100
From: "Štěpán Němec"

Should we ask maintainers of shared-mime-info to update the Org mode entry?

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

[Ihor Radchenko]

Juan Manuel Macías  writes:

>> Although I am still a bit hesitant to remove
>> `org-latex-line-break-safe'.
>> What would be the benefit of removing it? For now, I mostly just see
>> that it will make the life harder for users in Scenario B.
>
> It's a complicated situation, because we now have two solutions to the
> same problem... It certainly sounds a bit abrupt to remove
> org-latex-line-break-safe (at least for now). I see no problem in both
> solutions coexisting. After all, the user can always give an ""
> value to org-latex-line-break-safe. The other possibility is that
> org-latex-line-break-safe is selectively deleted, as you mentioned in a
> previous email. In tables and verse blocks, unless I'm missing
> something, I think adding [0pt] would be unnecessary, with the new
> solution.

Upon looking closer into selective removal, it turned out to be more
tricky than I thought. I'm afraid that using \\[0pt] only in some places
may become a bit of headache to maintain - we may accidentally break
certain regexp replacements in `org-latex-verse-block'. In particular,
when verse contents is not straightforward and uses \\[0pt].

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.

>From d2e74cc2734eaf8d782f5acf66b11956d6ffa47e Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
Date: Thu, 18 Jan 2024 14:01:32 +0100
Subject: [PATCH v2 1/2] ox-latex: Make sure that [text] is not misinterpreted
 as LaTeX argument

* lisp/ox-latex.el (org-latex-plain-text): Protect plain text starting
from [.  It might be misinterpreted as optional command argument if
previous exported fragment ends with a command accepting such.
*
testing/lisp/test-ox-latex.el (text-ox-latex/protect-square-brackets):
Add new test.

Link: https://orgmode.org/list/87o7dju9vn@posteo.net
---
 lisp/ox-latex.el  |  9 +
 testing/lisp/test-ox-latex.el | 23 +++
 2 files changed, 32 insertions(+)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index df20345f8..a64dd5a87 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -3095,6 +3095,15 @@ (defun org-latex-plain-text (text info)
 		"\\(?:[ \t]*\\)?[ \t]*\n"
 (concat org-latex-line-break-safe "\n")
 output nil t)))
+;; Protect [foo] at the beginning of lines / beginning of the
+;; plain-text object.  This prevents LaTeX from unexpectedly
+;; interpreting @@latex:\pagebreak@@ [foo] as a command with
+;; optional argument.
+(setq output (replace-regexp-in-string
+  (rx bol (0+ space) (group "["))
+  "{[}"
+  output
+  nil nil 1))
 ;; Return value.
 output))
 
diff --git a/testing/lisp/test-ox-latex.el b/testing/lisp/test-ox-latex.el
index 41df1b823..237ad97ec 100644
--- a/testing/lisp/test-ox-latex.el
+++ b/testing/lisp/test-ox-latex.el
@@ -29,6 +29,29 @@ (unless (featurep 'ox-latex)
 
 
 
+(ert-deftest text-ox-latex/protect-square-brackets ()
+  "Test [foo] being interpreted as plain text even after LaTeX commands."
+  (org-test-with-exported-text
+  'latex
+  "* This is test
+lorem @@latex:\\pagebreak@@ [ipsum]
+
+#+begin_figure
+[lorem] figure
+#+end_figure
+
+| [foo] | 2 |
+| [bar] | 3 |
+
+- [bax]
+- [aur]
+"
+(goto-char (point-min))
+(should (search-forward "lorem \\pagebreak {[}ipsum]"))
+(should (search-forward "{[}lorem] figure"))
+(should (search-forward "{[}foo]"))
+(should (search-forward "\\item {[}bax]"
+
 (ert-deftest test-ox-latex/verse ()
   "Test verse blocks."
   (org-test-with-exported-text
-- 
2.43.0

>From dd4618b31dc5070d6802e484fd58cf50f5d3606d Mon Sep 17 00:00:00 2001
Message-ID: 
In-Reply-To: 
References: 
From: Ihor Radchenko 
Date: Sun, 21 Jan 2024 14:21:33 +0100
Subject: [PATCH v2 2/2] ox-latex: Remove org-latex-line-break-safe

This reverts commit 3f60acff7717e472d06833e9cf9fff6ca3d59337 and
subsequent relevant comments.

* lisp/ox-latex.el (org-latex-line-break-safe): Remove constant.  The
\\[0pt] is actually not safe to use in some scenarios. We use a
different approach to avoid plain text [...] being interpreted as
LaTeX optional argument - we escape [ like {[}; that's what pandoc
does.
(org-latex-clock):
(org-latex-line-break):
(org-latex-plain-text):
(org-latex-planning):
(org-latex--org-table):
(org-latex--math-table):
(org-latex-table-row):
(org-latex-verse-block):
* testing/lisp/test-org-table.el (test-org-table/to-latex):
* testing/lisp/test-ox-latex.el (test-ox-latex/verse):
(test-ox-latex/longtable): Remove references to
`org-latex-line-break-safe'.
* etc/ORG-NEWS (=ox-latex=: ~org-latex-line-break-safe~ is removed):
Announce removal.
* lisp/org-compat.el (org-latex-line-break-safe): Make obsolete.

Link: https://orgmode.org/list/878r4jg37s@posteo.net
---
 etc/ORG-NEWS   | 10 

Re: [BUG] org-open-at-point-global fails on links with multiline descriptions in org-mode buffers [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Gregor Zattler  writes:

> But how about this idea of Omar: 
>
> "I would like to suggest that org-open-at-point-global
> check to see if it is being run in an Org mode buffer
> and if so just call org-open-at-point.  That way users
> can bind org-open-at-point-global and use that key
> binding everywhere including org-mode buffers without
> loss of functionality compared to org-open-at-point."
>
> This sounds reasonable for me!?

That would be a breaking change.
`org-open-at-point-global' is more permissive compared to
`org-open-at-point'. For example, `org-open-at-point-global' would open
links inside verbatim or src blocks, while `org-open-at-point' would not.

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

Re: [BUG] org-open-at-point-global fails on links with multiline descriptions in org-mode buffers [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Gregor Zattler]

Hi Ihor, Omar, 
* Ihor Radchenko  [2024-01-21; 12:18 GMT]:
> Omar Antolín Camarena  writes:
>
>> If you have an org link with a newline embedded in the description in an 
>> org-mode buffer and put point on it, org-open-at-point correctly follows the 
>> link but org-open-at-point-global does not, it instead reports "No link 
>> found". (I have plenty of org links with newlines in the description, 
>> because org-fill-paragraph tends to reformat links that way.)
>
> Thanks for reporting!
> Fixed, on main.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ac1c72376

that works for me now with both, org-open-at-point in
org-mode buffers and org-open-at-point-global somewhere
else.

But how about this idea of Omar: 

"I would like to suggest that org-open-at-point-global
check to see if it is being run in an Org mode buffer
and if so just call org-open-at-point.  That way users
can bind org-open-at-point-global and use that key
binding everywhere including org-mode buffers without
loss of functionality compared to org-open-at-point."

This sounds reasonable for me!?

Regards, Ggregor

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

[Ihor Radchenko]

Pedro Andres Aranda Gutierrez  writes:

> hopefully this is more informative. It complements the =polyglossia=
> example with some =babel= that can be compiled with pdflatex.

Thanks!
Several minor comments.

> From 4d0dcde4f8f149d3d028164c3cd3c8e9bff2a060 Mon Sep 17 00:00:00 2001
> From: "Pedro A. Aranda" 
> Date: Sun, 21 Jan 2024 09:39:35 +0100
> Subject: [PATCH] Add multi-language babel example

Please indicate that the patch deals with the manual in the first line:

  org-manual: Add multi-language babel example

And add the changelog entry.

> +Another example using ~pdflatex~ and ~babel~ and mixing Latin and

=pdflatex= and =babel= I think - we use ~...~ mostly for Elisp code.

> +Greek fonts in the document using the =\PassOptionsToPackage= command
> +from =babel= would be:
> +
> +#+begin_example
> +,#+latex_class_options: [greek,spanish,oneside]
> +,#+language: es
> +,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
> +,#+latex_header: \usepackage{alphabeta} % to support greek script
> +#+end_example
> +
> +Note that you can add more options to the ~latex_class_options~.

=#+latex_class_options:=

> +The important thing is that you include the *translated* name

Maybe just /translated/? Bold is usually considered too strong
typographically.

Also, I do not really understand what you mean by "translated" here.

> +for the =#+language:# you specify in the other commands for

=#+language:=

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

Re: Basic citations: problems with quotes in LaTeX export

[Ihor Radchenko]

William Denton  writes:

> While trying out more about basic citations, with quotes to mark strings so I 
> can see where whitespace matters, I found that when exporting to LaTeX some 
> regular quote marks (") turn into fancy ones (“”) but others don't.
>
> Let's say we have Basic.bib (now in testing/examples/, adjust path as needed) 
> and this Org file:
>
> # --
> #+bibliography: Basic.bib
> #+cite_export: basic
>
> [cite: "prefix one" @friends "suffix one"]
>
> [cite: "global"; "prefix one" @friends "suffix one"; "prefix two" @friends 
> 'suffix two'; "global"].
> # --
>
> Export that to LaTeX and you'll see this (also attached):
>
> https://www.miskatonic.org/tmp/latex-quotes.png
>
> The suffix quote marks don't turn fancy.  Same if you change the citation 
> processor to csl.

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=83696bf21

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

Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated

[Ihor Radchenko]

Suhail Singh Canary  writes:

> Ihor Radchenko  writes:
>
>> Max Nikulin  writes:
>>
>>> https://list.orgmode.org/87bl21vazj@posteo.net
>>>
>>> Likely should be modified a bit to support derived backends.
>>
>> I think we do not do this in any of the examples for :export link
>> property in WORG. I am actually not sure how to update things to work
>> for derived backends as well.
> ...
> For what it's worth, org-special-block-extras doesn't work well with
> derived backends yet, either [1].
>
> [1]: 

`org-export-derived-backend-p' is indeed the right approach.

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

Re: [BUG] org-open-at-point-global fails on links with multiline descriptions in org-mode buffers [9.6.6 (release_9.6.6 @ /usr/share/emacs/29.1/lisp/org/)]

[Ihor Radchenko]

Omar Antolín Camarena  writes:

> If you have an org link with a newline embedded in the description in an 
> org-mode buffer and put point on it, org-open-at-point correctly follows the 
> link but org-open-at-point-global does not, it instead reports "No link 
> found". (I have plenty of org links with newlines in the description, because 
> org-fill-paragraph tends to reformat links that way.)

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=ac1c72376

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

Re: [PATCH] Unindentation fixup for code blocks

[Ihor Radchenko]

Ihor Radchenko  writes:

> Thanks! This patch does apply.
> I am not yet sure if I like this patch or the previous one more. I am
> thinking about combining them and implementing something like
> `org-move-to-text-column'.

I do not see immediate use of `org-move-to-text-column', so let's keep
things simple.

I am attaching an amended patch with modified commit message and
docstring describing the invisible text is accounted as visible.
I also added TINYCHANGE cookie as you do not appear to have FSF
copyright assignment.

Let me know if you want to make any changes to the new version of the
patch.

>From b7eb76647395eac256602bdecaab4aea3ffbe68c Mon Sep 17 00:00:00 2001
Message-ID: 
From: Psionik K <73710933+psioni...@users.noreply.github.com>
Date: Wed, 10 Jan 2024 22:37:28 +0900
Subject: [PATCH v2] org-do-remove-indentation: Ignore invisible text

* lisp/org-macs.el (org-do-remove-indentation): Set
`buffer-invisibility-spec' to nil before detecting the column or
moving to a column.

This fixes src_block indentation removal for org-modern-mode but will
also correct other cases of hidden indentation.

TINYCHANGE
---
 lisp/org-macs.el | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/lisp/org-macs.el b/lisp/org-macs.el
index 8def5cbb2..fc4fd7975 100644
--- a/lisp/org-macs.el
+++ b/lisp/org-macs.el
@@ -388,6 +388,8 @@ (defmacro org-current-text-indentation ()
 
 (defun org-do-remove-indentation ( n skip-fl)
   "Remove the maximum common indentation from the buffer.
+Do not consider invisible text when calculating indentation.
+
 When optional argument N is a positive integer, remove exactly
 that much characters from indentation, if possible.  When
 optional argument SKIP-FL is non-nil, skip the first
@@ -408,7 +410,8 @@ (defun org-do-remove-indentation ( n skip-fl)
 	;; Remove exactly N indentation, but give up if not possible.
 (when skip-fl (forward-line))
 	(while (not (eobp))
-	  (let ((ind (progn (skip-chars-forward " \t") (current-column
+	  (let* ((buffer-invisibility-spec nil) ; do not treat invisible text specially
+ (ind (progn (skip-chars-forward " \t") (current-column
 	(cond ((< ind n)
(if (eolp) (delete-region (line-beginning-position) (point))
  (throw :exit nil)))
-- 
2.43.0


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

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

[Ihor Radchenko]

Ihor Radchenko  writes:

> We recently discovered `ess-gen-proc-buffer-name-function', but it does
> not work as we expected, unfortunately. (which is either because we
> misunderstand something or because there is a bug).

I am attaching tentative patch that will make `ess-request-a-process'
obey `ess-gen-proc-buffer-name-function'.

>From 68984a5a0a1df5a5a2619b579f23f70128e979cd Mon Sep 17 00:00:00 2001
Message-ID: <68984a5a0a1df5a5a2619b579f23f70128e979cd.1705837631.git.yanta...@posteo.net>
From: Ihor Radchenko 
Date: Sun, 21 Jan 2024 12:44:32 +0100
Subject: [PATCH] ess-request-a-process: Honor
 ess-gen-proc-buffer-name-function

* lisp/ess-inf.el (ess-request-a-process): Do not make processes not
matching `ess-gen-proc-buffer-name-function' current.
---
 lisp/ess-inf.el | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/lisp/ess-inf.el b/lisp/ess-inf.el
index 9ca3f455..aaff314c 100644
--- a/lisp/ess-inf.el
+++ b/lisp/ess-inf.el
@@ -820,7 +820,7 @@ (defun ess-request-a-process (message  noswitch ask-if-1)
(delete-dups (list "R" "S+" (or (bound-and-true-p S+-dialect-name) "S+")
   "stata" (or (bound-and-true-p STA-dialect-name) "stata")
   "julia" "SAS")
- (pname-list (delq nil ;; keep only those matching dialect
+ (pname-list (delq nil ;; keep only those matching dialect and `ess-gen-proc-buffer-name-function'
(append
 (mapcar (lambda (lproc)
   (and (equal ess-dialect
@@ -828,6 +828,8 @@ (defun ess-request-a-process (message  noswitch ask-if-1)
'ess-dialect
(process-buffer (get-process (car lproc)
(not (equal ess-local-process-name (car lproc)))
+   (equal (buffer-name (process-buffer (get-process (car lproc
+  (funcall ess-gen-proc-buffer-name-function (car lproc)))
(car lproc)))
 ess-process-name-list)
 ;; append local only if running
-- 
2.43.0


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

Re: [BUG] FAQ asnwer for "How can I use arbitrary colors for words/sentences in HTML export?" is outdated

[Bastien Guerry]

Hi Max,

Max Nikulin  writes:

> Bastien, could you, please, have a look at the CI configuration. I do
> not see recent builds in
> https://builds.sr.ht/~bzg/worg

Thanks for the heads up. I've triggered the build for Worg. There is
something wrong with the CI configuration, not sure what yet, I need
to investigate.

-- 
 Bastien Guerry

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

[Pedro Andres Aranda Gutierrez]

Hi,

hopefully this is more informative. It complements the =polyglossia=
example with some =babel= that can be compiled with pdflatex.

Cheers, /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
From 4d0dcde4f8f149d3d028164c3cd3c8e9bff2a060 Mon Sep 17 00:00:00 2001
From: "Pedro A. Aranda" 
Date: Sun, 21 Jan 2024 09:39:35 +0100
Subject: [PATCH] Add multi-language babel example

---
 doc/org-manual.org | 20 
 1 file changed, 20 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index acc6d07ff..506b9b844 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13925,6 +13925,10 @@ general options (see [[*Export Settings]]).
'("AUTO" "polyglossia" t ("xelatex" "lualatex")))
   #+end_src
 
+  The value used for =babel= or =polyglossia= is set in
+  ~org-export-default-language~. The default value is ~"en"~, which
+  means American English.
+
 - =LATEX_CLASS= ::
 
   #+cindex: @samp{LATEX_CLASS}, keyword
@@ -14079,6 +14083,22 @@ the =\babelprovide= command:
 ,#+LATEX_HEADER: \babelprovide[import, main]{AUTO}
 #+end_example
 
+Another example using ~pdflatex~ and ~babel~ and mixing Latin and
+Greek fonts in the document using the =\PassOptionsToPackage= command
+from =babel= would be:
+
+#+begin_example
+,#+latex_class_options: [greek,spanish,oneside]
+,#+language: es
+,#+latex_header: \PassOptionsToPackage{main=spanish}{babel}
+,#+latex_header: \usepackage{alphabeta} % to support greek script
+#+end_example
+
+Note that you can add more options to the ~latex_class_options~.
+The important thing is that you include the *translated* name
+for the =#+language:# you specify in the other commands for
+your LaTeX header.
+
 =Polyglossia=, for this procedure to be effective, must be loaded
 using the same =babel= classic syntax (but note that /this is not/
 the actual polyglossia syntax).  For example, suppose a document
-- 
2.34.1