Emacs + AUCTeX + cœur LaTeX + MiKTeX + Nom de fichier avec caractères accentués

[vincent....@gmail.com]

Bonjour,

Récemment je suis tombé sur un problème que je n'avais pas avant.

Voilà la chose : lorsque j’essaie de compiler un document comprenant une
lettre accentuée, par exemple liberté.tex ça ne marche plus.

Je réfute d'avance la réponse qui serait d'écrire liberte au lieu de
liberté, je ne connais pas plus Liberte qu'Alberte, et c'est juste une
question de choix, je préfère la tracasserie de tomber de temps en temps
dans ce genre de nid de poule en utilisant des lettres accentuées dans
les noms de fichier à celle consistant à écrire les noms de fichiers
sans accents, en franquais plutôt qu'en français.

J'utilise AUCTeX sur MiKTeX, mais j'ignore si le souci vient du portage
de pdflatex que fait MiKTeX ou bien du cœur LaTeX. À moins que ce soit
une mise à jour d'Emacs qui change le comportement d'AUCTeX.

En regardant en détail ce qui se passe, AUCTeX ne fait que appeler la
commande

pdflatex \input liberté.tex

(avec quelques guillemets que je supprime ici parce que les guillemets
ne sont pas les mêmes en DOS et en Unix, et que ce n'est pas le problème
ici).

Cette commande échoue parce que liberté y est interprété comme du code
LaTeX et que le é va donc donner autre chose que la suite des deux octets
C3 A9 en hexa.

Il m'a suffit pour corriger le problème de bidouiller AUCTeX pour qu'il
appelle

pdflatex liberté.tex


Pour que ça passe. Dans ce cas pdflatex interprète liberté.tex comme un
nom de fichier.

Au cas où d'autres tomberaient dans le même problème voici ce que j'ai
dû faire sous AUCTeX — la modif n'était pas si triviale, alors je la
donne — dans mon fichier d'init j'ai défini cette fonction:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
(defun my-latex-input-expander ()
(prog1
(if
(stringp TeX-command-text)
(progn
(setq TeX-command-pos
(and
(string-match " "
(funcall file t t))
"\"")))
(setq TeX-command-pos nil)
"")
(setq TeX-command-text nil)))
--8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8----

Et ensuite j'ai customisé TeX-expand-list pour que ça vaille

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
'(("%'" vbl-latex-input-expander))
--8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8----

Voici ce que ça donne dans le tampon de customisation :

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----
Hide Tex Expand List:
INS DEL Key: %'
Expander: vbl-latex-input-expander
Arguments:
INS
INS
State : SAVED and set.
--8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8----

Enfin bref, ça a résolu mon problème, mais j'écris ici pour savoir si
quelqu'un connais le changement qui l'a produit :

- Est-ce un changement du cœur LaTeX (\input ne se comportant plus comme
avant)

- Est-ce un changement d'Emacs — ma version :

GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of 2018-08-10

je suspecte qu'il faisait une conversion utf-8 → windows-1252 dans
les versions précédente, ce qu'en tout cas visiblement il ne fait pas
dans ma version actuelle.

- Est-ce un changement dans le moteur pdflatex de MiKTeX

- Est-ce un changement dans AUCTeX (j'en doute, je n'ai pas remis à jour
depuis très longtemps).

J'ai tendance à penser que c'est Emacs qui a changé car c'est le truc
que j'ai remis à jour le plus récemment.

V.

[vincent....@gmail.com]

vincent....@gmail.com writes:

> Bonjour,
>
> Récemment je suis tombé sur un problème que je n'avais pas avant.
>

[...]

