[AUCTeX] Set automatically TeX-PDF-from-DVI variable if documentclass receives option dvipdfmx or dvipdfm

[Ikumi Keita]

Hi Jean and all,

afaict in case of say \documentclass[dvipdfmx]{article}
the AUCTeX parsing does not set TeX-PDF-from-DVI variable
to "Dvipdfmx". This has to be done by user.
It would be nice to get this done automatically in case
of document class option dvipdfm or dvipdfmx.
Similarly dvips global option should trigger "Dvips"

I at last reached at a state with some spare time and incorporated your
suggestion. Very sorry for such a late response!

At first I thought it is an easy job of adding similar code around a
bunch of
(TeX-add-style-hook ... ... LaTeX-dialect)
lines in latex.el, but it turned out that the expected code doesn't
work. After some survey, I realized that these all lines are not
effective for some years due to the common reason with bug#25563:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25563
I.e., the class options are no longer treated as styles in the sense of
AUCTeX.

I added some codes to recover the functionality of these lines, so they
just began to work again in the codes in the latest git repository.

Also options to graphicx and/or geometry package could be scanned.

I added these functionality as well. The option "dvipdfmx" for these
packages now sets `TeX-PDF-from-DVI' to "Dvipdfmx".

Thanks for your useful suggestion.

Regards,
Ikumi Keita

[jfbu]

Hi Keita,

Post by Ikumi Keita
Hi Jean and all,

afaict in case of say \documentclass[dvipdfmx]{article}
the AUCTeX parsing does not set TeX-PDF-from-DVI variable
to "Dvipdfmx". This has to be done by user.
It would be nice to get this done automatically in case
of document class option dvipdfm or dvipdfmx.
Similarly dvips global option should trigger "Dvips"

I at last reached at a state with some spare time and incorporated your
suggestion. Very sorry for such a late response!
At first I thought it is an easy job of adding similar code around a
bunch of
(TeX-add-style-hook ... ... LaTeX-dialect)
lines in latex.el, but it turned out that the expected code doesn't
work. After some survey, I realized that these all lines are not
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25563
I.e., the class options are no longer treated as styles in the sense of
AUCTeX.
I added some codes to recover the functionality of these lines, so they
just began to work again in the codes in the latest git repository.

Also options to graphicx and/or geometry package could be scanned.

I added these functionality as well. The option "dvipdfmx" for these
packages now sets `TeX-PDF-from-DVI' to "Dvipdfmx".
Thanks for your useful suggestion.

Sorry for late reply.

I did so far only minimal testing and it works fine with this (example) preamble:

\documentclass[a4paper, french, dvipdfmx]{amsart}
\usepackage{amssymb}
\usepackage{babel}
\frenchsetup{PartNameFull=false, og=«, fg=»}
\usepackage[dvipdfmx]{graphicx}
\usepackage[T1]{fontenc}

However, my original did not have the \usepackage[dvipdfmx]{graphicx}, i.e.,
it was

\documentclass[a4paper, french, dvipdfmx]{amsart}
\usepackage{amssymb}
\usepackage{babel}
\frenchsetup{PartNameFull=false, og=«, fg=»}

\usepackage[T1]{fontenc}

and then it does not seem to work, i.e. the class option is not picked up.

I will investigate more when I get time, but wanted to report this in case
you can reproduce it.

Thanks a lot for implementing this, this is very useful to me,

Best,

Jean-François

[jfbu]

Post by jfbu
Hi Keita,

Post by Ikumi Keita
Hi Jean and all,

afaict in case of say \documentclass[dvipdfmx]{article}
the AUCTeX parsing does not set TeX-PDF-from-DVI variable
to "Dvipdfmx". This has to be done by user.
It would be nice to get this done automatically in case
of document class option dvipdfm or dvipdfmx.
Similarly dvips global option should trigger "Dvips"

I at last reached at a state with some spare time and incorporated your
suggestion.  Very sorry for such a late response!
At first I thought it is an easy job of adding similar code around a
bunch of
   (TeX-add-style-hook ... ... LaTeX-dialect)
