Je n'ai rien mis sur l'encodage dans mon .gnus, par contre dans les
customizes je trouve des trucs comme :
Gnus Default Charset: Hide iso-8859-1
Gnus Default Posting Charset: Hide nil
Gnus Group Posting Charset Alist: Hide
INS DEL Permitted unencoded charsets:
Where: Value Menu Group: ^\(fido7\|relcom\)\.[^,]*\(,[
]*\(fido7\|relcom\)\.[^,]*\)*$
Header: Value Menu Charset: koi8-r
Body: Value Menu Charsets:
INS DEL Charset: koi8-r
INS
INS DEL Permitted unencoded charsets:
Where: Value Menu Mail message
Header: Value Menu None
Body: Value Menu None
INS DEL Permitted unencoded charsets:
Where: Value Menu News article
Header: Value Menu None
Body: Value Menu Any
INS
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce sens-là... il y a un truc !
SL parlait d'XML. N'aurais-tu pas (SL) un document en Latin-1 avec une déclaration XML de la forme :
<?xml version="1.0"?>
? Si c'est le cas, alors c'est normal, tu dis que ton document est en UTF-8.
J'avoue que sur la fin c'était peut être le cas, entre nxml qui essayait de changer l'encodage et emacs qui par derrière se mélangeait les pédales, je convertissais ensuite hors d'emacs dans l'encodage voulu (et déclaré).
drkm a écrit :
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce
sens-là... il y a un truc !
SL parlait d'XML. N'aurais-tu pas (SL) un document en Latin-1
avec une déclaration XML de la forme :
<?xml version="1.0"?>
? Si c'est le cas, alors c'est normal, tu dis que ton document
est en UTF-8.
J'avoue que sur la fin c'était peut être le cas, entre nxml qui
essayait de changer l'encodage et emacs qui par derrière se mélangeait
les pédales, je convertissais ensuite hors d'emacs dans l'encodage
voulu (et déclaré).
Le contraire, je comprends encore s'il n'y a pas de BOM, mais dans ce sens-là... il y a un truc !
SL parlait d'XML. N'aurais-tu pas (SL) un document en Latin-1 avec une déclaration XML de la forme :
<?xml version="1.0"?>
? Si c'est le cas, alors c'est normal, tu dis que ton document est en UTF-8.
J'avoue que sur la fin c'était peut être le cas, entre nxml qui essayait de changer l'encodage et emacs qui par derrière se mélangeait les pédales, je convertissais ensuite hors d'emacs dans l'encodage voulu (et déclaré).
Sébastien Kirche
Le 14 septembre 2005 à 22:09, SL a formulé :
> 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.
Eh bien je ne comprends pas, je n'ai jamais vu un éditeur avoir autant de mal. Peut être le poid de toute une tradition emacsienne avec le jeu "mule" ?
Justement, il faudrait que fasse des tests comparatifs sur la machine de ma femme avec un assortiment d'éditeurs de notepad à ultraedit en passant par l'ide de visual studio. Ça m'étonnerais qu'il sachent directement relire n'importe quel encodage.
Sinon on n'aurait pas besoin de béquille logicielles pour effectuer la traduction mac<->win à mon boulot.
Le jeu mule comme tu dis permet à emacs de pouvoir manipuler une grande quantité d'encodages différents (jusqu'aux cyrillique / chinois / japonais). Mais il n'arrive pas forcément à deviner tout seul le bon.
[...] > 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.
Effectivement ça peut être intéressant... m'enfin ça vire au concept de l'éditeur qui à son propre format de fichier, c'est quand même un peu limite...
Ah ben non, justement. Il s'agit de laisser quelques info dans un coin du fichier pour pouvoir refaire certains réglages en ouvrant le fichier.
Par exemple quand tu te rends compte que tu refais toujours les mêmes manips à l'ouverture, du genre activer un mode.
Mais le fichier reste éditable par n'importe quel autre éditeur de texte.
> > > 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 ?
Non, à chaque fois que j'ai le pop-up "ces encodages ont été essayé... aucun d'eux ne permet d'encoder...", je n'ai aucune indication sur le caractère en particulier qui a fait achopper l'encodage. Peut être que c'est uniquement dans la dernière version d'emacs ? (que je ne regrette pas d'avoir installé je dois dire :-)
C'est bizarre. Il arrive que des caractères perturbent la sauvegarde d'un fichier (par exemple en copiant-scotchant du texte encodé en mac-roman sous osx dans un fichier latin-9) mais je n'ai pas souvenir d'avoir d'avoir une question (en français en plus ?) via un popup. Par contre d'habitude il splitte l'affichage et il indique les caractères fautifs. Ça ne viendrait pas de tes paquetages supplémentaires ?
-- Sébastien Kirche
Le 14 septembre 2005 à 22:09, SL a formulé :
> 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.
Eh bien je ne comprends pas, je n'ai jamais vu un éditeur avoir autant
de mal. Peut être le poid de toute une tradition emacsienne avec le
jeu "mule" ?
Justement, il faudrait que fasse des tests comparatifs sur la machine de
ma femme avec un assortiment d'éditeurs de notepad à ultraedit en
passant par l'ide de visual studio. Ça m'étonnerais qu'il sachent
directement relire n'importe quel encodage.
Sinon on n'aurait pas besoin de béquille logicielles pour effectuer la
traduction mac<->win à mon boulot.
Le jeu mule comme tu dis permet à emacs de pouvoir manipuler une
grande quantité d'encodages différents (jusqu'aux cyrillique / chinois /
japonais). Mais il n'arrive pas forcément à deviner tout seul le bon.
[...]
> 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.
Effectivement ça peut être intéressant... m'enfin ça vire au concept
de l'éditeur qui à son propre format de fichier, c'est quand même un
peu limite...
Ah ben non, justement. Il s'agit de laisser quelques info dans un coin
du fichier pour pouvoir refaire certains réglages en ouvrant le fichier.
Par exemple quand tu te rends compte que tu refais toujours les mêmes
manips à l'ouverture, du genre activer un mode.
Mais le fichier reste éditable par n'importe quel autre éditeur de
texte.
> > > 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 ?
Non, à chaque fois que j'ai le pop-up "ces encodages ont été
essayé... aucun d'eux ne permet d'encoder...", je n'ai aucune
indication sur le caractère en particulier qui a fait achopper
l'encodage. Peut être que c'est uniquement dans la dernière version
d'emacs ? (que je ne regrette pas d'avoir installé je dois dire :-)
C'est bizarre. Il arrive que des caractères perturbent la sauvegarde
d'un fichier (par exemple en copiant-scotchant du texte encodé en
mac-roman sous osx dans un fichier latin-9) mais je n'ai pas souvenir
d'avoir d'avoir une question (en français en plus ?) via un popup.
Par contre d'habitude il splitte l'affichage et il indique les
caractères fautifs.
Ça ne viendrait pas de tes paquetages supplémentaires ?
> 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.
Eh bien je ne comprends pas, je n'ai jamais vu un éditeur avoir autant de mal. Peut être le poid de toute une tradition emacsienne avec le jeu "mule" ?
Justement, il faudrait que fasse des tests comparatifs sur la machine de ma femme avec un assortiment d'éditeurs de notepad à ultraedit en passant par l'ide de visual studio. Ça m'étonnerais qu'il sachent directement relire n'importe quel encodage.
Sinon on n'aurait pas besoin de béquille logicielles pour effectuer la traduction mac<->win à mon boulot.
Le jeu mule comme tu dis permet à emacs de pouvoir manipuler une grande quantité d'encodages différents (jusqu'aux cyrillique / chinois / japonais). Mais il n'arrive pas forcément à deviner tout seul le bon.
[...] > 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.
Effectivement ça peut être intéressant... m'enfin ça vire au concept de l'éditeur qui à son propre format de fichier, c'est quand même un peu limite...
Ah ben non, justement. Il s'agit de laisser quelques info dans un coin du fichier pour pouvoir refaire certains réglages en ouvrant le fichier.
Par exemple quand tu te rends compte que tu refais toujours les mêmes manips à l'ouverture, du genre activer un mode.
Mais le fichier reste éditable par n'importe quel autre éditeur de texte.
> > > 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 ?
Non, à chaque fois que j'ai le pop-up "ces encodages ont été essayé... aucun d'eux ne permet d'encoder...", je n'ai aucune indication sur le caractère en particulier qui a fait achopper l'encodage. Peut être que c'est uniquement dans la dernière version d'emacs ? (que je ne regrette pas d'avoir installé je dois dire :-)
C'est bizarre. Il arrive que des caractères perturbent la sauvegarde d'un fichier (par exemple en copiant-scotchant du texte encodé en mac-roman sous osx dans un fichier latin-9) mais je n'ai pas souvenir d'avoir d'avoir une question (en français en plus ?) via un popup. Par contre d'habitude il splitte l'affichage et il indique les caractères fautifs. Ça ne viendrait pas de tes paquetages supplémentaires ?