>
> Enfin bref, ça a résolu mon problème, mais j'écris ici pour savoir si
> quelqu'un connais le changement qui l'a produit :
>
> - Est-ce un changement du cœur LaTeX (\input ne se comportant plus comme
> avant)
>
> - Est-ce un changement d'Emacs — ma version :
>
> GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of 2018-08-10
>
> je suspecte qu'il faisait une conversion utf-8 → windows-1252 dans
> les versions précédente, ce qu'en tout cas visiblement il ne fait pas
> dans ma version actuelle.
>
> - Est-ce un changement dans le moteur pdflatex de MiKTeX
>
> - Est-ce un changement dans AUCTeX (j'en doute, je n'ai pas remis à jour
> depuis très longtemps).
>
> J'ai tendance à penser que c'est Emacs qui a changé car c'est le truc
> que j'ai remis à jour le plus récemment.
>
> V.

Je me réponds à moi même pour dire que ça ne vient pas d'Emacs. Je viens
de trouver une vieille (GNU Emacs 26.0.50 (build 1, i686-pc-mingw32) of
2017-06-29) version d'Emacs — la plus vieille que j'ai pu trouver sur ma
machine, et il y a exactement le même problème.

Sans ma customisation d'AUCTeX ça fait cela:

--8<----8<----8<----8<----8<-- begin -->8---->8---->8---->8---->8----

Running `LaTeX' on `liberté' with ``pdflatex -file-line-error -interaction=nonstopmode "\input" "liberté.tex"''
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (MiKTeX 2.9.6745 64-bit)
entering extended mode
LaTeX2e <2018-04-01> patch level 5
???:0: I can't find file `libert'.
<to be read again>
\global
<*> \input liberté
.tex
Please type another input file name
???:0: Emergency stop
???:0: ==> Fatal error occurred, no output PDF file produced!
Transcript written on texput.log.

TeX Output exited abnormally with code 1 at Fri Sep 28 06:34:53

--8<----8<----8<----8<----8<-- end -->8---->8---->8---->8---->8----

V.

[vincent....@gmail.com]

vincent....@gmail.com writes:

> vincent....@gmail.com writes:
>
>> Bonjour,
>>
>> Récemment je suis tombé sur un problème que je n'avais pas avant.
>>
>
> [...]
>
>>
>> Enfin bref, ça a résolu mon problème, mais j'écris ici pour savoir si
>> quelqu'un connais le changement qui l'a produit :
>>
>> - Est-ce un changement du cœur LaTeX (\input ne se comportant plus comme
>> avant)
>>
>> - Est-ce un changement d'Emacs — ma version :
>>
>> GNU Emacs 27.0.50 (build 1, x86_64-w64-mingw32) of 2018-08-10
>>
>> je suspecte qu'il faisait une conversion utf-8 → windows-1252 dans
>> les versions précédente, ce qu'en tout cas visiblement il ne fait pas
>> dans ma version actuelle.
>>
>> - Est-ce un changement dans le moteur pdflatex de MiKTeX
>>
>> - Est-ce un changement dans AUCTeX (j'en doute, je n'ai pas remis à jour
>> depuis très longtemps).
>>
>> J'ai tendance à penser que c'est Emacs qui a changé car c'est le truc
>> que j'ai remis à jour le plus récemment.
>>
>> V.
>
> Je me réponds à moi même pour dire que ça ne vient pas d'Emacs.

[...]

> V.

Je me demande si ça ne serait pas une mise à jour MSWindows qui aurait
causé ce changement de comportement. Je suspecte/spécule que petit à
petit MSWindows migre vers l'UTF-8 pour les appel système, ce qui serait
une bonne chose. Qq un est-il au courant de cela ?

V.

[Jean-Yves Baudais]

Bonjour,

Le 28/09/2018 à 06:40, vincent....@gmail.com a écrit :
> [...]

> Running `LaTeX' on `liberté' with ``pdflatex -file-line-error -interaction=nonstopmode "\input" "liberté.tex"''
> This is pdfTeX, Version 3.14159265-2.6-1.40.19 (MiKTeX 2.9.6745 64-bit)
> entering extended mode
> LaTeX2e <2018-04-01> patch level 5
> ???:0: I can't find file `libert'.
> <to be read again>
> \global
> <*> \input liberté
> .tex

