Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Caractères accentués mal rendus lors de l'import d'une signature

11 réponses
Avatar
Eric Masson
'Lut,

Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix)

Depuis le passage d'Emacs23 à Emacs24, je rencontre un problème avec les
signatures insérées par les posting styles de Gnus.

Le code correspondant dans .gnus est le suivant :
;;
;; Signatures
;;

(defun signature-function ()
(shell-command-to-string "fortune ~/misc/fortune/Fr_sig ~/misc/fortune/glp ~/misc/fortune/gmp ~/misc/fortune/En_sig ~/misc/fortune/gnu"))

;;
;; Posting Styles
;;

(setq gnus-posting-styles
'((".*"
(signature signature-function))
))

Suite à l'exécution de signature-function, le resultat de fortune est
inséré dans le buffer, mais les éventuelles accentuées sont transcrites
sous la forme de leur code en iso8859-1 :
http://emss.free.fr/contents/Divers/emacs_gnus_sc.png

Quelqu'un aurait-il une idée pour résoudre ce petit désagrément, svp ?

Merci d'avance.

--
Et si Windows NT plante c'est que vous êtes trop débile que pour le
configurer correctement ... ou alors vous avez du matos de merde .
-+- BB in : <http://www.le-gnu.net> - Attention neuneu violeNT -+-

10 réponses

1 2
Avatar
Damien Wyart
* Eric Masson in fr.comp.applications.emacs:
Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix)
Depuis le passage d'Emacs23 à Emacs24, je rencontre un problème avec les
signatures insérées par les posting styles de Gnus.

[...]

Suite à l'exécution de signature-function, le resultat de fortune est
inséré dans le buffer, mais les éventuelles accentuées sont
transcrites sous la forme de leur code en iso8859-1 :
http://emss.free.fr/contents/Divers/emacs_gnus_sc.png



Peux-tu te placer sur un de ces caractères et faire un C-u C-x =, et
également faire un C-h C (describe-coding-system) ?

Dans tous les cas, une fois l'article posté, il s'affiche correctement
chez moi (il est bien annoncé comme du 8859-1).

Avec ça, tu peux essayer d'appeler recode-region sur la signature pour
voir si ça améliore les choses...

--
DW
Avatar
Eric Masson
Damien Wyart writes:

'Lut,

Peux-tu te placer sur un de ces caractères et faire un C-u C-x


position: 327 of 549 (59%), column: 32
character: (displayed as ) (codepoint 4194281, #o17777751, #x3fffe9)
preferred charset: eight-bit (Raw bytes 128-255)
code point in charset: 0xE9
syntax: w which means: word
category: L:Left-to-right (strong)
buffer code: #xE9
file code: not encodable by coding system utf-8-emacs
display: no font available

Character code properties: customize what to show
general-category: Cn (Other, Not Assigned)
decomposition: (4194281) ('')

There are text properties here:
fontified t

et également faire un C-h C (describe-coding-system) ?



Coding system for saving this buffer:
U -- utf-8-emacs

Default coding system (for new files):
U -- utf-8-unix (alias: mule-utf-8-unix)

Coding system for keyboard input:
U -- utf-8-unix (alias: mule-utf-8-unix)

Coding system for terminal output:
U -- utf-8-unix (alias: mule-utf-8-unix)

Coding system for inter-client cut and paste:
nil
Defaults for subprocess I/O:
decoding: U -- utf-8-unix (alias: mule-utf-8-unix)

encoding: U -- utf-8-unix (alias: mule-utf-8-unix)


Priority order for recognizing coding systems when reading files:
1. utf-8 (alias: mule-utf-8)
2. iso-latin-1 (alias: iso-8859-1 latin-1)
3. iso-2022-7bit
4. iso-2022-7bit-lock (alias: iso-2022-int-1)
5. iso-2022-8bit-ss2
6. emacs-mule
7. raw-text
8. iso-2022-jp (alias: junet)
9. in-is13194-devanagari (alias: devanagari)
10. chinese-iso-8bit (alias: cn-gb-2312 euc-china euc-cn cn-gb gb2312)
11. utf-8-auto
12. utf-8-with-signature
13. utf-16
14. utf-16be-with-signature (alias: utf-16-be)
15. utf-16le-with-signature (alias: utf-16-le)
16. utf-16be
17. utf-16le
18. japanese-shift-jis (alias: shift_jis sjis)
19. chinese-big5 (alias: big5 cn-big5 cp950)
20. undecided

Other coding systems cannot be distinguished automatically
from these, and therefore cannot be recognized automatically
with the present coding system priorities.

Particular coding systems specified for certain file names:

OPERATION TARGET PATTERN CODING SYSTEM(s)
--------- -------------- ----------------
File I/O ".dz'" (no-conversion . no-conversion)
".xz'" (no-conversion . no-conversion)
".lzma'" (no-conversion . no-conversion)
".lz'" (no-conversion . no-conversion)
".g?z'" (no-conversion . no-conversion)
".(?:tgz|svgz|sifz)'"
(no-conversion . no-conversion)
".tbz2?'" (no-conversion . no-conversion)
".bz2'" (no-conversion . no-conversion)
".Z'" (no-conversion . no-conversion)
".elc'" utf-8-emacs
".utf(-8)?'" utf-8
".xml'" xml-find-file-coding-system
"(`|/)loaddefs.el'"
(raw-text . raw-text-unix)
".tar'" (no-conversion . no-conversion)
".po[tx]?'|.po."
po-find-file-coding-system
".(tex|ltx|dtx|drv)'"
latexenc-find-file-coding-system
"" (undecided)
Process I/O nothing specified
Network I/O nothing specified

Dans tous les cas, une fois l'article posté, il s'affiche correctement
chez moi (il est bien annoncé comme du 8859-1).



C'est juste parce que j'éditais à la main :)

