Gnus et encodage (toujours)

Le 12 September 2005 à 11:09, SL vraute :

Sauriez vous comment éviter le multi-part ?

Pas eu le temps de décortiquer tes posts, mais une solution qui permet
d'éviter le multipart avec gnus:

(unify-8859-on-encoding-mode t)
(unify-8859-on-decoding-mode t)
(éventuellement après un (require 'ucs-tables))

Si ça ne suffit pas, j'essaierai de dépiauter tes messages plus en
détail.

--
Sébastien Kirche

Sébastien Kirche a écrit :

Le 12 September 2005 à 11:09, SL vraute :

> Sauriez vous comment éviter le multi-part ?

Pas eu le temps de décortiquer tes posts, mais une solution qui
permet d'éviter le multipart avec gnus:

(unify-8859-on-encoding-mode t)
(unify-8859-on-decoding-mode t)
(éventuellement après un (require 'ucs-tables))

Si ça ne suffit pas, j'essaierai de dépiauter tes messages plus en
détail.

Merci, j'essaye.

SL <nospam@nospam.com> writes:

Merci, j'essaye.

Voir ma page sur emacs et les accents aussi.

--
Matthieu

Bonjour,

Désolé pour l'état dégueulasse de ce mail, c'est précisément le genre
de pb pour lesquels j'écris.

Je voudrais prendre à bras le corps les problèmes d'encodage qui me
pourrissent la vie dans emacs. Je n'ai jamais réussi à régler
totalement le problème et il est particulièrement gênant : non
seulement à l'édition, où il me faut dans certains fichiers confirmer
l'encodage utilisé à chaque sauvegarde, mais aussi parce qu'il m'ait
arrivé que emacs me corrompe des fichiers, et que donc je n'ouvre pas
dans emacs les fichiers volumineux/précieux. Honnêtement, c'est
l'énorme défaut que je trouve à emacs (sans doute une mauvaise
configuration de ma part, mais bon).

voici le contenu de mon ~/.emacs se rapportant à l'encodage :

---------------

(require 'ucs-tables)
(unify-8859-on-encoding-mode t)
(unify-8859-on-decoding-mode t)

(set-language-environment "French")
(prefer-coding-system 'iso-8859-1)
(set-w32-system-coding-system (quote iso-8859-1))
(setq current-language-environment (quote latin-1))
(setq default-buffer-file-coding-system 'latin-1-dos)
;; pour nxml
(setq buffer-file-coding-system 'latin-1-dos)
(set-keyboard-coding-system (quote latin-1-dos))
(setq keyboard-coding-system (quote latin-1-dos))
(setq terminal-coding-system (quote latin-1-dos))

---------------

Les trois premières lignes m'ont été recommandé par Sébastien le 12/9
pour un problème de multipart avec gnus qui achève de me décourager.

Les caractères saccagés ci-dessus le sont parce que j'ai voulu changer
"French" par 'French dans la quatrième ligne de code de l'extrait de
.emacs, j'ai fermé et rouvert ce fichier, qui est apparu comrompu ;
j'ai remis language-environment sur "French" mais le fichier est
irrécupérable...

J'ai consulté déjà à moult reprise la page de Matthieu qui ne m'a pas
permis de fixer le problème.

La manifestation la plus fréquente du pb est qu'à partir d'un certain
moment de l'édition du fichier, "C-x s" produit l'affichage de ce
message dans le mini buffer :

Select coding system (default raw-text):

et l'affichage d'un buffer-pop up :

These default coding systems were tried:
iso-latin-1-dos mule-utf-8
However, none of them safely encodes the target text.

Select one of the following safe coding systems:
raw-text emacs-mule no-conversion

Il n'y a aucun caractère hors de l'iso-8859-1 dans mon
buffer. J'ai réussi à observer un cas précis : dans un buffer vierge
"Il n'y a rien de" ne pose pas de pb mais "sûr" en pose un ; qui plus
est, le coup d'après, les mêmes caractères passent sans problème ;
enfin à chaque fois qu'apparaît ce message, il suffit de répéter "C-x
s" et à la quatrième tentative le buffer est écrit... bref je n'y
comprends absolument rien.

Quelques autres observations : les relevés de ce que produit C-h C
dans différentes situation :

------------------
Dans un buffer en mode "Text", premier buffer ouvert au lancemetn d'emacs :

Coding system for saving this buffer:
1 -- iso-latin-1-dos
Default coding system (for new files):
1 -- latin-1-dos
Coding system for keyboard input:
1 -- latin-1-dos
Coding system for terminal output:
1 -- iso-latin-1 (alias: iso-8859-1 latin-1)

-----------------
Dans un buffer en mode "nxml" :

Coding system for saving this buffer:
u -- utf-8-dos
Default coding system (for new files):
u -- mule-utf-8-dos
Coding system for keyboard input:
1 -- latin-1-dos
Coding system for terminal output:
1 -- iso-latin-1 (alias: iso-8859-1 latin-1)
Defaults for subprocess I/O:
decoding: u -- mule-utf-8-dos
encoding: u -- mule-utf-8-dos
------------

Dans un buffer en mode "Text", ouvert après qu'ait été utilisé le mode
"nxml" :

Coding system for saving this buffer:
- -- undecided-dos
Default coding system (for new files):
u -- mule-utf-8-dos
Coding system for keyboard input:
1 -- latin-1-dos
Coding system for terminal output:
1 -- iso-latin-1 (alias: iso-8859-1 latin-1)
Defaults for subprocess I/O:
decoding: u -- mule-utf-8-dos
encoding: u -- mule-utf-8-dos

Parfois, dans un fichier txt après l'ouverture de nxml :

Coding system for saving this buffer:
u -- mule-utf-8-dos
Default coding system (for new files):
u -- mule-utf-8-dos
Coding system for keyboard input:
1 -- latin-1-dos
Coding system for terminal output:
1 -- iso-latin-1 (alias: iso-8859-1 latin-1)
Defaults for subprocess I/O:
decoding: u -- mule-utf-8-dos
encoding: u -- mule-utf-8-dos


----------------------

Bref, toute aide bienvenue !

SL

SL <nospam@nospam.com> writes:

These default coding systems were tried:
iso-latin-1-dos mule-utf-8
However, none of them safely encodes the target text.

Surprenant! Il y a trés peu de caractère qu'unicode n'encode pas.
Ne serait-ce pas un caractère spécifique à MS-Windows?

Sinon, si tu veux utiliser l'¤, il vaut mieux utiliser iso-8859-15 que
iso-8859-1.

--
__Pascal Bourguignon__ http://www.informatimago.com/

There is no worse tyranny than to force a man to pay for what he does not
want merely because you think it would be good for him. -- Robert Heinlein

Pascal Bourguignon a écrit :

SL <nospam@nospam.com> writes:
> These default coding systems were tried:
> iso-latin-1-dos mule-utf-8
> However, none of them safely encodes the target text.

Surprenant! Il y a trés peu de caractère qu'unicode n'encode pas.
Ne serait-ce pas un caractère spécifique à MS-Windows?

Peut être faut-il préciser systématiquement utf-8-dos alors ?

Autre cas de figure : à la première lettre accentuée (un é !), j'ai le
buffer-pop-up pour me demander quel charset utiliser :

These default coding systems were tried:
latin-1-dos
However, none of them safely encodes the target text.

Select one of the following safe coding systems:
koi8-r mule-utf-16-be mule-utf-16-le utf-8 raw-text emacs-mule
no-conversion

C'est à dire que part défaut, ce fou furieux veut me mettre en coréen
! Ce que je ne comprends pas c'est cette absence totale de régularité
et de prévisibilité dans sa réaction : depuis presque un an, certes en
ne faisant pas spécialement attention au problème, je n'ai jamais pu
inférer la moindre logique dans ce comportement. C'est peut être le
port sur Windows qui pose des problèmes ? Ou alors j'utilise la
distribution de la TEI, peut être qu'elle fait beaucoup de réglages
problématiques ? J'ai regardé dans le site-start, je n'ai rien trouvé
de relatif à l'encodage.

Sinon, si tu veux utiliser l'¤, il vaut mieux utiliser iso-8859-15
que iso-8859-1.

Hélas, si le problème était d'avoir le symbole euro :-)...

Le 14 September 2005 à 12:09, SL vraute :

Bonjour,

Désolé pour l'état dégueulasse de ce mail, c'est précisément le genre
de pb pour lesquels j'écris.

Pas grave, c'est l'endroit pour en causer.

[...]

voici le contenu de mon ~/.emacs se rapportant à l'encodage :

---------------

(require 'ucs-tables)
(unify-8859-on-encoding-mode t)
(unify-8859-on-decoding-mode t)

(set-language-environment "French")
(prefer-coding-system 'iso-8859-1)
(set-w32-system-coding-system (quote iso-8859-1))
(setq current-language-environment (quote latin-1))
(setq default-buffer-file-coding-system 'latin-1-dos)
;; pour nxml
(setq buffer-file-coding-system 'latin-1-dos)
(set-keyboard-coding-system (quote latin-1-dos))
(setq keyboard-coding-system (quote latin-1-dos))
(setq terminal-coding-system (quote latin-1-dos))

Est-ce que tu pourrais préciser ta plate-forme et tes locales ?
Es-tu sous windows comme le paramètre set-w32-system-coding-system le
laisse supposer ?

Il semble aussi que tu utilises un ancien gnus sur un emacs 21.3.
Peut-être que la mise à jour d'emacs vers une version plus récente (21.4
ou cvs[1]) ansi que gnus pourrait aider à régler des problèmes ? Il me
semble que depuis ces versions pas mal de corrections ont été apportés.

Il faut savoir que set-language-environment prépositionne un certain
nombre de réglages, aussi je me demande si les réglages suivants
n'embrouillent pas les réglages.

Voici les réglages modifiés par set-language-environment pour la valeur
French (extrait de language-info-alist) :

,----
| ("French"
| (documentation . "This language environment is almost the same as
| Latin-1,nbut it selects the French tutorial and input method.")
| (sample-text . "French (Français) Bonjour, Salut")
| (input-method . "latin-1-prefix")
| (unibyte-display . iso-latin-1)
| (unibyte-syntax . "latin-1")
| (nonascii-translation . latin-iso8859-1)
| (coding-priority iso-latin-1)
| (coding-system iso-latin-1 iso-latin-9)
| (charset ascii latin-iso8859-1)
| (tutorial . "TUTORIAL.fr"))
`----

Tu peux voir que notamment le coding system est positionné. Chez moi
comme j'utilise l'iso-8859-15 (entre autres pour l'euro, mes locales
sont positionnées sur fr_FR@euro) je rajoute après le
set-language-environment un (prefer-coding-system 'latin-9)

---------------

Les trois premières lignes m'ont été recommandé par Sébastien le
12/9 pour un problème de multipart avec gnus qui achève de me
décourager.

Les caractères saccagés ci-dessus le sont parce que j'ai voulu changer
"French" par 'French dans la quatrième ligne de code de l'extrait de
.emacs, j'ai fermé et rouvert ce fichier, qui est apparu comrompu ;
j'ai remis language-environment sur "French" mais le fichier est
irrécupérable...

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.

De même tu peux forcer l'encodage pour les enregistrement suivants avec
C-x RET f ou encore C-x RET c avant le C-x C-s

J'ai consulté déjà à moult reprise la page de Matthieu qui ne m'a pas
permis de fixer le problème.

La manifestation la plus fréquente du pb est qu'à partir d'un certain
moment de l'édition du fichier, "C-x s" produit l'affichage de ce
message dans le mini buffer :

Select coding system (default raw-text):

et l'affichage d'un buffer-pop up :

These default coding systems were tried:
iso-latin-1-dos mule-utf-8
However, none of them safely encodes the target text.

Si tu es sous win, il est possible que le keyboard-coding-system que tu
as défini entre en conflit avec les caractères utilisés par le système
qui n'est pas du latin-1 ou 9 mais sjmsb plutôt du cp-1251 et/ou de
l'utf-8/utf16 (je n'ai pas de windows sous la main pour vérifier).

Select one of the following safe coding systems:
raw-text emacs-mule no-conversion

Il n'y a aucun caractère hors de l'iso-8859-1 dans mon
buffer. J'ai réussi à observer un cas précis : dans un buffer vierge
"Il n'y a rien de" ne pose pas de pb mais "sûr" en pose un ; qui plus
est, le coup d'après, les mêmes caractères passent sans problème ;
enfin à chaque fois qu'apparaît ce message, il suffit de répéter "C-x
s" et à la quatrième tentative le buffer est écrit... bref je n'y
comprends absolument rien.

Peut-être que tu crois que c'est de l'iso-8859-1 mais pour t'en assurer
il faut vérifier le buffer-file-coding-system 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. M-x describe-coding-system
peut aussi aider.

[...]

Bref, toute aide bienvenue !

On va essayer :)


Footnotes:
[1] si tu es sous win, tu peux trouver une version cvs pré-compilée et
pas trop ancienne sur http://crasseux.com/emacs/

--
Sébastien Kirche

Sébastien Kirche a écrit :

> (require 'ucs-tables)
> (unify-8859-on-encoding-mode t)
> (unify-8859-on-decoding-mode t)
>
> (set-language-environment "French")
> (prefer-coding-system 'iso-8859-1)
> (set-w32-system-coding-system (quote iso-8859-1))
> (setq current-language-environment (quote latin-1))
> (setq default-buffer-file-coding-system 'latin-1-dos)
> ;; pour nxml
> (setq buffer-file-coding-system 'latin-1-dos)
> (set-keyboard-coding-system (quote latin-1-dos))
> (setq keyboard-coding-system (quote latin-1-dos))
> (setq terminal-coding-system (quote latin-1-dos))

Est-ce que tu pourrais préciser ta plate-forme et tes locales ?

C'est bien un Windows (XP).

Il s'agit de l'emacs « GNU Emacs 21.3.1 (i386-msvc-nt5.1.2600) of
2003-03-28 on buffy ».

Gnus v5.9.0

Il semble aussi que tu utilises un ancien gnus sur un emacs 21.3.
Peut-être que la mise à jour d'emacs vers une version plus récente
(21.4 ou cvs[1]) ansi que gnus pourrait aider à régler des problèmes
? Il me semble que depuis ces versions pas mal de corrections ont
été apportés.

Effectivement. Je n'aurais pas pû il y a quelque temps, parce que
j'utilise le paquetage de la TEI, où plein de ressources (modes emacs
et matéoriel TEI sont inclus). Maintenant je saurais recomposer cet
environnement de travail. Il y a aussi un paquetage plus récent sur le
site de la TEI. 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.

Il faut savoir que set-language-environment prépositionne un certain
nombre de réglages, aussi je me demande si les réglages suivants
n'embrouillent pas les réglages.

Voici les réglages modifiés par set-language-environment pour la valeur
French (extrait de language-info-alist) :

,----
| ("French"
| (documentation . "This language environment is almost the same as
| Latin-1,nbut it selects the French tutorial and input method.")
| (sample-text . "French (Français) Bonjour, Salut")
| (input-method . "latin-1-prefix")
| (unibyte-display . iso-latin-1)
| (unibyte-syntax . "latin-1")
| (nonascii-translation . latin-iso8859-1)
| (coding-priority iso-latin-1)
| (coding-system iso-latin-1 iso-latin-9)
| (charset ascii latin-iso8859-1)
| (tutorial . "TUTORIAL.fr"))
`----

Tu peux voir que notamment le coding system est positionné. Chez
moi comme j'utilise l'iso-8859-15 (entre autres pour l'euro, mes
locales sont positionnées sur fr_FR@euro) je rajoute après le
set-language-environment un (prefer-coding-system 'latin-9)

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 ?

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 ?

Si tu es sous win, il est possible que le keyboard-coding-system que
tu as défini entre en conflit avec les caractères utilisés par le
système qui n'est pas du latin-1 ou 9 mais sjmsb plutôt du cp-1251
et/ou de l'utf-8/utf16 (je n'ai pas de windows sous la main pour
vérifier).

J'ai tout viré, excepté :

(require 'ucs-tables)
(unify-8859-on-encoding-mode t)
(unify-8859-on-decoding-mode t)

(set-language-environment "French")
(prefer-coding-system 'iso-8859-1)

;; pour nxml
(setq buffer-file-coding-system 'latin-1-dos)

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.

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). 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 !

> Select one of the following safe coding systems: raw-text
> emacs-mule no-conversion
>
> Il n'y a aucun caractère hors de l'iso-8859-1 dans mon
> buffer. J'ai réussi à observer un cas précis : dans un buffer
> vierge "Il n'y a rien de" ne pose pas de pb mais "sûr" en pose un
> ; qui plus est, le coup d'après, les mêmes caractères passent sans
> problème ; enfin à chaque fois qu'apparaît ce message, il suffit
> de répéter "C-x s" et à la quatrième tentative le buffer est
> écrit... bref je n'y comprends absolument rien.

Peut-être que tu crois que c'est de l'iso-8859-1 mais pour t'en assurer
il faut vérifier le buffer-file-coding-system

Ne semble pas exister chez moi.

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
(Right-Hand Part of Latin Alphabet 1 (ISO/IEC 8859-1): ISO-IR-100)
code point: 96
syntax: word
category: l:Latin
buffer code: 0x81 0xE0
file code: E0 (encoded by coding system iso-latin-1)
font:
-outline-Courier New-normal-r-normal-normal-13-97-96-96-c-80-iso8859-1

----

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.

M-x describe-coding-system peut aussi aider.

Oui, je l'utilise à chaque fois pour avoir l'encodage.

> Bref, toute aide bienvenue !

On va essayer :)

Merci, mais c'est pas gagné je crains :-). J'avoue que je suis
immensément découragé et lassé par tout ces problèmes, je n'ai jamais
vu (dans les 10 dernières années, j'avoue !) un éditeur avoir autant
de difficultés à reconnaître l'encodage.

Footnotes:
[1] si tu es sous win, tu peux trouver une version cvs pré-compilée et
pas trop ancienne sur http://crasseux.com/emacs/

Bon, j'essaye.

Sébastien Kirche a écrit :

[1] si tu es sous win, tu peux trouver une version cvs pré-compilée et
pas trop ancienne sur http://crasseux.com/emacs/

Installé. Les problèmes d'encodage ne se sont pas (encore)
manifestés. Ils se reposent sans doute. Reste à adapter le .emacs...

Une nouveauté de ce gnus : la photo de contributeurs dans le champs
"From". Quelle horreur !

Le 14 September 2005 à 17:09, SL a dit :

Sébastien Kirche a écrit :

> [1] si tu es sous win, tu peux trouver une version cvs pré-compilée
> et
> pas trop ancienne sur http://crasseux.com/emacs/

Installé. Les problèmes d'encodage ne se sont pas (encore)
manifestés. Ils se reposent sans doute.

Tu veux dire que tu n'as pas de problème avec cette version en éditant
tes fichiers de la même façon ?

Reste à adapter le .emacs...

Des messages d'erreur au lancement ?

Une nouveauté de ce gnus : la photo de contributeurs dans le champs
"From". Quelle horreur !

Non mais, c'est pas sympa ! :P

(setq gnus-treat-display-x-face nil) dans ton .gnus devrait te faire
retrouver la sérénité.

--
Sébastien Kirche