> [...]


J'imagine que MiKTeX ouvre un shell (ou un sous-shell) pour exécuter
la commande. Non ? Et la variable LANG de ce shell là, ou de ce Chelsea
(heu... désolé c'est vendredi), n'est pas UTF8... C'est pas un truc
comme ça ? Comme je comprends rien au Lisp, je suis incapable de lire
votre code pour savoir si c'est une conversion d'encodage que fait
AUCTeX pour exécuter la commande !

Jean-Yves

--
Il y a une précédence des arborescences les unes sur les autres en
fonction de leur ordre d'apparition dans $TEXMF, des inconscients
comme Joss s'amusent à jongler avec ça.
-+- JKr in fr.comp.text.tex -+-

[jfbu]

Le 28/09/2018 à 08:16, Jean-Yves Baudais a écrit :
> Bonjour,
>
> Le 28/09/2018 à 06:40, vincent....@gmail.com a écrit :
>> [...]
>> Running `LaTeX' on `liberté' with ``pdflatex  -file-line-error   -interaction=nonstopmode "\input" "liberté.tex"''
>> This is pdfTeX, Version 3.14159265-2.6-1.40.19 (MiKTeX 2.9.6745 64-bit)
>> entering extended mode
>> LaTeX2e <2018-04-01> patch level 5
>> ???:0: I can't find file `libert'.
>> <to be read again>
>>                     \global
>> <*> \input liberté
>>                     .tex
>> [...]
>
>
>   J'imagine que  MiKTeX ouvre un shell (ou un sous-shell) pour exécuter la commande. Non ? Et la variable LANG de ce shell là, ou de ce Chelsea (heu... désolé c'est vendredi), n'est pas UTF8... C'est pas un truc comme ça ? Comme je comprends rien au Lisp, je suis incapable de lire votre code pour savoir si c'est une conversion d'encodage que fait AUCTeX pour exécuter la commande !
>
>   Jean-Yves
>

Bonjour,

Est-ce qu'il ne s'agirait pas tout simplement du problème évoqué dans ce message

https://lists.gnu.org/archive/html/auctex/2018-05/msg00003.html

et les suivants.

(Je soupçonne que oui à cause de la version de LaTeX: LaTeX2e <2018-04-01> patch level 5,
avez-vous mis-à-jour le format LaTeX récemment?)