Avec ça, tu peux essayer d'appeler recode-region sur la signature pour
voir si ça améliore les choses...



recode-region de iso-8859-15 à utf-8-emacs donne bien le résultat
escompté.

Recoder les fichiers fortune en utf-8 est certes une solution, mais y
a-t-il moyen de faire comprendre à Emacs que le retour de fortune est en
iso-8859-15, stp ?

Merci.

--
JdC > [OUI]
CR > mais [NON] (c)
Fufage contradictoire compulsif. Il n'y a pas de remède connu.
-+- jdc in <http://www.le-gnu.net> : Un suppo et au lit -+-
Avatar
Damien Wyart
* Eric Masson in fr.comp.applications.emacs:
> Dans tous les cas, une fois l'article posté, il s'affiche correctement
> chez moi (il est bien annoncé comme du 8859-1).

C'est juste parce que j'éditais à la main :)



:)

Mais du coup, c'est bizarre que dans ton buffer Gnus tu utilises de
l'UFT8 alors qu'au final tu postes en 8859... Pourquoi ne pas switcher
le buffer en 8859 quand tu postes sur Usenet-fr ? Sinon il y a des
conversions aditionnelles qui me semble inutiles.

recode-region de iso-8859-15 à utf-8-emacs donne bien le résultat
escompté.

Recoder les fichiers fortune en utf-8 est certes une solution, mais
y a-t-il moyen de faire comprendre à Emacs que le retour de fortune
est en iso-8859-15, stp ?



Automatiser l'appel à recode-region ?

Piper la sortie de fortune dans recode ou iconv avant envoi à Emacs ?
(ca me semble la piste la plus souple)

Sinon, si ta config n'a pas changé, c'est bizarre que tu n'avais pas le
problème en Emacs 23... Est-ce que d'autres choses ont changé sur le
poste (locale par défaut...) ? Ou alors ce sont des modifs dans Gnus
mais comme je n'utilise que la version de dev je n'ai pas trop suivi ce
qui avait été intégré dans la version "bundle" d'Emacs 24.

--
DW
Avatar
Eric Masson
Damien Wyart writes:

'Re,

Mais du coup, c'est bizarre que dans ton buffer Gnus tu utilises de
l'UFT8 alors qu'au final tu postes en 8859... Pourquoi ne pas switcher
le buffer en 8859 quand tu postes sur Usenet-fr ? Sinon il y a des
conversions aditionnelles qui me semble inutiles.



Le but du jeu est de poster avec l'encodage le plus adapté au contenu.
Je ne change rien au charset par défaut, mais lors de l'envoi gnus
sélectionne l'encoding suivant les priorités définies :

(setq mm-coding-system-priorities '(iso-8859-1 iso-8859-15 utf-8))
(setq mm-body-charset-encoding-alist
'((iso-8859-1 . 8bit)
(iso-8859-15 . 8bit)
(utf-8 . 8bit)))

Automatiser l'appel à recode-region ?



Ça doit être possible, mais là, je sens poindre les limites de mes
compétences en emacs-lisp (timbre poste, dos, toussa)

Piper la sortie de fortune dans recode ou iconv avant envoi à Emacs ?
(ca me semble la piste la plus souple)



Ah, vi effectivement.

Sinon, si ta config n'a pas changé, c'est bizarre que tu n'avais pas le
problème en Emacs 23... Est-ce que d'autres choses ont changé sur le
poste (locale par défaut...) ?



Lors du passage de Free 8.3 en 9.1, j'ai retouché la classe french pour
que le shell soit par défaut en utf-8.

