[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia

From: Juan Manuel Macías
Subject: Re: [PATCH] ox-latex.el: Unify in one single list Babel and Polyglossia languages alists
Date: Tue, 19 Jul 2022 19:31:17 +0000

Max Nikulin writes:

> On 19/07/2022 22:01, Juan Manuel Macías wrote:
>> +                     (replace-match
>> + (mapconcat (lambda (option) (if (equal "AUTO" option) language
>> option))
>> + (cond ((member language options) (delete "AUTO" options))
>> + ((member "AUTO" options) options)
>> + (t (append options (list language))))
>> +                                 ", ")
> In my opinion this code should not attempt to be excessively clever.
> If user skipped AUTO then do not append language. Test for duplicated
> options is redundant as well. Such cases may still be a reason to
> issue a warning (e.g. by `org-lint').

I completely agree. I've kept that old part of the code for backwards
compatibility and because, at the end of the day, it doesn't break
anything new. I mean, if a user declares the main language using
babelprovide and this code (too intrusive) puts the main language in the
Babel argument too (something the user doesn't want in origin), that
syntax is supported by Babel. Babel simply takes into account the main
language declared with babelprovide, if the 'main' option has been
added. But even if it doesn't return any errors, it's unnecessary

Anyway, yes, it's too intrusive. I am in favor of removing that part,
but I don't know if it will have any effect on backwards compatibility.

(BTW, I think I didn't explain in this thread the advantages of using
babelprovide over the traditional ldf file system. With ini files the
user has more control over the loaded language and there are many
options, including the ability to associate a font with a script.
Furthermore the user can create his own custom ini files, and define his
own languages. For example, I could write an ini file with specific
values for Spanish, or even an imaginary language. On the one hand, it
is an important advance. But on the other hand it adds more fuel to the
current great latex pandemic: multiplicity).

> On the other hand I would consider adding babel by default without
> explicit header. To suppress loading users may add
> #+latex_header: % \usepackage{babel}

I don't understand this very well. What would happen, then, to users who
prefer to use Polyglossia, or those who prefer to explicitly add babel
or polyglossia code?

> I like that you decided to avoid inventing of a DSL just to have
> org-like options that are translated to to a couple of preamble
> commands. From my point of view it would not help novices and would
> make things more complicated for experienced LaTeX users.

Yes, in the end I realized that this was getting into a slippery slope,
especially for the reasons you mention...

>> #+latex_class: article
>> #+latex_class_options: [11pt,draft,AUTO]
>> #+LaTeX_Header: \usepackage{babel}
>> #+language: ru
> While AUTO is suitable for \usepackage{babel} and \babelprovide, for
> class option the placeholder should be clearly associated with babel,
> e.g. BABEL_LANG instead of AUTO.

What you say makes sense. However, this was ultimately not implemented
in the current version of the patch because the argument of
org-latex-guess-babel-language is a #+latex_header keyword.

> I am not familiar enough with setting used to generate preview of
> equations or images from LaTeX source blocks, so I am not completely
> sure that suggested changes do not affect these features in some
> negative way.

I think that shouldn't affect previsualization, because if I remember
correctly the preamble used for previews is the value of
org-format-latex-header. But I'm not sure...

Best regards,

Juan Manuel 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]