La version de développement de AUCTeX a réglé le problème (et d'autres) depuis,

Apparemment cependant il n'y a pas eu de "Release" depuis.
Mais comme ma copie de .emacs.d/elpa/auctex-12.1.1 est modifiée
pour incorporer les patchs je n'ai pas trop suivi si auctex
avait de nouvelles versions,

Jean-François

[Ulrike Fischer]

Am Fri, 28 Sep 2018 06:31:28 +0200 schrieb
vincent....@gmail.com:

> Voilà la chose : lorsque j’essaie de compiler un document comprenant une
> lettre accentuée, par exemple liberté.tex ça ne marche plus.

- Est-ce un changement du cœur LaTeX

Oui, tres probablement ca: utf8 est maintainent le default dans
LaTeX et activé directement.

> Je réfute d'avance la réponse qui serait d'écrire liberte au lieu de
> liberté, je ne connais pas plus Liberte qu'Alberte, et c'est juste une
> question de choix, je préfère la tracasserie de tomber de temps en temps
> dans ce genre de nid de poule en utilisant des lettres accentuées dans
> les noms de fichier à celle consistant à écrire les noms de fichiers
> sans accents, en franquais plutôt qu'en français.

Mais ca veux dire que tu expectes que les autres passent leur temps
à te tirer de ton nid. Tu expectes que les maintainer de miktex,
auctex, emacs, latex, graphics etc trouvent et debug des solutions
pour manipuler des fichiers avec des noms en non-ascii pour des tas
de applications d'age differente sur des tas de versions de windows,
linux, mac.


--
Ulrike Fischer
https://www.troubleshooting-tex.de/

[jfbu]

J'ai oublié de dire que

https://tex.stackexchange.com/a/429886/4686

indique une échappatoire qui est sans doute plus
simple que d'incorporer soi-même à son propre auctex 12.1.1
le ou plutôt les patchs dont l'un a été indiqué par Arash sur l'autre groupe
auctex.gnu.org

http://git.savannah.gnu.org/cgit/auctex.git/commit/?id=a8ea1273fd95da5702fe95ad3f41d151b621bc72

(en particulier il y a en plus de celui-là des patchs pour le mode preview)

Cordialement,

Jean-François

[vincent....@gmail.com]

Ulrike Fischer <ne...@nililand.de> writes:

> Am Fri, 28 Sep 2018 06:31:28 +0200 schrieb
> vincent....@gmail.com:
>
>
>> Voilà la chose : lorsque j’essaie de compiler un document comprenant une
>> lettre accentuée, par exemple liberté.tex ça ne marche plus.
>
> - Est-ce un changement du cœur LaTeX
>
> Oui, tres probablement ca: utf8 est maintainent le default dans
> LaTeX et activé directement.
>

Ah, OK, tu veux dire dans les moteurs xxxTeX (pdflatax, xelatex,
lualatex) ? ou bien un changement dans le cœur LaTeX (c.-à-d. définition
de la commande \input) ?

>
>> Je réfute d'avance la réponse qui serait d'écrire liberte au lieu de
>> liberté, je ne connais pas plus Liberte qu'Alberte, et c'est juste une
>> question de choix, je préfère la tracasserie de tomber de temps en temps
>> dans ce genre de nid de poule en utilisant des lettres accentuées dans
>> les noms de fichier à celle consistant à écrire les noms de fichiers
>> sans accents, en franquais plutôt qu'en français.
>
> Mais ca veux dire que tu expectes que les autres passent leur temps
> à te tirer de ton nid.

Non bien sûr je n'attends pas que les mainteneurs de tels ou tels
paquetages passent leur temps à résoudre mes problèmes : la preuve c'est
que j'ai trouvé tout seul une solution qui répondait à mon problème
immédiat, et que mon but était avant tout de la partager et donc plutôt
d'aider autrui que de chercher de l'aide — quoique bien sûr j'essaie de
comprendre ce qui a changé et où va le monde…

Ceci dit, ce n'est pas *mon* nid de poule, mais aussi le tien : que je
sache la langue allemande ne se contente pas de l'ASCII, vous avez
besoin notamment de ü ä et ß … pareil pour les Polonais, les Tchèques,
les Japonais, etc., etc. enfin bref presque tout le monde …

> Tu expectes que les maintainer de miktex,
> auctex, emacs, latex, graphics etc trouvent et debug des solutions
> pour manipuler des fichiers avec des noms en non-ascii pour des tas
> de applications d'age differente sur des tas de versions de windows,
> linux, mac.

Je trouve très dommage que les outils de la famille TeX soient si en
retard sur ces questions, alors que ça ne pose aucun problème à des
outils du genre MSWord — même s'il y a des problèmes aussi avec la suite
MSOffice, par ex. le code des macros VBA est en 8-bit du coup ce n'est
pas portable entre MSWindows et MACOS.

Je trouve que ces limitations donnent l'image que LaTeX c'est uniquement
pour des informaticiens, et que cette image est dommageable à la
communauté des utilisateurs. Je trouve plus généralement que la
diversité des langues, comme toute diversité du vivant, est une richesse
qu'il faut absolument préserver de la destruction et d'un
appauvrissement mental qui nous mène au totalitarisme.

Je suis tout à fait conscient que ce n'est pas si simple, par
ex. latexmk est dépendant de ce que perl fait, et pour la compilation
DVI → PS → PDF on est tributaire des scripts Ghostscript qui ont des
limitation. Mais au moins tant qu'on fait tout avec pdflatex/xelatex ça
ne marche pas trop mal.

En tout cas, (voir ma réponse sur les listes de diffusion AUCTeX/MiKTeX)
selon moi la réponse définitive à ce genre de problème n'est pas de
bidouiller des lignes de commande de plus en plus complexe avec des
\detokenize, des \string~ ou \string##, etc…

Je pense que la racine du mal c'est le format même de la ligne de
commande des moteurs TeX : le fait que ce soit basé sur une euristique
et qu'on ne peut pas explicitement indiquer ce qui est du code TeX, et
ce qui est un nom de fichier. En plus ce n'est pas conforme à POSIX
comme format.

Si on pouvait indiquer un truc de ce genre :

pdflatex --eval \input --file liberté.tex

où l'argument suivant l'option --eval serait considéré comme du code TeX,
et l'argument suivant --file comme un nom de fichier (donc une suite de
lettre ou other, c.-à-d. catcode 12 ou 11), ça simplifierait grandement
l'utilisation de nom de fichier quelconque, et ça augmenterait
considérablement la portabilité des moteurs TeX.