lines in latex.el, but it turned out that the expected code doesn't
work.  After some survey, I realized that these all lines are not
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25563
I.e., the class options are no longer treated as styles in the sense of
AUCTeX.
I added some codes to recover the functionality of these lines, so they
just began to work again in the codes in the latest git repository.

Also options to graphicx and/or geometry package could be scanned.

I added these functionality as well.  The option "dvipdfmx" for these
packages now sets `TeX-PDF-from-DVI' to "Dvipdfmx".
Thanks for your useful suggestion.

Sorry for late reply.
\documentclass[a4paper, french, dvipdfmx]{amsart}
\usepackage{amssymb}
\usepackage{babel}
\frenchsetup{PartNameFull=false, og=«, fg=»}
\usepackage[dvipdfmx]{graphicx}
\usepackage[T1]{fontenc}
However, my original did not have the \usepackage[dvipdfmx]{graphicx}, i.e.,
it was
\documentclass[a4paper, french, dvipdfmx]{amsart}
\usepackage{amssymb}
\usepackage{babel}
\frenchsetup{PartNameFull=false, og=«, fg=»}
\usepackage[T1]{fontenc}
and then it does not seem to work, i.e. the class option is not picked up.
I will investigate more when I get time, but wanted to report this in case
you can reproduce it.
Thanks a lot for implementing this, this is very useful to me,

ah sorry for noise.

I had not re-byte compiled my elpa installed auctex
after applying the patch.

It seems to work as expected now,

Thanks a lot!

Jean-François

[Mosè Giordano]

Hi Keita,

Post by Ikumi Keita
I.e., the class options are no longer treated as styles in the sense of
AUCTeX.
I added some codes to recover the functionality of these lines, so they
just began to work again in the codes in the latest git repository.

I'm not sure this is correct. Inserting a package name as class
option doesn't actually load the package. I think I removed that
feature exactly because it could have wrongly loaded packages that
weren't meant to be so.

Bye,
Mosè

[Ikumi Keita]

Hi Mosè, thanks for valuable indication!

Post by Mosè Giordano
I'm not sure this is correct. Inserting a package name as class
option doesn't actually load the package. I think I removed that
feature exactly because it could have wrongly loaded packages that
weren't meant to be so.

I'm sorry, I was wrong about whether `TeX-run-style-hooks' loads elisp
files on the fly or not. It does load the files if they are not loaded
already and run the relavant hooks actually. Hmm...

How about the attached patch? It introduces a new entry :classopt in
style hook dialect and assigns all hooks associated with class option
into that new dialect. It let-binds `TeX-style-hook-dialect' to
:classopt when it runs these hooks, so the package style hooks aren't
touched.

Some disadvantages:
- If "foo" is the class option, it doesn't suppress trying to load
the style file "foo.el(c)", just avoids to run the package style hooks
defined in that file.
- It is strange to call class options as "dialect". My intention is to
regard it as a "pseudo-dialect", but it might not be an acceptable
idea.

Regards,
Ikumi Keita

[Ikumi Keita]

Post by Ikumi Keita
How about the attached patch? It introduces a new entry :classopt in
style hook dialect and assigns all hooks associated with class option
into that new dialect. It let-binds `TeX-style-hook-dialect' to
:classopt when it runs these hooks, so the package style hooks aren't
touched.

It isn't a good idea to adhere to `TeX-run-style-hooks' after all
because it taints `TeX-active-styles'. I abandoned it and took another
straightforward approach in the attached patch #1, which is for the
current git master.

In addition, I noticed that the original idea of automatically set
`TeX-PDF-from-DVI' does not work when the user types C-c C-m to input
new "\usepackage" and supply "dvipdfmx" option to "geometry" or
"graphicx" package.

It is not limited to these cases that package options are ignored by
AUCTeX when the user inputs new "\usepackage" with C-c C-m. The reason
is:
There are many style files which behaves suitably acoording to the
package options via `LaTeX-provided-package-options-member'. They
do so in the style hooks added by `TeX-add-style-hook', where
`TeX-update-style' eventually runs those hooks if `TeX-auto-parse' is
enabled in general. However, when "\usepackage" is entered with C-c
C-m, AUCTeX runs the style hooks _before_ it asks package options to the
user, so the hooks cannot know at that time the actual options entered
later by the user.