Après vérification, l'appel de fortune depuis un shell lancé via putty
me donne un résultat légèrement différent, mais cohérent (absence des
accentuées)

Donc, ça fait un point boulet pour ma pomme.

En tous cas, merci beaucoup pour tes explications.

--
ma reponce tu la sur ton e.mail perso
pour ne pas poluee ce forum
(suivi d'une signature de 10 lignes)
-+-Dx in GNU - Allo, voici un fax pour te rappeler de lire ton Email-+-
Avatar
Paul Gaborit
À (at) Wed, 16 Jan 2013 12:08:03 +0100,
Eric Masson écrivait (wrote):
Suite à l'exécution de signature-function, le resultat de fortune est
inséré dans le buffer, mais les éventuelles accentuées sont transcrites
sous la forme de leur code en iso8859-1 :
http://emss.free.fr/contents/Divers/emacs_gnus_sc.png

Quelqu'un aurait-il une idée pour résoudre ce petit désagrément, svp ?



Définir un locale UTF8 (du genre: LANG=fr_FR.UTF-8) ou passer l'option
'-u' à fortune...

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Avatar
Le TeXnicien de surface
Le 16/01/2013 16:05, Eric Masson a écrit :

Ah, vi effectivement.



Là, t'aggraves ton cas !

--
Le TeXnicien de surface
qui s'est dit que vendredi, finalement...
Avatar
Eric Masson
Paul Gaborit writes:

'Lut,

Définir un locale UTF8 (du genre: LANG=fr_FR.UTF-8) ou passer l'option
'-u' à fortune...



Le fortune de ma brouette ne supporte pas l'option -u (FreeBSD 9.x),
j'ai donc utilisé la solution suggérée par Damien :

(defun signature-function ()
(shell-command-to-string "fortune | iconv -f iso-8859-15 -t utf-8"))

La locale des sessions que j'ouvre sur cette machine est bien UTF-8 :
:~> env | grep UTF-8
MM_CHARSET=UTF-8
LANG=fr_FR.UTF-8

Merci.

--
A part ça, moi qui suis habitués aux PC Windows, PC Linux, PC SCO,
Atari, IBM RS/6000, SUN Sparc, ... j'ai été un peu dérouté au début.
Enfin, je m'amuse beaucoups avec... plus que mon père.
-+- KEL in Guide du Macounet Pervers : Et la lumière fut -+-
Avatar
Manuel Giraud
Eric Masson writes:

Paul Gaborit writes:

'Lut,

Définir un locale UTF8 (du genre: LANG=fr_FR.UTF-8) ou passer l'o ption
'-u' à fortune...



Le fortune de ma brouette ne supporte pas l'option -u (FreeBSD 9.x),
j'ai donc utilisé la solution suggérée par Damien :

(defun signature-function ()
(shell-command-to-string "fortune | iconv -f iso-8859-15 -t utf-8"))



Cette version sans iconv devrait marcher aussi:

(defun signature-function ()
(encode-coding-string (shell-command-to-string "fortune") 'latin-1))

--
Manuel Giraud
Avatar
Paul Gaborit
À (at) Thu, 17 Jan 2013 16:50:43 +0100,
Manuel Giraud écrivait (wrote):

Eric Masson writes:

Paul Gaborit writes:

'Lut,

Définir un locale UTF8 (du genre: LANG=fr_FR.UTF-8) ou passer l'option
'-u' à fortune...



Le fortune de ma brouette ne supporte pas l'option -u (FreeBSD 9.x),





Toutes mes condoléances... ;-)

j'ai donc utilisé la solution suggérée par Damien :
(defun signature-function ()
(shell-command-to-string "fortune | iconv -f iso-8859-15 -t utf-8"))



Cette version sans iconv devrait marcher aussi:

(defun signature-function ()
(encode-coding-string (shell-command-to-string "fortune") 'latin-1))



Ce n'est parfaitement équivalent : l'un part de iso-8859-15 et l'autre
de iso-8859-1. Il faudrait vérifier l'encodage des fichiers de fortune
utilisés (s'il y a des 'œ' ou des '€', c'est iso-8859-15).

--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Avatar
Manuel Giraud
Paul Gaborit writes:

Ce n'est parfaitement équivalent : l'un part de iso-8859-15 et l'aut re
de iso-8859-1. Il faudrait vérifier l'encodage des fichiers de fortu ne
utilisés (s'il y a des 'œ' ou des '€', c'est iso-8859-1 5).



Ah oui. Dans ce cas, on peut faire:
(defun signature-function ()
(encode-coding-string (shell-command-to-string "fortune") 'iso-8859-15))
--
Manuel Giraud
1 2