Vincent.

[vincent....@gmail.com]

jfbu <NONj...@SPfreeAM.fr> writes:

> Le 28/09/2018 à 08:16, Jean-Yves Baudais a écrit :
>> Bonjour,
>>

[...]

>>
>
> Bonjour,
>
> Est-ce qu'il ne s'agirait pas tout simplement du problème évoqué dans ce message
>
> https://lists.gnu.org/archive/html/auctex/2018-05/msg00003.html
>
> et les suivants.
>
> (Je soupçonne que oui à cause de la version de LaTeX: LaTeX2e <2018-04-01> patch level 5,
> avez-vous mis-à-jour le format LaTeX récemment?)

Voici ma version :

$ pdflatex --version
MiKTeX-pdfTeX 2.9.6668 (1.40.19) (MiKTeX 2.9.6745 64-bit)
Copyright (C) 1982 D. E. Knuth, (C) 1996-2018 Han The Thanh
TeX is a trademark of the American Mathematical Society.
using bzip2 version 1.0.6, 6-Sept-2010
compiled with curl version 7.56.1; using libcurl/7.56.1 WinSSL
compiled with expat version 2.2; using expat_2.2.0
compiled with jpeg version 9.2
compiled with liblzma version 50020032; using 50020032
compiled with libpng version 1.6.34; using 1.6.34
compiled with libressl version LibreSSL 2.5.3; using LibreSSL 2.5.3
compiled with MiKTeX Application Framework version 2.6636; using 2.6636
compiled with MiKTeX Core version 7.6745; using 7.6778
compiled with MiKTeX Archive Extractor version 1.6300; using 1.6300
compiled with MiKTeX Package Manager version 3.6727; using 3.6727
compiled with poppler version 0.60.1
compiled with uriparser version 0.8.4
compiled with zlib version 1.2.11; using 1.2.11

