N'empêche que cette façon d'emacs de ne pas savoir
reconnaitre un jeu d'encodage (le seul logiciel que je connaisse dans
ce cas) ne me rassure guère.
Faut pas. On peut tout faire avec Emacs et on peut le modifier comme on
veut, avec le risque de mal le paramétrer.
Il faut dire qu'à ses débuts il y a environ 30 ans, il n'avait pas
autant d'encodages à manipuler. Au fil du temps leur support a été
ajouté avec plus ou moins de bonheur. Dans l'avenir avec l'utilisation
d'unicode ces problèmes devraient disparaître.
Mais même avec les éditeurs de win, tu as déjà ouvert un fichier "de
l'époque du dos" (càd non encodé en ansi de windows) avec notepad ? Il y
a les mêmes problèmes avec les accents (page de code 437 vs. 850).
Ok, je note ces indications. Inutiles de (mal) redéclarer ce qui
l'a déjà été par set-language-environment. Seulement entre
iso-8859-1-dos et iso-8859-1, il n'y a pas de différence cruciales
?
Pas de différence de codage de caractères. Le suffixe -dos indique
qu'avec cet encodage il va utiliser le retour à la ligne "dos" soit
cr+lf. Il existe le même encodage avec -unix (lf / 13) et -mac (cr / 10)
suivant la plateforme d'origine ou de destination du document à éditer.
> Tu peux tenter de le rouvrir en changeant de coding-system par C-x
> RET c avant de faire le C-x C-f et d'utiliser latin-1, latin-9 ou
> utf-8. Ça pourrait permettre de récupérer ton fichier.
J'avais essayer en précisant l'encodage avec C-x RET f sur le
fichier ouvert, est-ce la même chose ?
C-x RET f indique l'encodage à utiliser si possible pour le prochain
enregistrement et les suivants. Il ne modifie pas l'encodage courant.
Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)
- le spécifier avant l'ouverture C-x RET c codage C-x C-f
- réouvrir le fichier avec C-x RET r codage (marche mal sur mon mac)
Ensuite, j'ouvre un buffer, le « à » ne suscite pas de protestation,
mais *juste après* le « é » me vaut un buffer pop-up et une invitation
à préférer l'utf-8 sur l'iso-8859-1.
Tu n'as rien constaté de bizarre avec describe-coding-system à ce
moment ? Il doit y avoir un désaccord entre l'encodage du buffer et
celui du clavier.Je ferme et rouvre emacs. Cette fois-ci le « é » passe. M-x
describe-coding-system : on est bien en iso-latin-1.
Je ferme et re-ouvre emacs. j'ouvre ~/.emacs. C-h C donne
iso-latin-1-dos (pourquoi ? Je ne demande plus de dos).
Parce que les sauts de lignes déjà enregistrés sont au format dos ?
Emacs essaie de deviner quand c'est possible l'encodage d'un fichier à
l'ouverture. Parfois il se trompe (ex: distinguer latin-1 du latin-9
s'il n'y a pas d'euro ou de caractère spécifique latin-9).Je rouvre un nouveau fichier en mode Text. Cette fois le à (première
lettre accentuée) ne passe plus, alors qu'elle passait tout à l'heure,
et les pop-up me proposent de remplacer l'iso-latin-1 (seul encodage
testé cette fois), par... du koi8-r, seigneur !
J'ai eu ce genre de soucis au début pour configurer emacs/gnus pour
manipuler correctement générer par défaut du latin-9 sur un mac alors
que l'encodage par défaut du système est mac-roman... On y arrive :)> et peut-être aussi comment tes caractères accentués sont vus par
> emacs : C-u C-x = sur le caractère t'affichera des informations très
> utiles.
Sur le « à » qui cause des problèmes juste au dessus :
----
character: à (04340, 2272, 0x8e0)
charset: latin-iso8859-1
[...]
file code: E0 (encoded by coding system iso-latin-1)
Donc le caractère est bien en latin-1 ou iso-8859-1 maintenant il faut
vérifier le reste (buffer / clavier).Ce que je trouve particulièrement savoureux c'est qu'il me range mon «
à » dans « latin-iso8859-1 », mais qu'il refuse d'utiliser ce charset
pour l'encoder (cela dit le C-x C-s après le C-u C-x = est passé, donc
peut être que c'était déjà réglé. J'ai voulu répéter toute
l'expérience (tantôt le à passe, tantôt non, toujours dans un buffer
en mode texte ouvert après l'ouverture / fermeture du .emacs, qui est
toujours reconnu comme du iso-8859-1-dos), et le à est bien toujours
classé comme du latin-1, même quand juste après il n'arrive pa sà
l'encoder.
Le problème vient peut-être d'un autre caractère qu'il ne sait pas
sauver en latin-1 ? Normalement quand il te demande un encodage
alternatif au moment de l'enregistrement, il te précise les caractères
qui lui posent problème.
N'empêche que cette façon d'emacs de ne pas savoir
reconnaitre un jeu d'encodage (le seul logiciel que je connaisse dans
ce cas) ne me rassure guère.
Faut pas. On peut tout faire avec Emacs et on peut le modifier comme on
veut, avec le risque de mal le paramétrer.
Il faut dire qu'à ses débuts il y a environ 30 ans, il n'avait pas
autant d'encodages à manipuler. Au fil du temps leur support a été
ajouté avec plus ou moins de bonheur. Dans l'avenir avec l'utilisation
d'unicode ces problèmes devraient disparaître.
Mais même avec les éditeurs de win, tu as déjà ouvert un fichier "de
l'époque du dos" (càd non encodé en ansi de windows) avec notepad ? Il y
a les mêmes problèmes avec les accents (page de code 437 vs. 850).
Ok, je note ces indications. Inutiles de (mal) redéclarer ce qui
l'a déjà été par set-language-environment. Seulement entre
iso-8859-1-dos et iso-8859-1, il n'y a pas de différence cruciales
?
Pas de différence de codage de caractères. Le suffixe -dos indique
qu'avec cet encodage il va utiliser le retour à la ligne "dos" soit
cr+lf. Il existe le même encodage avec -unix (lf / 13) et -mac (cr / 10)
suivant la plateforme d'origine ou de destination du document à éditer.
> Tu peux tenter de le rouvrir en changeant de coding-system par C-x
> RET c avant de faire le C-x C-f et d'utiliser latin-1, latin-9 ou
> utf-8. Ça pourrait permettre de récupérer ton fichier.
J'avais essayer en précisant l'encodage avec C-x RET f sur le
fichier ouvert, est-ce la même chose ?
C-x RET f indique l'encodage à utiliser si possible pour le prochain
enregistrement et les suivants. Il ne modifie pas l'encodage courant.
Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)
- le spécifier avant l'ouverture C-x RET c codage C-x C-f
- réouvrir le fichier avec C-x RET r codage (marche mal sur mon mac)
Ensuite, j'ouvre un buffer, le « à » ne suscite pas de protestation,
mais *juste après* le « é » me vaut un buffer pop-up et une invitation
à préférer l'utf-8 sur l'iso-8859-1.
Tu n'as rien constaté de bizarre avec describe-coding-system à ce
moment ? Il doit y avoir un désaccord entre l'encodage du buffer et
celui du clavier.
Je ferme et rouvre emacs. Cette fois-ci le « é » passe. M-x
describe-coding-system : on est bien en iso-latin-1.
Je ferme et re-ouvre emacs. j'ouvre ~/.emacs. C-h C donne
iso-latin-1-dos (pourquoi ? Je ne demande plus de dos).
Parce que les sauts de lignes déjà enregistrés sont au format dos ?
Emacs essaie de deviner quand c'est possible l'encodage d'un fichier à
l'ouverture. Parfois il se trompe (ex: distinguer latin-1 du latin-9
s'il n'y a pas d'euro ou de caractère spécifique latin-9).
Je rouvre un nouveau fichier en mode Text. Cette fois le à (première
lettre accentuée) ne passe plus, alors qu'elle passait tout à l'heure,
et les pop-up me proposent de remplacer l'iso-latin-1 (seul encodage
testé cette fois), par... du koi8-r, seigneur !
J'ai eu ce genre de soucis au début pour configurer emacs/gnus pour
manipuler correctement générer par défaut du latin-9 sur un mac alors
que l'encodage par défaut du système est mac-roman... On y arrive :)
> et peut-être aussi comment tes caractères accentués sont vus par
> emacs : C-u C-x = sur le caractère t'affichera des informations très
> utiles.
Sur le « à » qui cause des problèmes juste au dessus :
----
character: à (04340, 2272, 0x8e0)
charset: latin-iso8859-1
[...]
file code: E0 (encoded by coding system iso-latin-1)
Donc le caractère est bien en latin-1 ou iso-8859-1 maintenant il faut
vérifier le reste (buffer / clavier).
Ce que je trouve particulièrement savoureux c'est qu'il me range mon «
à » dans « latin-iso8859-1 », mais qu'il refuse d'utiliser ce charset
pour l'encoder (cela dit le C-x C-s après le C-u C-x = est passé, donc
peut être que c'était déjà réglé. J'ai voulu répéter toute
l'expérience (tantôt le à passe, tantôt non, toujours dans un buffer
en mode texte ouvert après l'ouverture / fermeture du .emacs, qui est
toujours reconnu comme du iso-8859-1-dos), et le à est bien toujours
classé comme du latin-1, même quand juste après il n'arrive pa sà
l'encoder.
Le problème vient peut-être d'un autre caractère qu'il ne sait pas
sauver en latin-1 ? Normalement quand il te demande un encodage
alternatif au moment de l'enregistrement, il te précise les caractères
qui lui posent problème.
N'empêche que cette façon d'emacs de ne pas savoir
reconnaitre un jeu d'encodage (le seul logiciel que je connaisse dans
ce cas) ne me rassure guère.
Faut pas. On peut tout faire avec Emacs et on peut le modifier comme on
veut, avec le risque de mal le paramétrer.
Il faut dire qu'à ses débuts il y a environ 30 ans, il n'avait pas
autant d'encodages à manipuler. Au fil du temps leur support a été
ajouté avec plus ou moins de bonheur. Dans l'avenir avec l'utilisation
d'unicode ces problèmes devraient disparaître.
Mais même avec les éditeurs de win, tu as déjà ouvert un fichier "de
l'époque du dos" (càd non encodé en ansi de windows) avec notepad ? Il y
a les mêmes problèmes avec les accents (page de code 437 vs. 850).
Ok, je note ces indications. Inutiles de (mal) redéclarer ce qui
l'a déjà été par set-language-environment. Seulement entre
iso-8859-1-dos et iso-8859-1, il n'y a pas de différence cruciales
?
Pas de différence de codage de caractères. Le suffixe -dos indique
qu'avec cet encodage il va utiliser le retour à la ligne "dos" soit
cr+lf. Il existe le même encodage avec -unix (lf / 13) et -mac (cr / 10)
suivant la plateforme d'origine ou de destination du document à éditer.
> Tu peux tenter de le rouvrir en changeant de coding-system par C-x
> RET c avant de faire le C-x C-f et d'utiliser latin-1, latin-9 ou
> utf-8. Ça pourrait permettre de récupérer ton fichier.
J'avais essayer en précisant l'encodage avec C-x RET f sur le
fichier ouvert, est-ce la même chose ?
C-x RET f indique l'encodage à utiliser si possible pour le prochain
enregistrement et les suivants. Il ne modifie pas l'encodage courant.
Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)
- le spécifier avant l'ouverture C-x RET c codage C-x C-f
- réouvrir le fichier avec C-x RET r codage (marche mal sur mon mac)
Ensuite, j'ouvre un buffer, le « à » ne suscite pas de protestation,
mais *juste après* le « é » me vaut un buffer pop-up et une invitation
à préférer l'utf-8 sur l'iso-8859-1.
Tu n'as rien constaté de bizarre avec describe-coding-system à ce
moment ? Il doit y avoir un désaccord entre l'encodage du buffer et
celui du clavier.Je ferme et rouvre emacs. Cette fois-ci le « é » passe. M-x
describe-coding-system : on est bien en iso-latin-1.
Je ferme et re-ouvre emacs. j'ouvre ~/.emacs. C-h C donne
iso-latin-1-dos (pourquoi ? Je ne demande plus de dos).
Parce que les sauts de lignes déjà enregistrés sont au format dos ?
Emacs essaie de deviner quand c'est possible l'encodage d'un fichier à
l'ouverture. Parfois il se trompe (ex: distinguer latin-1 du latin-9
s'il n'y a pas d'euro ou de caractère spécifique latin-9).Je rouvre un nouveau fichier en mode Text. Cette fois le à (première
lettre accentuée) ne passe plus, alors qu'elle passait tout à l'heure,
et les pop-up me proposent de remplacer l'iso-latin-1 (seul encodage
testé cette fois), par... du koi8-r, seigneur !
J'ai eu ce genre de soucis au début pour configurer emacs/gnus pour
manipuler correctement générer par défaut du latin-9 sur un mac alors
que l'encodage par défaut du système est mac-roman... On y arrive :)> et peut-être aussi comment tes caractères accentués sont vus par
> emacs : C-u C-x = sur le caractère t'affichera des informations très
> utiles.
Sur le « à » qui cause des problèmes juste au dessus :
----
character: à (04340, 2272, 0x8e0)
charset: latin-iso8859-1
[...]
file code: E0 (encoded by coding system iso-latin-1)
Donc le caractère est bien en latin-1 ou iso-8859-1 maintenant il faut
vérifier le reste (buffer / clavier).Ce que je trouve particulièrement savoureux c'est qu'il me range mon «
à » dans « latin-iso8859-1 », mais qu'il refuse d'utiliser ce charset
pour l'encoder (cela dit le C-x C-s après le C-u C-x = est passé, donc
peut être que c'était déjà réglé. J'ai voulu répéter toute
l'expérience (tantôt le à passe, tantôt non, toujours dans un buffer
en mode texte ouvert après l'ouverture / fermeture du .emacs, qui est
toujours reconnu comme du iso-8859-1-dos), et le à est bien toujours
classé comme du latin-1, même quand juste après il n'arrive pa sà
l'encoder.
Le problème vient peut-être d'un autre caractère qu'il ne sait pas
sauver en latin-1 ? Normalement quand il te demande un encodage
alternatif au moment de l'enregistrement, il te précise les caractères
qui lui posent problème.
SL writes:- plein de modes (xml, nxml, java (jde), auctex, etc. etc. je ne
saurais pas les lister.)
Ça, c'est trivial à faire soi-même.
- plein de matériel TEI (les DTD / Schémas, les stylesheets)
Ça je connais pas. Mais ça ne doit pas être bien compliqué de
les récupérer soi-même. J'imagine que le consortium TEI propose
une archive rassemblant le tout.
- pas mal des binaires les plus indispensables pour XML (xmllint,
xsltproc, tidy, xt, saxon, jing, catalog), quelques autre (grep).
Même remarque que pour les modes d'édition. En outre, il
semble donc qu'il y ai des doublons dans les logiciels installés.- un paramétrage d'emacs pour en faire un outils d'édition de document
TEI : un menu "insert skeleton" par exemple, ce genre de chose, des
menus pour valider / transformer / etc.
C'est sans doute ici que tu auras le plus de soucis. Ne
proposent-ils pas ces fonctionnalités en tant que mode
indépendant à installer selon les règles habituelles ?
SL writes:
- plein de modes (xml, nxml, java (jde), auctex, etc. etc. je ne
saurais pas les lister.)
Ça, c'est trivial à faire soi-même.
- plein de matériel TEI (les DTD / Schémas, les stylesheets)
Ça je connais pas. Mais ça ne doit pas être bien compliqué de
les récupérer soi-même. J'imagine que le consortium TEI propose
une archive rassemblant le tout.
- pas mal des binaires les plus indispensables pour XML (xmllint,
xsltproc, tidy, xt, saxon, jing, catalog), quelques autre (grep).
Même remarque que pour les modes d'édition. En outre, il
semble donc qu'il y ai des doublons dans les logiciels installés.
- un paramétrage d'emacs pour en faire un outils d'édition de document
TEI : un menu "insert skeleton" par exemple, ce genre de chose, des
menus pour valider / transformer / etc.
C'est sans doute ici que tu auras le plus de soucis. Ne
proposent-ils pas ces fonctionnalités en tant que mode
indépendant à installer selon les règles habituelles ?
SL writes:- plein de modes (xml, nxml, java (jde), auctex, etc. etc. je ne
saurais pas les lister.)
Ça, c'est trivial à faire soi-même.
- plein de matériel TEI (les DTD / Schémas, les stylesheets)
Ça je connais pas. Mais ça ne doit pas être bien compliqué de
les récupérer soi-même. J'imagine que le consortium TEI propose
une archive rassemblant le tout.
- pas mal des binaires les plus indispensables pour XML (xmllint,
xsltproc, tidy, xt, saxon, jing, catalog), quelques autre (grep).
Même remarque que pour les modes d'édition. En outre, il
semble donc qu'il y ai des doublons dans les logiciels installés.- un paramétrage d'emacs pour en faire un outils d'édition de document
TEI : un menu "insert skeleton" par exemple, ce genre de chose, des
menus pour valider / transformer / etc.
C'est sans doute ici que tu auras le plus de soucis. Ne
proposent-ils pas ces fonctionnalités en tant que mode
indépendant à installer selon les règles habituelles ?
drkm a écrit :SL writes:- un paramétrage d'emacs pour en faire un outils d'édition de document
TEI : un menu "insert skeleton" par exemple, ce genre de chose, des
menus pour valider / transformer / etc.
C'est sans doute ici que tu auras le plus de soucis. Ne
proposent-ils pas ces fonctionnalités en tant que mode
indépendant à installer selon les règles habituelles ?
Ah mais je présentais l'ensemble pour répondre à ta question (qu'est
ce que c'est ?) ; personnellement je ne m'en sers pas trop de ces
menuss. Mais effectivement je ne sais pas où c'est défini cela dit.
drkm a écrit :
SL writes:
- un paramétrage d'emacs pour en faire un outils d'édition de document
TEI : un menu "insert skeleton" par exemple, ce genre de chose, des
menus pour valider / transformer / etc.
C'est sans doute ici que tu auras le plus de soucis. Ne
proposent-ils pas ces fonctionnalités en tant que mode
indépendant à installer selon les règles habituelles ?
Ah mais je présentais l'ensemble pour répondre à ta question (qu'est
ce que c'est ?) ; personnellement je ne m'en sers pas trop de ces
menuss. Mais effectivement je ne sais pas où c'est défini cela dit.
drkm a écrit :SL writes:- un paramétrage d'emacs pour en faire un outils d'édition de document
TEI : un menu "insert skeleton" par exemple, ce genre de chose, des
menus pour valider / transformer / etc.
C'est sans doute ici que tu auras le plus de soucis. Ne
proposent-ils pas ces fonctionnalités en tant que mode
indépendant à installer selon les règles habituelles ?
Ah mais je présentais l'ensemble pour répondre à ta question (qu'est
ce que c'est ?) ; personnellement je ne m'en sers pas trop de ces
menuss. Mais effectivement je ne sais pas où c'est défini cela dit.
Sébastien Kirche a écrit :Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)
Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ; il y a des formats de fichier
(XML pour ne pas le nommer) dans lesquels c'est impossible...
Sébastien Kirche a écrit :
Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)
Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ; il y a des formats de fichier
(XML pour ne pas le nommer) dans lesquels c'est impossible...
Sébastien Kirche a écrit :Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)
Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ; il y a des formats de fichier
(XML pour ne pas le nommer) dans lesquels c'est impossible...
SL writes:Sébastien Kirche a écrit :Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ; il y a des formats de fichier
(XML pour ne pas le nommer) dans lesquels c'est impossible...
Comment ça ?
<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>
SL writes:
Sébastien Kirche a écrit :
Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)
Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ; il y a des formats de fichier
(XML pour ne pas le nommer) dans lesquels c'est impossible...
Comment ça ?
<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>
SL writes:Sébastien Kirche a écrit :Pour forcer l'encodage et en être sûr, il faut au choix :
- le préciser «en dur» dans le fichier par une variable de fichier
(-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
la fin)Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ; il y a des formats de fichier
(XML pour ne pas le nommer) dans lesquels c'est impossible...
Comment ça ?
<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>
Franchement, j'ai des fichiers dans tous les jeux possibles, Unix
aussi bien que Windows, qui passent sans problème dans Vim (dont le
port sur Windows est incomparablement meilleur que celui d'emacs, au
passage) aussi bien que dans un (excellent) éditeur Windows comme
TextPad.
Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Et encore, je m'empresse d'oublier les choses atterrantes que j'ai
aperçues sur la nécessité de mettre un en-tête en haut de certains
fichies pour préciser l'encodage...
> > Ok, je note ces indications. Inutiles de (mal) redéclarer ce qui
> > l'a déjà été par set-language-environment. Seulement entre
> > iso-8859-1-dos et iso-8859-1, il n'y a pas de différence cruciales
> > ?
>
> Pas de différence de codage de caractères. Le suffixe -dos indique
> qu'avec cet encodage il va utiliser le retour à la ligne "dos" soit
> cr+lf. Il existe le même encodage avec -unix (lf / 13) et -mac (cr /
> 10) suivant la plateforme d'origine ou de destination du document à
> éditer.
Que ne l'aie-je su plus tôt...
> Pour forcer l'encodage et en être sûr, il faut au choix :
> - le préciser «en dur» dans le fichier par une variable de fichier
> (-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
> la fin)
Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ;
il y a des formats de fichier (XML pour ne pas le nommer) dans
lesquels c'est impossible...
> Le problème vient peut-être d'un autre caractère qu'il ne sait pas
> sauver en latin-1 ? Normalement quand il te demande un encodage
> alternatif au moment de l'enregistrement, il te précise les
> caractères qui lui posent problème.
Ah ? Ben non, là je vois rien de tel...
Franchement, j'ai des fichiers dans tous les jeux possibles, Unix
aussi bien que Windows, qui passent sans problème dans Vim (dont le
port sur Windows est incomparablement meilleur que celui d'emacs, au
passage) aussi bien que dans un (excellent) éditeur Windows comme
TextPad.
Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Et encore, je m'empresse d'oublier les choses atterrantes que j'ai
aperçues sur la nécessité de mettre un en-tête en haut de certains
fichies pour préciser l'encodage...
> > Ok, je note ces indications. Inutiles de (mal) redéclarer ce qui
> > l'a déjà été par set-language-environment. Seulement entre
> > iso-8859-1-dos et iso-8859-1, il n'y a pas de différence cruciales
> > ?
>
> Pas de différence de codage de caractères. Le suffixe -dos indique
> qu'avec cet encodage il va utiliser le retour à la ligne "dos" soit
> cr+lf. Il existe le même encodage avec -unix (lf / 13) et -mac (cr /
> 10) suivant la plateforme d'origine ou de destination du document à
> éditer.
Que ne l'aie-je su plus tôt...
> Pour forcer l'encodage et en être sûr, il faut au choix :
> - le préciser «en dur» dans le fichier par une variable de fichier
> (-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
> la fin)
Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ;
il y a des formats de fichier (XML pour ne pas le nommer) dans
lesquels c'est impossible...
> Le problème vient peut-être d'un autre caractère qu'il ne sait pas
> sauver en latin-1 ? Normalement quand il te demande un encodage
> alternatif au moment de l'enregistrement, il te précise les
> caractères qui lui posent problème.
Ah ? Ben non, là je vois rien de tel...
Franchement, j'ai des fichiers dans tous les jeux possibles, Unix
aussi bien que Windows, qui passent sans problème dans Vim (dont le
port sur Windows est incomparablement meilleur que celui d'emacs, au
passage) aussi bien que dans un (excellent) éditeur Windows comme
TextPad.
Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Et encore, je m'empresse d'oublier les choses atterrantes que j'ai
aperçues sur la nécessité de mettre un en-tête en haut de certains
fichies pour préciser l'encodage...
> > Ok, je note ces indications. Inutiles de (mal) redéclarer ce qui
> > l'a déjà été par set-language-environment. Seulement entre
> > iso-8859-1-dos et iso-8859-1, il n'y a pas de différence cruciales
> > ?
>
> Pas de différence de codage de caractères. Le suffixe -dos indique
> qu'avec cet encodage il va utiliser le retour à la ligne "dos" soit
> cr+lf. Il existe le même encodage avec -unix (lf / 13) et -mac (cr /
> 10) suivant la plateforme d'origine ou de destination du document à
> éditer.
Que ne l'aie-je su plus tôt...
> Pour forcer l'encodage et en être sûr, il faut au choix :
> - le préciser «en dur» dans le fichier par une variable de fichier
> (-*- coding: latin-1-dos -*- au début ou un bloc «Local variables» à
> la fin)
Ah ! seigneur, c'est ce dont je parlais plus haut. Franchement ce
n'est pas une solution satisfaisante ;
il y a des formats de fichier (XML pour ne pas le nommer) dans
lesquels c'est impossible...
> Le problème vient peut-être d'un autre caractère qu'il ne sait pas
> sauver en latin-1 ? Normalement quand il te demande un encodage
> alternatif au moment de l'enregistrement, il te précise les
> caractères qui lui posent problème.
Ah ? Ben non, là je vois rien de tel...
drkm a écrit :<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>
Ah, je croyais que c'était au tout début ; mais franchement je n'ai
aucune envie de poluer des documents XML avec des trucs comme ça,
c'est complètement archaïque... Je change d'éditeur quand il faut en
venir à des choses pareilles.
drkm a écrit :
<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>
Ah, je croyais que c'était au tout début ; mais franchement je n'ai
aucune envie de poluer des documents XML avec des trucs comme ça,
c'est complètement archaïque... Je change d'éditeur quand il faut en
venir à des choses pareilles.
drkm a écrit :<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>
Ah, je croyais que c'était au tout début ; mais franchement je n'ai
aucune envie de poluer des documents XML avec des trucs comme ça,
c'est complètement archaïque... Je change d'éditeur quand il faut en
venir à des choses pareilles.
Le 14 septembre 2005 à 19:09, SL a formulé :Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce
sens-là... il y a un truc !
il y a des formats de fichier (XML pour ne pas le nommer) dans
lesquels c'est impossible...
Pour l'édition xml, nXml s'en sort très bien avec l'encodage xml. Mais à
la rigueur on doit pouvoir utiliser -*- dans un commentaire <!-- -->
Le 14 septembre 2005 à 19:09, SL a formulé :
Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce
sens-là... il y a un truc !
il y a des formats de fichier (XML pour ne pas le nommer) dans
lesquels c'est impossible...
Pour l'édition xml, nXml s'en sort très bien avec l'encodage xml. Mais à
la rigueur on doit pouvoir utiliser -*- dans un commentaire <!-- -->
Le 14 septembre 2005 à 19:09, SL a formulé :Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce
sens-là... il y a un truc !
il y a des formats de fichier (XML pour ne pas le nommer) dans
lesquels c'est impossible...
Pour l'édition xml, nXml s'en sort très bien avec l'encodage xml. Mais à
la rigueur on doit pouvoir utiliser -*- dans un commentaire <!-- -->
SL writes:drkm a écrit :<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>Ah, je croyais que c'était au tout début ; mais franchement je n'ai
aucune envie de poluer des documents XML avec des trucs comme ça,
c'est complètement archaïque... Je change d'éditeur quand il faut en
venir à des choses pareilles.
D'un côté je comprend. Mais en l'occurrence, c'est normal. Tu
dis que ton document contient de l'UTF-8, alors qu'en fait c'est
du Latin-1. Il faut bien le préciser.
SL writes:
drkm a écrit :
<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>
Ah, je croyais que c'était au tout début ; mais franchement je n'ai
aucune envie de poluer des documents XML avec des trucs comme ça,
c'est complètement archaïque... Je change d'éditeur quand il faut en
venir à des choses pareilles.
D'un côté je comprend. Mais en l'occurrence, c'est normal. Tu
dis que ton document contient de l'UTF-8, alors qu'en fait c'est
du Latin-1. Il faut bien le préciser.
SL writes:drkm a écrit :<?xml version="1.0"?> <!-- -*- coding: latin-1 -*- -->
<root/>Ah, je croyais que c'était au tout début ; mais franchement je n'ai
aucune envie de poluer des documents XML avec des trucs comme ça,
c'est complètement archaïque... Je change d'éditeur quand il faut en
venir à des choses pareilles.
D'un côté je comprend. Mais en l'occurrence, c'est normal. Tu
dis que ton document contient de l'UTF-8, alors qu'en fait c'est
du Latin-1. Il faut bien le préciser.
Le 14 septembre 2005 à 19:09, SL a formulé :Franchement, j'ai des fichiers dans tous les jeux possibles, Unix
aussi bien que Windows, qui passent sans problème dans Vim (dont le
port sur Windows est incomparablement meilleur que celui d'emacs, au
passage) aussi bien que dans un (excellent) éditeur Windows comme
TextPad.
Pourtant, si l'encodage n'est pas indiqué explicitement par une
indication dans le fichier (vim le propose aussi il me semble) ou une
info de type BOM pour les fichiers utf, ils n'ont pas d'autre solution
que d'essayer de deviner comme le fait Emacs.
Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce
sens-là... il y a un truc !
Par exemple je m'en sers pour le coding, mais aussi pour indiquer la
position de la fill-column ou l'utilisation du mode outline.
> Le problème vient peut-être d'un autre caractère qu'il ne sait pas
> sauver en latin-1 ? Normalement quand il te demande un encodage
> alternatif au moment de l'enregistrement, il te précise les
> caractères qui lui posent problème.
Ah ? Ben non, là je vois rien de tel...
Tiens ? Aucune explication du pourquoi il te demande de changer
l'encodage ?
Le 14 septembre 2005 à 19:09, SL a formulé :
Franchement, j'ai des fichiers dans tous les jeux possibles, Unix
aussi bien que Windows, qui passent sans problème dans Vim (dont le
port sur Windows est incomparablement meilleur que celui d'emacs, au
passage) aussi bien que dans un (excellent) éditeur Windows comme
TextPad.
Pourtant, si l'encodage n'est pas indiqué explicitement par une
indication dans le fichier (vim le propose aussi il me semble) ou une
info de type BOM pour les fichiers utf, ils n'ont pas d'autre solution
que d'essayer de deviner comme le fait Emacs.
Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce
sens-là... il y a un truc !
Par exemple je m'en sers pour le coding, mais aussi pour indiquer la
position de la fill-column ou l'utilisation du mode outline.
> Le problème vient peut-être d'un autre caractère qu'il ne sait pas
> sauver en latin-1 ? Normalement quand il te demande un encodage
> alternatif au moment de l'enregistrement, il te précise les
> caractères qui lui posent problème.
Ah ? Ben non, là je vois rien de tel...
Tiens ? Aucune explication du pourquoi il te demande de changer
l'encodage ?
Le 14 septembre 2005 à 19:09, SL a formulé :Franchement, j'ai des fichiers dans tous les jeux possibles, Unix
aussi bien que Windows, qui passent sans problème dans Vim (dont le
port sur Windows est incomparablement meilleur que celui d'emacs, au
passage) aussi bien que dans un (excellent) éditeur Windows comme
TextPad.
Pourtant, si l'encodage n'est pas indiqué explicitement par une
indication dans le fichier (vim le propose aussi il me semble) ou une
info de type BOM pour les fichiers utf, ils n'ont pas d'autre solution
que d'essayer de deviner comme le fait Emacs.
Je ne comprends pas qu'emacs se vautre à traiter du latin-1 comme de
l'utf-8.
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce
sens-là... il y a un truc !
Par exemple je m'en sers pour le coding, mais aussi pour indiquer la
position de la fill-column ou l'utilisation du mode outline.
> Le problème vient peut-être d'un autre caractère qu'il ne sait pas
> sauver en latin-1 ? Normalement quand il te demande un encodage
> alternatif au moment de l'enregistrement, il te précise les
> caractères qui lui posent problème.
Ah ? Ben non, là je vois rien de tel...
Tiens ? Aucune explication du pourquoi il te demande de changer
l'encodage ?