Thus I propose another patch #2 to defer running style hooks until the
package options are actually given.

How do you think about these ideas?

Best,
Ikumi Keita

[Arash Esbati]

Post by Ikumi Keita
It isn't a good idea to adhere to `TeX-run-style-hooks' after all
because it taints `TeX-active-styles'. I abandoned it and took another
straightforward approach in the attached patch #1, which is for the
current git master.

Hi Keita,

using `TeX-update-style-hook' would have been also my suggestion -- I
think it is the straightforward approach.

Post by Ikumi Keita
Thus I propose another patch #2 to defer running style hooks until the
package options are actually given.
How do you think about these ideas?

I like this one. The current implementation bugged me also as I wrote
enumitem.el; one has to hit `C-c C-n' after doing `C-c C-m usepackage
RET name RET' in order to get things right. And I'm not sure if your
patch break other things. So +1 from me :)

Thank you for implementing it.

Best, arash

[Ikumi Keita]

Hi Arash,

Post by Arash Esbati
using `TeX-update-style-hook' would have been also my suggestion -- I
think it is the straightforward approach.

Hmm, then should we go the way of the revised patch #1? It saves the
value of `TeX-active-styles' by let-binding.

Post by Arash Esbati

Post by Ikumi Keita
Thus I propose another patch #2 to defer running style hooks until the
package options are actually given.
How do you think about these ideas?

enumitem.el; one has to hit `C-c C-n' after doing `C-c C-m usepackage
RET name RET' in order to get things right. And I'm not sure if your
patch break other things. So +1 from me :)