>
> La version de développement de AUCTeX a réglé le problème (et
> d'autres) depuis,

Oui, je viens de re-installer AUCTeX à partir de Git, et le \input n'est
plus là, en lisant le fil que vous donnez plus haut je comprends que le
\input servait à prendre en charge l'insertion de code LaTeX dans la
ligne (du genre \PassOptionsToPacakge ou \includeonly).

M'enfin bref… comme je l'ai repondu à Ulrike, pour moi la racine du mal
c'est les limitations du format de la ligne de commande des moteurs TeX,
c'est une chose dont j'ai déjà discuté avec les mainteneurs de latexmk
ou de texi2dvi pour des problème du même tonneau.

>
> Apparemment cependant il n'y a pas eu de "Release" depuis.
> Mais comme ma copie de .emacs.d/elpa/auctex-12.1.1 est modifiée
> pour incorporer les patchs je n'ai pas trop suivi si auctex
> avait de nouvelles versions,
>
> Jean-François

Moi non plus, j'ai installé la version de dev sans trop me poser que
question, comme à chaque fois que je tombe sur un truc qui me semble
être une anomalie, même si là franchement AUCTeX n'y est pas pour grand
chose, c'est plutôt une limitation de format de ligne de commande…

Vincent.

[jfbu]

Merci Vincent,

mais je faisais référence au format LaTeX,

cf https://www.latex-project.org/news/latex2e-news/

https://www.latex-project.org/news/latex2e-news/ltnews28.pdf

UTF-8: the new default input encoding

car le problème vient du fait que inputenc+utf-8 est actif (sic)
par défaut dorénavant avec pdflatex

>
>
>>
>> La version de développement de AUCTeX a réglé le problème (et
>> d'autres) depuis,
>
>
> Oui, je viens de re-installer AUCTeX à partir de Git, et le \input n'est
> plus là, en lisant le fil que vous donnez plus haut je comprends que le
> \input servait à prendre en charge l'insertion de code LaTeX dans la
> ligne (du genre \PassOptionsToPacakge ou \includeonly).
>
> M'enfin bref… comme je l'ai repondu à Ulrike, pour moi la racine du mal
> c'est les limitations du format de la ligne de commande des moteurs TeX,
> c'est une chose dont j'ai déjà discuté avec les mainteneurs de latexmk
> ou de texi2dvi pour des problème du même tonneau.

on peut faire des choses surprenantes comme avoir des fichiers
avec plusieurs caractères espaces consécutifs, mais il faut un peu de bidouille

>
>>
>> Apparemment cependant il n'y a pas eu de "Release" depuis.
>> Mais comme ma copie de .emacs.d/elpa/auctex-12.1.1 est modifiée
>> pour incorporer les patchs je n'ai pas trop suivi si auctex
>> avait de nouvelles versions,
>>
>> Jean-François
>
>
> Moi non plus, j'ai installé la version de dev sans trop me poser que
> question, comme à chaque fois que je tombe sur un truc qui me semble
> être une anomalie, même si là franchement AUCTeX n'y est pas pour grand
> chose, c'est plutôt une limitation de format de ligne de commande…
>
> Vincent.
>

Voici le mécanisme (qui m'est un peu revenu depuis votre premier message):

le format LaTeX pour pdftex ajoute l'interprétation "à la inputenc+utf8"
à \everyjob

2018-04-08 ltnal.dtx v2.1d
General: Delay full UTF-8 handling to \everyjob

Cet \everyjob est exécuté par TeX à un certain moment dont j'ai oublié
la description précise, mais qui dans la pratique correspond au moment
de la première macro ou primitive rencontrée, par exemple \input

Donc si on fait

pdflatex liberté.tex

le fichier liberté.tex est trouvé par TeX **avant** l'exécution de \everyjob

mais si on fait (ici avec de l'échappement pour un shell unix)

pdflatex \\def\\foo{foo} \\input liberté.tex

ou même seulement

pdflatex \\input liberté.tex

le code dans \everyjob est exécuté **avant** le \input
et dorénavant "é" qui tient sur plusieurs
octets en UTF-8 a son premier octet actif, et va subir l'expansion.

Au final cela donne une erreur.

LaTeX2e <2018-04-01> patch level 5

! I can't find file `libert'.

tandis que

pdflatex \\input \\detokenize{liberté.tex}

n'a pas de problème.

Bien sûr dans ce cas on préfère

pdflatex liberté.tex

et c'est bien ce que le AUCTeX de développement fait dorénavant, par défaut.

Sinon, dans les cas avec un \input ou autre, il utilisera le \detokenize.


Jean-François

[Ulrike Fischer]

Am Sun, 30 Sep 2018 22:24:09 +0200 schrieb
vincent....@gmail.com:

>> Oui, tres probablement ca: utf8 est maintainent le default dans
>> LaTeX et activé directement.
>>
>
> Ah, OK, tu veux dire dans les moteurs xxxTeX (pdflatax, xelatex,
> lualatex) ? ou bien un changement dans le cœur LaTeX (c.-à-d. définition
> de la commande \input) ?

coeur latex avec pdflatex.

\documentclass{article}
\usepackage[T1]{fontenc}
\begin{document}
liberté
\end{document

> Ceci dit, ce n'est pas *mon* nid de poule, mais aussi le tien : que je
> sache la langue allemande ne se contente pas de l'ASCII, vous avez
> besoin notamment de ü ä et ß

Non, ce n'est pas mon nid. Je n'utilise jamais des ü ou ä ou des
espcaces dans des noms de fichiers.

> Je trouve très dommage que les outils de la famille TeX soient si en
> retard sur ces questions, alors que ça ne pose aucun problème à des
> outils du genre MSWord — même s'il y a des problèmes aussi avec la suite
> MSOffice, par ex. le code des macros VBA est en 8-bit du coup ce n'est
> pas portable entre MSWindows et MACOS.

Exactement. C'est simple pour une application sur un OS, mais comme
tex doit marcher et echanger entre windows, macos, linux, ... c'est
difficile.

> Je trouve que ces limitations donnent l'image que LaTeX c'est uniquement
> pour des informaticiens, et que cette image est dommageable à la
> communauté des utilisateurs. Je trouve plus généralement que la
> diversité des langues, comme toute diversité du vivant, est une richesse
> qu'il faut absolument préserver de la destruction et d'un
> appauvrissement mental qui nous mène au totalitarisme.

Le problème *est* la diversité. Si tout le monde utilisait le même
OS et le même tex systeme et le même editeur et le même encodage etc
ce serait simple.

Mais tant qu'il y a des differences et la diversité il faut accepter
que ca demande de compromiser. Quand je fais un voyage j'utilise des
connecteurs standard et ne demande pas que les connecteurs specials
allemands fonctionnent partout.


--
Ulrike Fischer
http://www.troubleshooting-tex.de/

[jfbu]

Le 30/09/2018 à 23:27, jfbu a écrit :
> Donc si on fait
>
> pdflatex liberté.tex
>
> le fichier liberté.tex est trouvé par TeX **avant** l'exécution de \everyjob

Je ne veux bien sûr pas dire par là que le contenu de liberté.tex est trouvé avant l'exécution de \everyjob. Mais que le flux d'entrée en lecture de liberté.tex est ouvert par TeX avant l'exécution de \everyjob, donc à un moment où les octets composant liberté.tex ne sont pas rendus encore actifs.

Pour un autre exemple on peut essayer avec ~.

Dans ce cas

pdflatex temp~.tex

échoue car ~ est actif **avant même** \everyjob.


$ pdflatex temp~.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
! I can't find file `temp'.
<to be read again>
\protect
<*> temp~
.tex
(Press Enter to retry, or Control-D to exit)


C'est pour éviter cela que le LaTeX de 2018 qui fait inputenc+utf8 par défaut pour le moteur pdftex attend \everyjob pour cela.

Cependant comme on l'on vu \input provoque l'exécution de \everyjob avant même que TeX n'ait vu le nom du fichier.

D'où votre problème initial car pour des raisons "historiques" AUCTeX utilisait la forme avec \input par défaut.

Jean-François

[vincent....@gmail.com]

Ulrike Fischer <ne...@nililand.de> writes:

> Am Sun, 30 Sep 2018 22:24:09 +0200 schrieb
> vincent....@gmail.com:
>
>>> Oui, tres probablement ca: utf8 est maintainent le default dans
>>> LaTeX et activé directement.
>>>
>>
>> Ah, OK, tu veux dire dans les moteurs xxxTeX (pdflatax, xelatex,
>> lualatex) ? ou bien un changement dans le cœur LaTeX (c.-à-d. définition
>> de la commande \input) ?
>
> coeur latex avec pdflatex.
>
> \documentclass{article}
> \usepackage[T1]{fontenc}
> \begin{document}
> liberté
> \end{document
>
>

OK, je comprends. C'est très intéressant, est-ce que ça veut dire qu'on
peut écrire un paquetage pour LaTeX en utilisant l'UTF-8. Je pose la
question parce que en ce moment je m'interesse avec un contributeur à
faire fmtcount en arabe.

Si utf-8 devient le codage par défaut dans pdflatex, alors ça suggère
que l'obligation de coder les paquetage en ASCII seulement est revue à
la baisse pour peu qu'on encapsulerait le texte utf-8 dans une sorte de
\ensureUTFviii{…}.

>
>> Ceci dit, ce n'est pas *mon* nid de poule, mais aussi le tien : que je
>> sache la langue allemande ne se contente pas de l'ASCII, vous avez
>> besoin notamment de ü ä et ß
>
> Non, ce n'est pas mon nid. Je n'utilise jamais des ü ou ä ou des
> espcaces dans des noms de fichiers.

Je n'utilise jamais d'espace non plus, ni de ' ou ", mais par contre je
ne vois pas au nom de quoi des autres caractères comme l'espace
insécable (U+A0) ou l'apostrophe ’ (U+2019), ou encore le signe de
division ∕ (U+2215) seraient interdits.

Les versions modernes de MSWindows, MACOS et Linux prennent en charge
l'Unicode, c'est donc, au niveau des OS du moins, compatible. Donc je ne
vois pas vraiment pourquoi, s'il y a des problèmes, ne pas les résoudre.

>
>
>> Je trouve très dommage que les outils de la famille TeX soient si en
>> retard sur ces questions, alors que ça ne pose aucun problème à des
>> outils du genre MSWord — même s'il y a des problèmes aussi avec la suite
>> MSOffice, par ex. le code des macros VBA est en 8-bit du coup ce n'est
>> pas portable entre MSWindows et MACOS.
>
> Exactement. C'est simple pour une application sur un OS, mais comme
> tex doit marcher et echanger entre windows, macos, linux, ... c'est
> difficile.
>

Et donc il ne faut pas le faire ? bon je vais me coucher alors, ça sera
plus simple comme ça … :-)

>
>> Je trouve que ces limitations donnent l'image que LaTeX c'est uniquement
>> pour des informaticiens, et que cette image est dommageable à la
>> communauté des utilisateurs. Je trouve plus généralement que la
>> diversité des langues, comme toute diversité du vivant, est une richesse
>> qu'il faut absolument préserver de la destruction et d'un
>> appauvrissement mental qui nous mène au totalitarisme.
>
> Le problème *est* la diversité. Si tout le monde utilisait le même
> OS et le même tex systeme et le même editeur et le même encodage etc
> ce serait simple.
>
> Mais tant qu'il y a des differences et la diversité il faut accepter
> que ca demande de compromiser.

Oui, et le compromis a déjà été trouvé, ça s'appelle Unicode, et ça
oblige à coder é ou ù sur deux caractères au lieu d'un en Latin-9. C'est
bien un compromis, parce qu'honnêtement lorsque je fais un truc juste
pour moi même je le fais en latin-9, mais bon je l'accepte volontier au
nom de l'universalité.

> Quand je fais un voyage j'utilise des connecteurs standard et ne
> demande pas que les connecteurs specials allemands fonctionnent
> partout.

Il y a encore plus simple : ne pas voyager. :-) Sinon, il y a quand même
plein de pays où les fiches Schuko (Schutzkontakt, natürlich) marchent,
par exemple en France ;-).

V.

PS : Je sens que la discussion vire au troll, visiblement nous ne sommes
pas d'accord, et donc ça ne sert à rien de discuter sur la
motivation. Le principe du logiciel libre, c'est justement qu'on
est libre, notamment de ne pas tous utiliser exactement la même
chose, la même langue ou de penser la même chose, de faire le
Frexit, ou le Deutchmain, etc …

Merci en tout cas pour ta réponse ! et vive la Liberté !