bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xemacs is fine
Hello
The following problem only occurs in GNU emacs 24.5 or 25.0.50.
I have two files:
The first is saved in latin-1 but its header state
\usepackage[utf8]{inputenc}
And the other is the other way around
saved in UTF8 header is
\usepackage[latin1]{inputenc}
Both are displayed correctly in Xemacs and but not in GNU emacs.
Regards
Uwe Brauer
Emacs : GNU Emacs 25.0.50.1 (i686-pc-linux-gnu, GTK+ Version 2.20.1)
of 2015-09-28
Package: 2015-10-04
current state:
==
(setq
AUCTeX-date "2015-10-04"
window-system 'x
LaTeX-version "2e"
TeX-style-path '("/home/oub/ALLES/var/auctex"
"/home/oub/emacs/site-lisp/packages/auctex-git/auctex/style"
"/home/oub/.emacs.d/auctex/auto" "/home/oub/tex/sty/auto"
"auto" "style")
TeX-auto-save t
TeX-parse-self t
TeX-master t
TeX-command-list '(("TeX" "%(PDF)%(tex) %(file-line-error) %(extraopts)
%`%S%(PDFout)%(mode)%' %t"
TeX-run-TeX nil (plain-tex-mode ams-tex-mode texinfo-mode)
:help "Run plain TeX")
("LaTeX" "%`%l%(mode)%' %t" TeX-run-TeX nil (latex-mode
doctex-mode) :help
"Run LaTeX")
("Makeinfo" "makeinfo %(extraopts) %t" TeX-run-compile nil
(texinfo-mode) :help
"Run Makeinfo with Info output")
("Makeinfo HTML" "makeinfo %(extraopts) --html %t"
TeX-run-compile nil
(texinfo-mode) :help "Run Makeinfo with HTML output")
("AmSTeX" "amstex %(PDFout) %(extraopts) %`%S%(mode)%' %t"
TeX-run-TeX nil
(ams-tex-mode) :help "Run AMSTeX")
("ConTeXt" "%(cntxcom) --once --texutil %(extraopts)
%(execopts)%t" TeX-run-TeX nil
(context-mode) :help "Run ConTeXt once")
("ConTeXt Full" "%(cntxcom) %(extraopts) %(execopts)%t"
TeX-run-TeX nil
(context-mode) :help "Run ConTeXt until completion")
("BibTeX" "bibtex %s" TeX-run-BibTeX nil t :help "Run
BibTeX")
("Biber" "biber %s" TeX-run-Biber nil t :help "Run Biber")
("View" "%V" TeX-run-discard-or-function t t :help "Run
Viewer")
("Print" "%p" TeX-run-command t t :help "Print the file")
("Queue" "%q" TeX-run-background nil t :help "View the
printer queue" :visible
TeX-queue-command)
("File" "%(o?)dvips %d -o %f " TeX-run-dvips t t :help
"Generate PostScript file")
("Dvips" "%(o?)dvips %d -o %f " TeX-run-dvips nil t :help
"Convert DVI file to PostScript")
("Ps2pdf" "ps2pdf %f" TeX-run-ps2pdf nil t :help "Convert
PostScript file to PDF")
("Index" "makeindex %s" TeX-run-index nil t :help
"Run makeindex to create index file")
("Xindy" "texindy %s" TeX-run-command nil t :help "Run
xindy to create index file")
("Check" "lacheck %s" TeX-run-compile nil (latex-mode) :help
"Check LaTeX file for correctness")
("ChkTeX" "chktex -v6 %s" TeX-run-compile nil (latex-mode)
:help
"Check LaTeX file for common mistakes")
("Spell" "(TeX-ispell-document \"\")" TeX-run-function nil
t :help
"Spell-check the document")
("Clean" "TeX-clean" TeX-run-function nil t :help
"Delete generated intermediate files")
("Clean All" "(TeX-clean t)" TeX-run-function nil t :help
"Delete generated intermediate and output files")
("Other" "" TeX-run-command t t :help "Run an arbitrary
command"))
)
testcodutf-headerlatin1.tex
Description: Binary data
testcodtlatin1-headerut8.tex
Description: Binary data
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xemacs is fine
Uwe Brauer writes:
> Hello
>
> The following problem only occurs in GNU emacs 24.5 or 25.0.50.
>
> I have two files:
>
> The first is saved in latin-1 but its header state
> \usepackage[utf8]{inputenc}
>
> And the other is the other way around
> saved in UTF8 header is
>
> \usepackage[latin1]{inputenc}
>
>
> Both are displayed correctly in Xemacs and but not in GNU emacs.
I have a hard time understanding what you mean by "displayed correctly"
when the display does not correspond to what LaTeX would output.
Why are you lying to LaTeX/Emacs about the document encoding? And what
do you hope to achieve by Emacs ignoring this?
Of course one can switch off inputenc encoding recognition, cf.
latex-inputenc-coding-alist is a variable defined in ‘latexenc.el’.
Its value is shown below.
Documentation:
Mapping from LaTeX encodings in "inputenc.sty" to Emacs coding systems.
LaTeX encodings are specified with "\usepackage[encoding]{inputenc}".
Used by the function ‘latexenc-find-file-coding-system’.
You can customize this variable.
Value: (("ansinew" . windows-1252)
("applemac" . mac-roman)
("ascii" . us-ascii)
("cp1250" . windows-1250)
("cp1252" . windows-1252)
("cp1257" . cp1257)
("cp437de" . cp437)
("cp437" . cp437)
("cp850" . cp850)
("cp852" . cp852)
("cp858" . cp858)
("cp865" . cp865)
("latin1" . iso-8859-1)
("latin2" . iso-8859-2)
("latin3" . iso-8859-3)
("latin4" . iso-8859-4)
("latin5" . iso-8859-5)
("latin9" . iso-8859-15)
("next" . next)
("utf8" . utf-8)
("utf8x" . utf-8))
[back]
but in particular for telling apart various different 8-bit encodings
there is not much of an alternative.
--
David Kastrup
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xemacs is fine
Hi Uwe,
2015-11-04 16:17 GMT+01:00 Uwe Brauer :
>
> Hello
>
> The following problem only occurs in GNU emacs 24.5 or 25.0.50.
>
> I have two files:
>
> The first is saved in latin-1 but its header state
> \usepackage[utf8]{inputenc}
>
> And the other is the other way around
> saved in UTF8 header is
>
> \usepackage[latin1]{inputenc}
>
>
> Both are displayed correctly in Xemacs and but not in GNU emacs.
GNU Emacs has "latexenc" package which opens a file with the encoding
specified by the inputenc package and I think this feature is
valuable, since the actual file encoding should match the inputenc
encoding anyway. Then, I believe this is the classic case of "this
isn't a bug but a feature".
Cheers,
Mosè
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xemacs is fine
>>> "David" == David Kastrup writes:
> Uwe Brauer writes:
>> Hello
>>
>> The following problem only occurs in GNU emacs 24.5 or 25.0.50.
>>
>> I have two files:
>>
>> The first is saved in latin-1 but its header state
>> \usepackage[utf8]{inputenc}
>>
>> And the other is the other way around
>> saved in UTF8 header is
>>
>> \usepackage[latin1]{inputenc}
>>
>>
>> Both are displayed correctly in Xemacs and but not in GNU emacs.
> I have a hard time understanding what you mean by "displayed correctly"
> when the display does not correspond to what LaTeX would output.
I thought, that sending the latex files would have been enough. I attach
the screenshots.
> Why are you lying to LaTeX/Emacs about the document encoding? And what
> do you hope to achieve by Emacs ignoring this?
This is not on purpose of course, so this could occur if one has either
a very large header and forgets what coding has been selected (this is lame I
know) or more realistically you have a multi file documentation and
don't recall its encoding.
However there is one thing I just have to add. Maybe I was «spoiled»
in the past by Xemacs/x-symbol behavior which displayed any coding
correctly but internally had the files saved in ascii mode. (Like
running iso-iso2tex on every save).
Of course thinking about it again, you are right. This is a bad habit.
So this is not a bug.
I could solve the issue of the wrongly displayed coding by just removing
the incorrect header and reopening the file.
BTW how else could this wrong coding be repaired? I am asking because I
have encountered similar problems in non latex files, which have been
modified by Xemacs.
> Of course one can switch off inputenc encoding recognition, cf.
> latex-inputenc-coding-alist is a variable defined in ‘latexenc.el’.
> Its value is shown below.
I did not know about this. Thanks for pointing it out.
> Documentation:
> but in particular for telling apart various different 8-bit encodings
> there is not much of an alternative.
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21825: 2015-10-04; utf8 and latin1 coding problem in GNU emacs, Xemacs is fine
Uwe Brauer writes:
"David" == David Kastrup writes:
>
>> Uwe Brauer writes:
>>> Hello
>>>
>>> The following problem only occurs in GNU emacs 24.5 or 25.0.50.
>>>
>>> I have two files:
>>>
>>> The first is saved in latin-1 but its header state
>>> \usepackage[utf8]{inputenc}
>>>
>>> And the other is the other way around
>>> saved in UTF8 header is
>>>
>>> \usepackage[latin1]{inputenc}
>>>
>>>
>>> Both are displayed correctly in Xemacs and but not in GNU emacs.
>
>> I have a hard time understanding what you mean by "displayed correctly"
>> when the display does not correspond to what LaTeX would output.
>
>
> I thought, that sending the latex files would have been enough. I attach
> the screenshots.
>
>
>> Why are you lying to LaTeX/Emacs about the document encoding?
>> And what do you hope to achieve by Emacs ignoring this?
>
> This is not on purpose of course, so this could occur if one has
> either a very large header and forgets what coding has been selected
> (this is lame I know) or more realistically you have a multi file
> documentation and don't recall its encoding.
>
> However there is one thing I just have to add. Maybe I was «spoiled»
> in the past by Xemacs/x-symbol behavior which displayed any coding
> correctly but internally had the files saved in ascii mode. (Like
> running iso-iso2tex on every save).
So you have X-Symbol convert the buffers to pure ASCII input for LaTeX
but load the inputenc package in your document anyway, specifying some
completely random encoding that's a superset of ASCII and has nothing to
do with the buffer encoding.
> Of course thinking about it again, you are right. This is a bad habit.
I cannot rule out that X-Symbol's operation is incompatible with that of
latexenc.el. I have a hard time considering that a bug of latexenc.el,
though.
> So this is not a bug.
>
> I could solve the issue of the wrongly displayed coding by just
> removing the incorrect header and reopening the file.
>
>
> BTW how else could this wrong coding be repaired? I am asking because
> I have encountered similar problems in non latex files, which have
> been modified by Xemacs.
You can load a file with a particular encoding by using
C-x RET c latin-1 RET C-x C-f filename RET
for example.
You can change the coding system for saving by using
C-x RET f latin-9 RET
for example.
--
David Kastrup
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.
Hi,
steps to reproduce:
create file foo.dtx
\iffalse % meta-comment
%<*macos>
\documentclass{article}
\usepackage{fontspec}
\begin{document}
\end{document}
%
\fi
\documentclass{scrdoc}
\begin{document}
\end{document}
try to run (pdf)latex via C-c C-c
you should see the prompt:
>
> XeTeX, LuaTeX are required to build this document.
> Do you want to select one of these engines?
>
as an aside: sometimes the prompt appears in the
mini-buffer, sometimes as a pop-up (I use framepop.el)
but I have not been able to determine when happens what.
The problem was from a much bigger dtx file, and it
has taken me quite some time to reduce it to the mwe above.
The above structure is quite typical of a dtx file
which can extract files using docstrip, delimited
by guards in the dtx.
In the case at hand, the parsing done by auctex
could possibly identify the \iffalse ... \fi
but in my actual package.dtx, this is more complicated
as I modify catcodes to safely skip hundreds of lines
containing themselves conditionals. Thus it is more
like ~iffalse...~fi in the source.
The mwe above has given me the idea of another one,
which is a foo.tex, not foo.dtx file:
\documentclass{article}
\usepackage{filecontents}
\begin{filecontents}{bar.tex}
\documentclass{article}
\usepackage{fontspec}
\begin{document}
\end{document}
\end{filecontents}
\begin{document}
\end{document}
This will elicit again the
> XeTeX, LuaTeX are required to build this document.
> Do you want to select one of these engines?
>
prompt.
It was hard to get these two mwe's (although now it looks
obvious) because once we get the prompt we can suppress
the entire buffer contents and put anything and we still get
it. Even after removing entirely auto/ directory, etc...
One has to kill the buffer and reload it to get rid
of the prompt (after having killed the fontspec line)
I noticed the issue with a package of mine. I now realize
something has changed in auctex because a Septembre 2013
version of package.dtx now also shows the issue, and I most
definitely did not encounter it back then,
actually I don't think this problem
was showing up with the September 12, 2015 version of
package.dtx, but I forgot when exactly I saw it for the first time.
Best,
Jean-François
Emacs : GNU Emacs 24.5.7 (x86_64-apple-darwin13.4.0, Carbon Version 157 AppKit
1265.21)
of 2015-09-28 on Atago.local
Package: 11.88.8
current state:
==
(setq
AUCTeX-date "2015-08-28"
window-system 'mac
LaTeX-version "2e"
TeX-style-path '("~/.emacs.d/auctex"
"/Users/xxx/.emacs.d/elpa/auctex-11.88.8/style"
"/Users/xxx/.emacs.d/auctex/auto"
"/Users/xxx/.emacs.d/auctex/style" "auto" "style")
TeX-auto-save t
TeX-parse-self t
TeX-master t
TeX-command-list '(("TeX"
"%(PDF)%(tex) %(extraopts) %`%S%(PDFout)%(mode)%' %t"
TeX-run-TeX nil
(plain-tex-mode texinfo-mode ams-tex-mode) :help
"Run plain TeX")
("LaTeX" "%`%l%(mode)%' %t" TeX-run-TeX nil
(latex-mode doctex-mode) :help "Run LaTeX")
[...]
)
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine
Hi Jean-François,
2015-11-04 22:47 GMT+01:00 jfbu :
> Remember to cover the basics, that is, what you expected to happen and
> what in fact did happen.
>
>
>
> Hi,
>
> steps to reproduce:
>
> create file foo.dtx
>
> \iffalse % meta-comment
> %<*macos>
> \documentclass{article}
> \usepackage{fontspec}
> \begin{document}
> \end{document}
> %
> \fi
> \documentclass{scrdoc}
> \begin{document}
> \end{document}
>
> try to run (pdf)latex via C-c C-c
>
> you should see the prompt:
>
>>
>> XeTeX, LuaTeX are required to build this document.
>> Do you want to select one of these engines?
>>
>
> as an aside: sometimes the prompt appears in the
> mini-buffer, sometimes as a pop-up (I use framepop.el)
> but I have not been able to determine when happens what.
>
> The problem was from a much bigger dtx file, and it
> has taken me quite some time to reduce it to the mwe above.
>
> The above structure is quite typical of a dtx file
> which can extract files using docstrip, delimited
> by guards in the dtx.
>
> In the case at hand, the parsing done by auctex
> could possibly identify the \iffalse ... \fi
> but in my actual package.dtx, this is more complicated
> as I modify catcodes to safely skip hundreds of lines
> containing themselves conditionals. Thus it is more
> like ~iffalse...~fi in the source.
>
> The mwe above has given me the idea of another one,
> which is a foo.tex, not foo.dtx file:
>
> \documentclass{article}
>
> \usepackage{filecontents}
>
> \begin{filecontents}{bar.tex}
> \documentclass{article}
> \usepackage{fontspec}
> \begin{document}
> \end{document}
> \end{filecontents}
>
> \begin{document}
> \end{document}
>
> This will elicit again the
>
>> XeTeX, LuaTeX are required to build this document.
>> Do you want to select one of these engines?
>>
>
> prompt.
>
> It was hard to get these two mwe's (although now it looks
> obvious) because once we get the prompt we can suppress
> the entire buffer contents and put anything and we still get
> it. Even after removing entirely auto/ directory, etc...
>
> One has to kill the buffer and reload it to get rid
> of the prompt (after having killed the fontspec line)
Or just set `TeX-check-engine' to nil ;-)
I don't think can really deal with TeX conditionals, bud I'd like to
be proven wrong.
If the problem is the prompt you can change the value of
`TeX-check-engine' and this ticket will be closed, if this is a
request to implement parsing of conditionals we can keep this open,
even if for me would be "wontfix" or "patches welcome".
Bye,
Mosè
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine
Hi Mosè
Le 4 nov. 2015 à 23:20, Mosè Giordano a écrit :
> Hi Jean-François,
>
> 2015-11-04 22:47 GMT+01:00 jfbu :
>> Remember to cover the basics, that is, what you expected to happen and
>> what in fact did happen.
>>
>>
>>
>> Hi,
>>
>> steps to reproduce:
>>
>> create file foo.dtx
>>
>> \iffalse % meta-comment
>> %<*macos>
>> \documentclass{article}
>> \usepackage{fontspec}
>> \begin{document}
>> \end{document}
>> %
>> \fi
>> \documentclass{scrdoc}
>> \begin{document}
>> \end{document}
>>
>> try to run (pdf)latex via C-c C-c
>>
>> you should see the prompt:
>>
>>>
>>> XeTeX, LuaTeX are required to build this document.
>>> Do you want to select one of these engines?
>>>
>>
>> as an aside: sometimes the prompt appears in the
>> mini-buffer, sometimes as a pop-up (I use framepop.el)
>> but I have not been able to determine when happens what.
>>
>> The problem was from a much bigger dtx file, and it
>> has taken me quite some time to reduce it to the mwe above.
>>
>> The above structure is quite typical of a dtx file
>> which can extract files using docstrip, delimited
>> by guards in the dtx.
>>
>> In the case at hand, the parsing done by auctex
>> could possibly identify the \iffalse ... \fi
>> but in my actual package.dtx, this is more complicated
>> as I modify catcodes to safely skip hundreds of lines
>> containing themselves conditionals. Thus it is more
>> like ~iffalse...~fi in the source.
>>
>> The mwe above has given me the idea of another one,
>> which is a foo.tex, not foo.dtx file:
>>
>> \documentclass{article}
>>
>> \usepackage{filecontents}
>>
>> \begin{filecontents}{bar.tex}
>> \documentclass{article}
>> \usepackage{fontspec}
>> \begin{document}
>> \end{document}
>> \end{filecontents}
>>
>> \begin{document}
>> \end{document}
>>
>> This will elicit again the
>>
>>> XeTeX, LuaTeX are required to build this document.
>>> Do you want to select one of these engines?
>>>
>>
>> prompt.
>>
>> It was hard to get these two mwe's (although now it looks
>> obvious) because once we get the prompt we can suppress
>> the entire buffer contents and put anything and we still get
>> it. Even after removing entirely auto/ directory, etc...
>>
>> One has to kill the buffer and reload it to get rid
>> of the prompt (after having killed the fontspec line)
>
> Or just set `TeX-check-engine' to nil ;-)
>
> I don't think can really deal with TeX conditionals, bud I'd like to
> be proven wrong.
I concur that it is impossible to deal with TeX conditionals
in the generality I would need, short of re-implementing
TeX in lisp. But I would have expected
handling \if... \else \fi with nesting to be much more
feasible, but if you say it's hard, I surely must believe you.
>
> If the problem is the prompt you can change the value of
> `TeX-check-engine' and this ticket will be closed, if this is a
> request to implement parsing of conditionals we can keep this open,
> even if for me would be "wontfix" or "patches welcome".
It is not a request fo implement parsing of conditionals
because my second example has no conditionals.
> \documentclass{article}
>
> \usepackage{filecontents}
>
> \begin{filecontents}{bar.tex}
> \documentclass{article}
> \usepackage{fontspec}
> \begin{document}
> \end{document}
> \end{filecontents}
>
> \begin{document}
> \end{document}
>
Thanks for the pointer to TeX-check-engine
I find it somewhat fragile to decide only on the
basis of having found a \usepackage{fontspec} line
that the engine should be XeTeX or LuaTeX.
This raises maintenance issues on your side as
you must keep an eye on what fontspec will become
in the future, and also on what future engines
might arise etc...
best
Jean-François
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine
close 21832
tags 21832 notabug
thanks
2015-11-04 23:30 GMT+01:00 jfbu :
> I find it somewhat fragile to decide only on the
> basis of having found a \usepackage{fontspec} line
> that the engine should be XeTeX or LuaTeX.
Do you have other suggestions? They're welcome :-)
> This raises maintenance issues on your side as
> you must keep an eye on what fontspec will become
> in the future, and also on what future engines
> might arise etc...
Well, in style/ directory we have 196 files that raise lots of
maintenance issues, so we are used to them ;-) We do our best to keep
them updated, and we seek for other people helping us.
I'm closing this ticket.
Bye,
Mosè
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine
Le 04/11/2015 23:37, Mosè Giordano a écrit :
close 21832
tags 21832 notabug
thanks
2015-11-04 23:30 GMT+01:00 jfbu :
I find it somewhat fragile to decide only on the
basis of having found a \usepackage{fontspec} line
that the engine should be XeTeX or LuaTeX.
Do you have other suggestions? They're welcome :-)
I don't at this time ... I was surprised by the prompt
for XeTeX/LuaTeX (which in my use case was wrong, but
certainly that was very specific context), and if I had
to pause to think about it, I would be tempted by the somewhat
provocative but sincere feeling that checking for the
engine is not that of a good idea. It would perhaps
if only *one* engine was proposed as candidate, but if one has
to choose between luatex and xetex, that's not much
speed gain compared to doing it beforehand, or
being confronted with a botched pdflatex compilation and
doing it then.
Recently I read a bit of XeTeX doc, and it is perfectly
possible to use it without fontspec package.
I find it a bit surprising to tie discovery of XeTeX/LuateX
to use of fontspec package.
Why not rather a file variable at top of file ? Yes, user will
have thus to put something explicit there, but isn't it actually
better if the file is destined to be exchanged with other people
possibly not using Emacs/AUCTeX ?
This raises maintenance issues on your side as
you must keep an eye on what fontspec will become
in the future, and also on what future engines
might arise etc...
Well, in style/ directory we have 196 files that raise lots of
maintenance issues, so we are used to them ;-) We do our best to keep
them updated, and we seek for other people helping us.
My defense is now going to become pathetic, but this is time to
reveal that in my practice of auctex I surely underuse by a
factor 1000 the goodies which might come from whatever is in
style/
I must examine that
I'm closing this ticket.
ok
bye,
Jean-François
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
bug#21832: 11.88.8; prompt for using LuaTeX/XeTeX engine
2015-11-04 23:50 GMT+01:00 jfbu :
>> Do you have other suggestions? They're welcome :-)
>
>
> I don't at this time ... I was surprised by the prompt
> for XeTeX/LuaTeX (which in my use case was wrong, but
> certainly that was very specific context), and if I had
> to pause to think about it, I would be tempted by the somewhat
> provocative but sincere feeling that checking for the
> engine is not that of a good idea. It would perhaps
> if only *one* engine was proposed as candidate
fontspec requires two engines, we can't select one of the two for the
user. The point is that compilation will certainly fail if one loads
particular packages, provided that there aren't conditionals. A
prompt suggesting you the action to take is better than waiting for
the compilation to finish and then try to realize what went wrong.
> but if one has
> to choose between luatex and xetex, that's not much
> speed gain compared to doing it beforehand, or
> being confronted with a botched pdflatex compilation and
> doing it then.
>
> Recently I read a bit of XeTeX doc, and it is perfectly
> possible to use it without fontspec package.
Indeed the problem is the other way round: you can't use fontspec
without {Xe,Lua}TeX.
> I find it a bit surprising to tie discovery of XeTeX/LuateX
> to use of fontspec package.
>
> Why not rather a file variable at top of file ? Yes, user will
> have thus to put something explicit there, but isn't it actually
> better if the file is destined to be exchanged with other people
> possibly not using Emacs/AUCTeX ?
We already have a file-local variable to specify the engine to use,
`TeX-engine', the check is only for those who forget to set it
properly.
Cheers,
Mosè
___
bug-auctex mailing list
bug-auctex@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-auctex