Thanks. I found that the previous patch is not sufficient in some cases
because there are style files which requires running style hooks to
obtain proper package options. For example, empheq.el has the following
code:
(TeX-add-style-hook
"empheq"
...
;; Load amsmath.el and mathtools.el
(TeX-run-style-hooks "amsmath" "mathtools")

;; Add elements from `LaTeX-mathtools-package-options' only once
;; and not every time the style hook runs
(dolist (elt LaTeX-mathtools-package-options)
(add-to-list 'LaTeX-empheq-package-options elt))
...

Though I haven't verified yet, I suppose there are many other style
files like this. So I reconsidered the implementation to create the
revised patch #2. It runs the style hooks twice, once to collect the
package options for completion, another to reflect the options entered
by the user. This is the same as what `TeX-arg-document' does, after
all. In order to ensure the second run even with
`LaTeX-arg-usepackage', I again binds `TeX-active-styles' by `let' in
`LaTeX-arg-usepackage-read-packages-with-options'.
Maybe `(let ((TeX-active-styles TeX-active-styles))' is better than
`(let ((TeX-active-styles nil))' here.

Best,
Ikumi Keita

[Arash Esbati]

Post by Ikumi Keita

Post by Arash Esbati
using `TeX-update-style-hook' would have been also my suggestion -- I
think it is the straightforward approach.

Hmm, then should we go the way of the revised patch #1? It saves the
value of `TeX-active-styles' by let-binding.

Hi Keita,

I only read your patch and didn't test, but it makes sense to me. One
thing occured to me: You use the following code (which was there
before):

(apply #'TeX-run-style-hooks
(apply #'append
(mapcar #'cdr LaTeX-provided-class-options)))

Assuming that `LaTeX-provided-class-options' usually has only one entry
(unlike `LaTeX-provided-package-options'), wouldn't be sufficient to do:

(apply #'TeX-run-style-hooks
(cdar LaTeX-provided-class-options))

Maybe you could also mention `:classopt' in AUCTeX manual under
`TeX-add-style-hook' [1].

Post by Ikumi Keita

Post by Arash Esbati

Post by Ikumi Keita
Thus I propose another patch #2 to defer running style hooks until the
package options are actually given.
How do you think about these ideas?

enumitem.el; one has to hit `C-c C-n' after doing `C-c C-m usepackage
RET name RET' in order to get things right. And I'm not sure if your
patch break other things. So +1 from me :)

Thanks. I found that the previous patch is not sufficient in some cases
because there are style files which requires running style hooks to
obtain proper package options. For example, empheq.el has the following
(TeX-add-style-hook
"empheq"
...
;; Load amsmath.el and mathtools.el
(TeX-run-style-hooks "amsmath" "mathtools")
;; Add elements from `LaTeX-mathtools-package-options' only once
;; and not every time the style hook runs
(dolist (elt LaTeX-mathtools-package-options)
(add-to-list 'LaTeX-empheq-package-options elt))
...

I did't like this implementation as I wrote it. I took it mainly since
`mathtools' does the same thing -- and that is the only style doing this
AFAIR (off the top of my head, though).

I think it is cleaner to set this variable outside the style hook and
write something like this:

(defvar LaTeX-empheq-package-options
(progn
(TeX-load-style "mathtools")
(append LaTeX-mathtools-package-options
'("overload" "overload2"
"ntheorem" "newmultline"
"oldmultline")))
"Package options for the empheq package.")

WDYT?

Post by Ikumi Keita
Though I haven't verified yet, I suppose there are many other style
files like this.

See above.

Post by Ikumi Keita
So I reconsidered the implementation to create the revised patch #2.
It runs the style hooks twice, once to collect the package options for
completion, another to reflect the options entered by the user. This
is the same as what `TeX-arg-document' does, after all. In order to
ensure the second run even with `LaTeX-arg-usepackage', I again binds
`TeX-active-styles' by `let' in
`LaTeX-arg-usepackage-read-packages-with-options'. Maybe `(let
((TeX-active-styles TeX-active-styles))' is better than `(let
((TeX-active-styles nil))' here.

Hmm, not sure, but `(let ((TeX-active-styles TeX-active-styles))' looks
more sensible to me either.

Best, Arash

Footnotes:
[1] https://www.gnu.org/software/auctex/manual/auctex.html#index-TeX_002dadd_002dstyle_002dhook

[Ikumi Keita]

Hi Arash,

One thing occured to me: You use the following code (which was there
(apply #'TeX-run-style-hooks
(apply #'append
(mapcar #'cdr LaTeX-provided-class-options)))
Assuming that `LaTeX-provided-class-options' usually has only one entry
(apply #'TeX-run-style-hooks
(cdar LaTeX-provided-class-options))

That's the point I'd like to know. I think that the code would usually
suffice, too. I wonder why `LaTeX-provided-class-options' has a
structure which allows more than one class. Under what situation can it
have more than one entry?

Maybe you could also mention `:classopt' in AUCTeX manual under
`TeX-add-style-hook' [1].

Thanks for suggestion, I'll try another day.

I did't like this implementation as I wrote it. I took it mainly since
`mathtools' does the same thing -- and that is the only style doing this
AFAIR (off the top of my head, though).

It seems that you are right. Then I'll take the previous method.

I think it is cleaner to set this variable outside the style hook and
(defvar LaTeX-empheq-package-options
(progn
(TeX-load-style "mathtools")
(append LaTeX-mathtools-package-options
'("overload" "overload2"
"ntheorem" "newmultline"
"oldmultline")))
"Package options for the empheq package.")
WDYT?

With this code, if the user sets the variable in init file, the expected
code isn't evaluated so the addtional entries are not appended. Thus I
think it's better to put `TeX-load-style' and `append' outside the
`defvar'.

Best,
Ikumi Keita

[Mosè Giordano]

Hi Keita,

Post by Ikumi Keita
I wonder why `LaTeX-provided-class-options' has a
structure which allows more than one class. Under what situation can it
have more than one entry?

Most LaTeX classes are based on other classes (e.g., standard ones),
you may want to keep track of the options provided to the class
directly used and to the base one.

Bye,
Mosè

[Ikumi Keita]

Hi Mosè and all,

Post by Mosè Giordano
Most LaTeX classes are based on other classes (e.g., standard ones),
you may want to keep track of the options provided to the class
directly used and to the base one.

Thanks for explanation, perhaps you are talking about the case the user
uses `(TeX-add-to-alist 'LaTeX-provided-class-options ....)' in the
customized style file?
Anyway, I confirmed that `LaTeX-provided-class-options' can have two
entries when the subfile has "\documentclass[someoption]{standalone}".
So I'll take the original approach.

My current proposal are attached below. Does anyone find difficulties
with these? If none, I'll commit them in the next week.

Best,
Ikumi Keita

[Ikumi Keita]

Post by Ikumi Keita
My current proposal are attached below. Does anyone find difficulties
with these? If none, I'll commit them in the next week.

Done.

Bye,
Ikumi Keita

[Arash Esbati]

Post by Ikumi Keita
That's the point I'd like to know. I think that the code would usually
suffice, too. I wonder why `LaTeX-provided-class-options' has a
structure which allows more than one class. Under what situation can it
have more than one entry?

Hi Keita,

sorry for my late response. My bet would have the `standalone' class,
but you know that already :-)

Post by Ikumi Keita

Post by Arash Esbati
I think it is cleaner to set this variable outside the style hook and
(defvar LaTeX-empheq-package-options
(progn
(TeX-load-style "mathtools")
(append LaTeX-mathtools-package-options
'("overload" "overload2"
"ntheorem" "newmultline"
"oldmultline")))
"Package options for the empheq package.")
WDYT?

With this code, if the user sets the variable in init file, the expected
code isn't evaluated so the addtional entries are not appended. Thus I
think it's better to put `TeX-load-style' and `append' outside the
`defvar'.

Thanks for looking at this and fixing the code.

While we're at it: I think I found some unnecessary parentheses in the
option management of geometry.el and graphicx.el which I removed[1].
Please feel free to revert the patch if I'm missing something.

Best, Arash

Footnotes:
[1] http://git.savannah.gnu.org/cgit/auctex.git/commit/?id=8b5e53d9f55bdf06e529096156845f660a8d03dc

[Ikumi Keita]

Hi Arash,

Post by Arash Esbati
While we're at it: I think I found some unnecessary parentheses in the
option management of geometry.el and graphicx.el which I removed[1].
Please feel free to revert the patch if I'm missing something.

Oh, sorry for overlooking this! Thank you very much.

Bye,
Ikumi Keita

[Arash Esbati]

Post by Ikumi Keita

Post by Arash Esbati
While we're at it: I think I found some unnecessary parentheses in the
option management of geometry.el and graphicx.el which I removed[1].
Please feel free to revert the patch if I'm missing something.

Oh, sorry for overlooking this! Thank you very much.

Hi Keita,

sure, you're welcome. I stumbled over it as I was looking at the
compiler warnings after rebuilding AUCTeX. From the ones issued by the
style files, I think 90% can be avoided by adding these lines to the
relevant styles:

(declare-function font-latex-add-keywords
"font-latex"
(keywords class))

Another 5% by these lines:

(defvar font-latex-syntactic-keywords-extra)
(declare-function font-latex-update-font-lock
"font-latex"
(&optional syntactic-kws))

WDYT, is it worth the effort? (No, I'm not asking you to do it ;-)

Best, Arash

[Ikumi Keita]

Hi Arash and all,

Post by Arash Esbati
sure, you're welcome. I stumbled over it as I was looking at the
compiler warnings after rebuilding AUCTeX. From the ones issued by the
style files, I think 90% can be avoided by adding these lines to the
(declare-function font-latex-add-keywords
"font-latex"
(keywords class))
(defvar font-latex-syntactic-keywords-extra)
(declare-function font-latex-update-font-lock
"font-latex"
(&optional syntactic-kws))
WDYT, is it worth the effort? (No, I'm not asking you to do it ;-)

It will significantly improve S/N ratio in the make log. I think it's
worth doing.

One note: if we care only the warnings at "make", similar result will be
obtained by adding these lines in lpath.el:
(autoload 'font-latex-add-keywords "font-latex")
(autoload 'font-latex-update-font-lock "font-latex")

(It seems that `declare-function' and `defvar' in lpath.el are not
effective in this way, unfortunately.)
Of course this is just a makeshift and not a proper solution.

Bye,
Ikumi Keita