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