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
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.
C'est peut-être le mieux à faire. Comme l'a dit Sébastien, il y a eu pas mal de modifications depuis la 21.3. Je te conseille comme lui d'essayer la version compilée disponible sur crasseux. Elle date d'avril, mais c'est déjà bien mieux que la 21.3, ÀMHA.
Installe-le indépendamment et regarde si cela règle tes problèmes d'encodage. Si c'est le cas, tu peux essayer de recomposer toi-même l'environnement fournit par TEI-Emacs. Au fait, il propose quoi, exactement ?
--drkm
SL writes:
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.
C'est peut-être le mieux à faire. Comme l'a dit Sébastien, il
y a eu pas mal de modifications depuis la 21.3. Je te conseille
comme lui d'essayer la version compilée disponible sur crasseux.
Elle date d'avril, mais c'est déjà bien mieux que la 21.3, ÀMHA.
Installe-le indépendamment et regarde si cela règle tes
problèmes d'encodage. Si c'est le cas, tu peux essayer de
recomposer toi-même l'environnement fournit par TEI-Emacs. Au
fait, il propose quoi, exactement ?
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.
C'est peut-être le mieux à faire. Comme l'a dit Sébastien, il y a eu pas mal de modifications depuis la 21.3. Je te conseille comme lui d'essayer la version compilée disponible sur crasseux. Elle date d'avril, mais c'est déjà bien mieux que la 21.3, ÀMHA.
Installe-le indépendamment et regarde si cela règle tes problèmes d'encodage. Si c'est le cas, tu peux essayer de recomposer toi-même l'environnement fournit par TEI-Emacs. Au fait, il propose quoi, exactement ?
--drkm
drkm
SL writes:
Une nouveauté de ce gnus : la photo de contributeurs dans le champs "From". Quelle horreur !
Une horreur ? Qui ?-)
--drkm
SL writes:
Une nouveauté de ce gnus : la photo de contributeurs dans le champs
"From". Quelle horreur !
Une nouveauté de ce gnus : la photo de contributeurs dans le champs "From". Quelle horreur !
Une horreur ? Qui ?-)
--drkm
drkm
SL writes:
Installé. Les problèmes d'encodage ne se sont pas (encore) manifestés. Ils se reposent sans doute. Reste à adapter le .emacs...
Puisque tu as créé ton ~/.emacs.el de manière réfléchie et organisée, et qu'il n'est pas le résultat d'un poids historique de copier/coller et essais/erreurs, que tu as bien isolé ce qui était spécifique à TEI-Emacs du reste, cela ne devrait pas poser de problèmes ;-)
N'hésite pas à le rendre disponible publiquement si tu as des questions et/ou des problèmes, si tu veux qu'on y jette un coup d'oeil.
--drkm
SL writes:
Installé. Les problèmes d'encodage ne se sont pas (encore)
manifestés. Ils se reposent sans doute. Reste à adapter le .emacs...
Puisque tu as créé ton ~/.emacs.el de manière réfléchie et
organisée, et qu'il n'est pas le résultat d'un poids historique
de copier/coller et essais/erreurs, que tu as bien isolé ce qui
était spécifique à TEI-Emacs du reste, cela ne devrait pas poser
de problèmes ;-)
N'hésite pas à le rendre disponible publiquement si tu as des
questions et/ou des problèmes, si tu veux qu'on y jette un coup
d'oeil.
Installé. Les problèmes d'encodage ne se sont pas (encore) manifestés. Ils se reposent sans doute. Reste à adapter le .emacs...
Puisque tu as créé ton ~/.emacs.el de manière réfléchie et organisée, et qu'il n'est pas le résultat d'un poids historique de copier/coller et essais/erreurs, que tu as bien isolé ce qui était spécifique à TEI-Emacs du reste, cela ne devrait pas poser de problèmes ;-)
N'hésite pas à le rendre disponible publiquement si tu as des questions et/ou des problèmes, si tu veux qu'on y jette un coup d'oeil.
--drkm
SL
Sébastien Kirche a écrit :
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 ?
Pas encore en effet :-) Croisons les doigts.
Reste à adapter le .emacs...
Des messages d'erreur au lancement ?
Oui, des questions de répertoires qu'il faut que je range proprement, c'est dispatché entre le répertoire de l'ancien emacs et le nouveau.
Une nouveauté de ce gnus : la photo de contributeurs dans le champs "From". Quelle horreur !
Non mais, c'est pas sympa ! :P
On se croirait sur MSN (en moins bien du coup)...
(setq gnus-treat-display-x-face nil) dans ton .gnus devrait te faire retrouver la sérénité.
Super.
Sébastien Kirche a écrit :
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 ?
Pas encore en effet :-) Croisons les doigts.
Reste à adapter le .emacs...
Des messages d'erreur au lancement ?
Oui, des questions de répertoires qu'il faut que je range proprement,
c'est dispatché entre le répertoire de l'ancien emacs et le nouveau.
Une nouveauté de ce gnus : la photo de contributeurs dans le champs
"From". Quelle horreur !
Non mais, c'est pas sympa ! :P
On se croirait sur MSN (en moins bien du coup)...
(setq gnus-treat-display-x-face nil) dans ton .gnus devrait te faire
retrouver la sérénité.
> [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 ?
Pas encore en effet :-) Croisons les doigts.
Reste à adapter le .emacs...
Des messages d'erreur au lancement ?
Oui, des questions de répertoires qu'il faut que je range proprement, c'est dispatché entre le répertoire de l'ancien emacs et le nouveau.
Une nouveauté de ce gnus : la photo de contributeurs dans le champs "From". Quelle horreur !
Non mais, c'est pas sympa ! :P
On se croirait sur MSN (en moins bien du coup)...
(setq gnus-treat-display-x-face nil) dans ton .gnus devrait te faire retrouver la sérénité.
Super.
Sébastien Kirche
Le 14 September 2005 à 16:09, SL a dit :
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.
-- Sébastien Kirche
Le 14 September 2005 à 16:09, SL a dit :
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.
-- Sébastien Kirche
SL
drkm a écrit :
Installe-le indépendamment et regarde si cela règle tes problèmes d'encodage. Si c'est le cas, tu peux essayer de recomposer toi-même l'environnement fournit par TEI-Emacs. Au fait, il propose quoi, exactement ?
Et bien disons quatre gros type de choses :
- plein de modes (xml, nxml, java (jde), auctex, etc. etc. je ne saurais pas les lister.)
- plein de matériel TEI (les DTD / Schémas, les stylesheets)
- pas mal des binaires les plus indispensables pour XML (xmllint, xsltproc, tidy, xt, saxon, jing, catalog), quelques autre (grep).
- 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.
Le tout est assez complet. Mais bon, on a vite fait d'avoir déjà tout installé par soi-même, et même configuré soigneusement ça n'en fait pas un environnement user friendly.
drkm a écrit :
Installe-le indépendamment et regarde si cela règle tes
problèmes d'encodage. Si c'est le cas, tu peux essayer de
recomposer toi-même l'environnement fournit par TEI-Emacs. Au
fait, il propose quoi, exactement ?
Et bien disons quatre gros type de choses :
- plein de modes (xml, nxml, java (jde), auctex, etc. etc. je ne
saurais pas les lister.)
- plein de matériel TEI (les DTD / Schémas, les stylesheets)
- pas mal des binaires les plus indispensables pour XML (xmllint,
xsltproc, tidy, xt, saxon, jing, catalog), quelques autre (grep).
- 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.
Le tout est assez complet. Mais bon, on a vite fait d'avoir déjà tout
installé par soi-même, et même configuré soigneusement ça n'en fait
pas un environnement user friendly.
Installe-le indépendamment et regarde si cela règle tes problèmes d'encodage. Si c'est le cas, tu peux essayer de recomposer toi-même l'environnement fournit par TEI-Emacs. Au fait, il propose quoi, exactement ?
Et bien disons quatre gros type de choses :
- plein de modes (xml, nxml, java (jde), auctex, etc. etc. je ne saurais pas les lister.)
- plein de matériel TEI (les DTD / Schémas, les stylesheets)
- pas mal des binaires les plus indispensables pour XML (xmllint, xsltproc, tidy, xt, saxon, jing, catalog), quelques autre (grep).
- 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.
Le tout est assez complet. Mais bon, on a vite fait d'avoir déjà tout installé par soi-même, et même configuré soigneusement ça n'en fait pas un environnement user friendly.
SL
drkm a écrit :
SL writes:
Une nouveauté de ce gnus : la photo de contributeurs dans le champs "From". Quelle horreur !
Une horreur ? Qui ?-)
Je suis tombé sur un gaillard en lunettes de soleil sur f.c.o.l.debats.
Finalement je vais peut être m'y faire :-)
drkm a écrit :
SL writes:
Une nouveauté de ce gnus : la photo de contributeurs dans le champs
"From". Quelle horreur !
Une horreur ? Qui ?-)
Je suis tombé sur un gaillard en lunettes de soleil sur
f.c.o.l.debats.
Une nouveauté de ce gnus : la photo de contributeurs dans le champs "From". Quelle horreur !
Une horreur ? Qui ?-)
Je suis tombé sur un gaillard en lunettes de soleil sur f.c.o.l.debats.
Finalement je vais peut être m'y faire :-)
SL
drkm a écrit :
Puisque tu as créé ton ~/.emacs.el de manière réfléchie et organisée, et qu'il n'est pas le résultat d'un poids historique de copier/coller et essais/erreurs, que tu as bien isolé ce qui était spécifique à TEI-Emacs du reste, cela ne devrait pas poser de problèmes ;-)
Hélas, il me semble au contraire me reconnaître dans la première option :-)
N'hésite pas à le rendre disponible publiquement si tu as des questions et/ou des problèmes, si tu veux qu'on y jette un coup d'oeil.
Ok, je vais toujours essayer mais je crains bien que je vais finir par recourir à vos bons conseils.
drkm a écrit :
Puisque tu as créé ton ~/.emacs.el de manière réfléchie et
organisée, et qu'il n'est pas le résultat d'un poids historique de
copier/coller et essais/erreurs, que tu as bien isolé ce qui était
spécifique à TEI-Emacs du reste, cela ne devrait pas poser de
problèmes ;-)
Hélas, il me semble au contraire me reconnaître dans la première
option :-)
N'hésite pas à le rendre disponible publiquement si tu as des
questions et/ou des problèmes, si tu veux qu'on y jette un coup
d'oeil.
Ok, je vais toujours essayer mais je crains bien que je vais finir par
recourir à vos bons conseils.
Puisque tu as créé ton ~/.emacs.el de manière réfléchie et organisée, et qu'il n'est pas le résultat d'un poids historique de copier/coller et essais/erreurs, que tu as bien isolé ce qui était spécifique à TEI-Emacs du reste, cela ne devrait pas poser de problèmes ;-)
Hélas, il me semble au contraire me reconnaître dans la première option :-)
N'hésite pas à le rendre disponible publiquement si tu as des questions et/ou des problèmes, si tu veux qu'on y jette un coup d'oeil.
Ok, je vais toujours essayer mais je crains bien que je vais finir par recourir à vos bons conseils.
drkm
SL writes:
Sébastien Kirche a écrit :
Des messages d'erreur au lancement ?
Oui, des questions de répertoires qu'il faut que je range proprement, c'est dispatché entre le répertoire de l'ancien emacs et le nouveau.
Aïe, à éviter absolument, selon moi. Je te conseille de garder deux hiérarchies bien distinctes, et de byte-compiler les fichiers avec la version à laquelle ils sont destinées. Histoire de prendre les devants sur les emmerdements.
--drkm
SL writes:
Sébastien Kirche a écrit :
Des messages d'erreur au lancement ?
Oui, des questions de répertoires qu'il faut que je range proprement,
c'est dispatché entre le répertoire de l'ancien emacs et le nouveau.
Aïe, à éviter absolument, selon moi. Je te conseille de garder
deux hiérarchies bien distinctes, et de byte-compiler les
fichiers avec la version à laquelle ils sont destinées. Histoire
de prendre les devants sur les emmerdements.
Oui, des questions de répertoires qu'il faut que je range proprement, c'est dispatché entre le répertoire de l'ancien emacs et le nouveau.
Aïe, à éviter absolument, selon moi. Je te conseille de garder deux hiérarchies bien distinctes, et de byte-compiler les fichiers avec la version à laquelle ils sont destinées. Histoire de prendre les devants sur les emmerdements.
--drkm
drkm
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
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 ?
- 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 ?
