Certains se souviennent peut-être d'une discussion d'il y a
quelques mois, concernant MML. Ce package de Gnus permet
d'ajouter des parties dans un certain type à un message, juste en
utilisant 'C-c <RET> p' dans un buffer en Message Mode.
Cette partie du message, à la lecture, est alors font lockée en
fonction du type. Par exemple selon le mode Emacs Lisp pour les
partie de type "application/emacs-lisp", etc.
Ce qui apparaissait comme une fonctionalité intéressante s'est
révélé inutilisable, car Gnus génère alors un article en
multi-part, illisible par certains, en particulier Google Groups.
Je viens d'écrire un petit package utilisant la même idée, mais
ne générant pas de multi-part. Il laisse les balises telles
quelles à l'envoit, et les décode à la lecture.
Si l'on utilise le package à la lecture, on se retrouve alors
bien avec des parties de texte font lockées selon le type, sinon
on voit simplement les balises. C'est ÀMHA un bon compromis.
Voici par exemple des screenshots de Gnus montrant un tel
article font locké pour l'un, et raw pour l'autre :
Ahem, effectivement. Comme je rédigeais l'article dans Gnus, j'ai attendu de poster pour vite faire les deux screenshots et les uploader. Deux minutes de manip'.
On peut dire que t'es rapide :-)
Désolé, c'est réglé. Par contre, pour la passerelle web pour le CVS, il faut généralement attendre un peu sur SF.net. Mais le 'cvs(1)' doit fonctionner.
Ahem, effectivement. Comme je rédigeais l'article dans Gnus,
j'ai attendu de poster pour vite faire les deux screenshots et
les uploader. Deux minutes de manip'.
On peut dire que t'es rapide :-)
Désolé, c'est réglé. Par contre, pour la passerelle web pour
le CVS, il faut généralement attendre un peu sur SF.net. Mais le
'cvs(1)' doit fonctionner.
Ahem, effectivement. Comme je rédigeais l'article dans Gnus, j'ai attendu de poster pour vite faire les deux screenshots et les uploader. Deux minutes de manip'.
On peut dire que t'es rapide :-)
Désolé, c'est réglé. Par contre, pour la passerelle web pour le CVS, il faut généralement attendre un peu sur SF.net. Mais le 'cvs(1)' doit fonctionner.
Merci,
--drkm
Xavier Maillard
On 17 Jul 2005, drkm wrote:
Voici par exemple des screenshots de Gnus montrant un tel article font locké pour l'un, et raw pour l'autre :
Ahem, effectivement. Comme je rédigeais l'article dans Gnus, j'ai attendu de poster pour vite faire les deux screenshots et les uploader. Deux minutes de manip'.
On peut dire que t'es rapide :-)
Daisolai :) En fait je suis en train de me péter les neurones à essayer d'utiliser le paquet xml.el depuis le début de la journée /o
Désolé, c'est réglé. Par contre, pour la passerelle web pour le CVS, il faut généralement attendre un peu sur SF.net. Mais le 'cvs(1)' doit fonctionner.
Qu'est-ce dont que ce 'cvs(1)' ? (chez moi ça ouvre une page de manuel et je ne suis pas sûr que c'est ce que tu voulais faire). -- Hacker Wonderland Xavier Maillard| "Stand Back! I'm a programmer!" .0. | ..0 (+33) 326 770 221 | Webmaster, emacsfr.org 000 PGP : 0x1E028EA5 | Membre de l' APRIL
Ahem, effectivement. Comme je rédigeais l'article dans Gnus,
j'ai attendu de poster pour vite faire les deux screenshots et
les uploader. Deux minutes de manip'.
On peut dire que t'es rapide :-)
Daisolai :) En fait je suis en train de me péter les neurones à
essayer d'utiliser le paquet xml.el depuis le début de la journée
/o
Désolé, c'est réglé. Par contre, pour la passerelle web pour le
CVS, il faut généralement attendre un peu sur SF.net. Mais le
'cvs(1)' doit fonctionner.
Qu'est-ce dont que ce 'cvs(1)' ? (chez moi ça ouvre une page de
manuel et je ne suis pas sûr que c'est ce que tu voulais faire).
--
Hacker Wonderland Xavier Maillard| "Stand Back! I'm a programmer!"
.0. zedek@gnu-rox.orgz|
..0 (+33) 326 770 221 | Webmaster, emacsfr.org
000 PGP : 0x1E028EA5 | Membre de l' APRIL
Ahem, effectivement. Comme je rédigeais l'article dans Gnus, j'ai attendu de poster pour vite faire les deux screenshots et les uploader. Deux minutes de manip'.
On peut dire que t'es rapide :-)
Daisolai :) En fait je suis en train de me péter les neurones à essayer d'utiliser le paquet xml.el depuis le début de la journée /o
Désolé, c'est réglé. Par contre, pour la passerelle web pour le CVS, il faut généralement attendre un peu sur SF.net. Mais le 'cvs(1)' doit fonctionner.
Qu'est-ce dont que ce 'cvs(1)' ? (chez moi ça ouvre une page de manuel et je ne suis pas sûr que c'est ce que tu voulais faire). -- Hacker Wonderland Xavier Maillard| "Stand Back! I'm a programmer!" .0. | ..0 (+33) 326 770 221 | Webmaster, emacsfr.org 000 PGP : 0x1E028EA5 | Membre de l' APRIL
drkm
Xavier Maillard writes:
On 17 Jul 2005, drkm wrote:
Daisolai :) En fait je suis en train de me péter les neurones à essayer d'utiliser le paquet xml.el depuis le début de la journée
Tiens, aurait-ce un quelconque rapport avec Muse, Planner ou apparenté ? À tout hasard avec la génération de Muse XML ?-)
Au fait, quels sont les problèmes que tu rencontres ? Je n'ai jamais utilisé ce package, mais d'après un rapide coup d'oeil à emacswiki, il ne semble pas bien compliqué (c'est toujours comme ça après un rapide coup d'oeil). Il semble dans la même veine que DOM.
Mais peut-être as-tu fait des recherches et trouvé une implémentation SAX-like. Ça doit bien exister, et c'est souvent plus simple (ça dépend de l'utilisation, évidemment).
Il y a aussi xmltok de James Clark, dans nXML, mais ÀMHA, ce n'est pas des plus simples en première approche. C'est très orienté analyse incrémentale.
Désolé, c'est réglé. Par contre, pour la passerelle web pour le CVS, il faut généralement attendre un peu sur SF.net. Mais le 'cvs(1)' doit fonctionner.
Qu'est-ce dont que ce 'cvs(1)' ? (chez moi ça ouvre une page de manuel et je ne suis pas sûr que c'est ce que tu voulais faire).
Disons que je ne voulais pas spécialement ouvrir de man page chez toi, mais c'était une façon de nommer le client CVS. Les man pages sont référencées de cette manière (je suppose que tu connais :-p), et le fait d'utiliser un (1) référence donc souvent un programme utilisateur.
Donc pour la passerelle web, il faut normalement attendre, mais tu peux utiliser ton client CVS favorit pour obtenir dès maintenant le fichier.
Ou tiens, je les place (avant de poster :-p) sur :
Daisolai :) En fait je suis en train de me péter les neurones à
essayer d'utiliser le paquet xml.el depuis le début de la journée
Tiens, aurait-ce un quelconque rapport avec Muse, Planner ou
apparenté ? À tout hasard avec la génération de Muse XML ?-)
Au fait, quels sont les problèmes que tu rencontres ? Je n'ai
jamais utilisé ce package, mais d'après un rapide coup d'oeil à
emacswiki, il ne semble pas bien compliqué (c'est toujours comme
ça après un rapide coup d'oeil). Il semble dans la même veine
que DOM.
Mais peut-être as-tu fait des recherches et trouvé une
implémentation SAX-like. Ça doit bien exister, et c'est souvent
plus simple (ça dépend de l'utilisation, évidemment).
Il y a aussi xmltok de James Clark, dans nXML, mais ÀMHA, ce
n'est pas des plus simples en première approche. C'est très
orienté analyse incrémentale.
Désolé, c'est réglé. Par contre, pour la passerelle web pour le
CVS, il faut généralement attendre un peu sur SF.net. Mais le
'cvs(1)' doit fonctionner.
Qu'est-ce dont que ce 'cvs(1)' ? (chez moi ça ouvre une page de
manuel et je ne suis pas sûr que c'est ce que tu voulais faire).
Disons que je ne voulais pas spécialement ouvrir de man page
chez toi, mais c'était une façon de nommer le client CVS. Les
man pages sont référencées de cette manière (je suppose que tu
connais :-p), et le fait d'utiliser un (1) référence donc souvent
un programme utilisateur.
Donc pour la passerelle web, il faut normalement attendre, mais
tu peux utiliser ton client CVS favorit pour obtenir dès
maintenant le fichier.
Ou tiens, je les place (avant de poster :-p) sur :
Daisolai :) En fait je suis en train de me péter les neurones à essayer d'utiliser le paquet xml.el depuis le début de la journée
Tiens, aurait-ce un quelconque rapport avec Muse, Planner ou apparenté ? À tout hasard avec la génération de Muse XML ?-)
Au fait, quels sont les problèmes que tu rencontres ? Je n'ai jamais utilisé ce package, mais d'après un rapide coup d'oeil à emacswiki, il ne semble pas bien compliqué (c'est toujours comme ça après un rapide coup d'oeil). Il semble dans la même veine que DOM.
Mais peut-être as-tu fait des recherches et trouvé une implémentation SAX-like. Ça doit bien exister, et c'est souvent plus simple (ça dépend de l'utilisation, évidemment).
Il y a aussi xmltok de James Clark, dans nXML, mais ÀMHA, ce n'est pas des plus simples en première approche. C'est très orienté analyse incrémentale.
Désolé, c'est réglé. Par contre, pour la passerelle web pour le CVS, il faut généralement attendre un peu sur SF.net. Mais le 'cvs(1)' doit fonctionner.
Qu'est-ce dont que ce 'cvs(1)' ? (chez moi ça ouvre une page de manuel et je ne suis pas sûr que c'est ce que tu voulais faire).
Disons que je ne voulais pas spécialement ouvrir de man page chez toi, mais c'était une façon de nommer le client CVS. Les man pages sont référencées de cette manière (je suppose que tu connais :-p), et le fait d'utiliser un (1) référence donc souvent un programme utilisateur.
Donc pour la passerelle web, il faut normalement attendre, mais tu peux utiliser ton client CVS favorit pour obtenir dès maintenant le fichier.
Ou tiens, je les place (avant de poster :-p) sur :
J'aime bien le principe et puis si en plus ça peut nous permettre d'utiliser cette super fonctionnalité, je dis "je veux".
Chouette :-)
Si j'étais toi, j'enverrais ça sur la liste de développement de Gnus pour inclusion immédiate ! :)
Hum. Je ne sais pas si ce code en vaut la peine. Pas en l'état actuel. Mais sur l'idée, sans doute. En fait, je pense que MML pourrait être modifié pour pouvoir choisir, d'après un defcustom, de générer du multi-part ou de laisser le markup (et de le décoder à la lecture).
/me content de ne plus devoir mettre de ';;; lisp code' ...
Disons que pour toi, c'est plus facile, car il y a les commandes qui vont bien dans *followup to ...*, pour les personnes qui utilisent drkm-mml, ben c'est mieux, et pour les autres, ";;; lisp code" ou "<!#part ...", c'est pas très différent.
Appréciation toute subjective, évidemment :-)
Merci,
--drkm
Xavier Maillard writes:
J'aime bien le principe et puis si en plus ça peut nous permettre
d'utiliser cette super fonctionnalité, je dis "je veux".
Chouette :-)
Si j'étais toi, j'enverrais ça sur la liste de développement de
Gnus pour inclusion immédiate ! :)
Hum. Je ne sais pas si ce code en vaut la peine. Pas en
l'état actuel. Mais sur l'idée, sans doute. En fait, je pense
que MML pourrait être modifié pour pouvoir choisir, d'après un
defcustom, de générer du multi-part ou de laisser le markup (et
de le décoder à la lecture).
/me content de ne plus devoir mettre de ';;; lisp code' ...
Disons que pour toi, c'est plus facile, car il y a les
commandes qui vont bien dans *followup to ...*, pour les
personnes qui utilisent drkm-mml, ben c'est mieux, et pour les
autres, ";;; lisp code" ou "<!#part ...", c'est pas très
différent.
J'aime bien le principe et puis si en plus ça peut nous permettre d'utiliser cette super fonctionnalité, je dis "je veux".
Chouette :-)
Si j'étais toi, j'enverrais ça sur la liste de développement de Gnus pour inclusion immédiate ! :)
Hum. Je ne sais pas si ce code en vaut la peine. Pas en l'état actuel. Mais sur l'idée, sans doute. En fait, je pense que MML pourrait être modifié pour pouvoir choisir, d'après un defcustom, de générer du multi-part ou de laisser le markup (et de le décoder à la lecture).
/me content de ne plus devoir mettre de ';;; lisp code' ...
Disons que pour toi, c'est plus facile, car il y a les commandes qui vont bien dans *followup to ...*, pour les personnes qui utilisent drkm-mml, ben c'est mieux, et pour les autres, ";;; lisp code" ou "<!#part ...", c'est pas très différent.
Appréciation toute subjective, évidemment :-)
Merci,
--drkm
Sébastien Kirche
Le 17 juillet 2005 à 02:07, drkm a dit :
Mais le 'cvs(1)' doit fonctionner.
C'est drkm-lib/file-style/file-style.el qu'il faut reprendre je suppose.
Est-ce que c'est indépendant ou ça appelle d'autres modules de tes libs ?
-- Sébastien Kirche
Le 17 juillet 2005 à 02:07, drkm a dit :
Mais le 'cvs(1)' doit fonctionner.
C'est drkm-lib/file-style/file-style.el qu'il faut reprendre je suppose.
Est-ce que c'est indépendant ou ça appelle d'autres modules de tes
libs ?
C'est drkm-lib/file-style/file-style.el qu'il faut reprendre je suppose.
Est-ce que c'est indépendant ou ça appelle d'autres modules de tes libs ?
-- Sébastien Kirche
drkm
Sébastien Kirche writes:
Le 17 juillet 2005 à 02:07, drkm a dit :
Mais le 'cvs(1)' doit fonctionner.
C'est drkm-lib/file-style/file-style.el qu'il faut reprendre je suppose.
Oops. J'ai oublié de préciser : drkm-lib/drkm/drkm-mml.el.
Est-ce que c'est indépendant ou ça appelle d'autres modules de tes libs ?
Normalement non. J'ai juste :
(require 'mailcap)
qui est un module de Gnus, donc normalement disponible si on utilise drkm MML ;-). D'ailleurs, ça n'a rien à faire dans drkm-lib/drkm, ça devrait plutôt être un package indépendant. Lorsque l'on en avait parlé il y a quelques mois, j'avais créé ce fichier machinalement dans drkm-lib/drkm.
En fait, la structure devrait elle-même changer. De :
drkm-lib/drkm drkm-lib/file-styles
je devrais passer à :
drkm-lib file-styles
tout simplement.
Donc pour répondre à ta question, le commentaire au début de drkm-mml.el doit être suffisant pour l'installer : il doit être dans le 'load-path', et soit tu charges le 'loaddefs.el' du même répertoire, soit tu te contentes d'un '(require 'drkm-mml)' (ce qui est acceptable dans ~/.gnus.el, il est assez petit).
Les File Styles, c'est encore autre chose :-). C'est un peu le même principe que les styles de CC Mode : tu attribues un style (un nom) dans les File Local Variables à la fin de ton fichier, et certaines valeurs et/ou comportement sont sécialisés pour ce style.
Et cela au moyen de EIEIO, donc orienté-objet. Lorsque tu définis un nouveau style, tu hérites d'un style existant, et tu spécialises certaines méthodes, en fonction de ce que tu veux faire.
J'ai par exemple utilisé cela pour personaliser les impressions par PS Print de mes code sources. Il y avait trop de paramètres à modifier à chaque impression lorsque je passais de projets persos à des projets en commun pour mes cours ou des impressions de brouillons dans le cadre de mon stage.
Avec les File Styles, je modifiais juste le style du fichier, au choix :
;; drkm-style: drkm
ou :
;; drkm-style: ipl
ou :
;; drkm-style: cern
Il faut alors définir le style, par exemple 'cern', dans un fichier cern-fstyle.el dans le 'load-path' :
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; File: cern-fstyle.el ;; ;; Author: F. Georges ;; ;; Date: 2005-02-24 ;; ;; Tags: ;; ;; Attrs: ;; ;; Copyright (c) 2005 Florent Georges ;; ;; --------------------------------------------------------- ;;
Plutôt sympa ;-). Mais comme d'hab', le module a besoin d'un petit nettoyage, et surtout manque de doc' :-(.
--drkm
Sébastien Kirche writes:
Le 17 juillet 2005 à 02:07, drkm a dit :
Mais le 'cvs(1)' doit fonctionner.
C'est drkm-lib/file-style/file-style.el qu'il faut reprendre je suppose.
Oops. J'ai oublié de préciser : drkm-lib/drkm/drkm-mml.el.
Est-ce que c'est indépendant ou ça appelle d'autres modules de tes
libs ?
Normalement non. J'ai juste :
(require 'mailcap)
qui est un module de Gnus, donc normalement disponible si on
utilise drkm MML ;-). D'ailleurs, ça n'a rien à faire dans
drkm-lib/drkm, ça devrait plutôt être un package indépendant.
Lorsque l'on en avait parlé il y a quelques mois, j'avais créé ce
fichier machinalement dans drkm-lib/drkm.
En fait, la structure devrait elle-même changer. De :
drkm-lib/drkm
drkm-lib/file-styles
je devrais passer à :
drkm-lib
file-styles
tout simplement.
Donc pour répondre à ta question, le commentaire au début de
drkm-mml.el doit être suffisant pour l'installer : il doit être
dans le 'load-path', et soit tu charges le 'loaddefs.el' du même
répertoire, soit tu te contentes d'un '(require 'drkm-mml)' (ce
qui est acceptable dans ~/.gnus.el, il est assez petit).
Les File Styles, c'est encore autre chose :-). C'est un peu le
même principe que les styles de CC Mode : tu attribues un style
(un nom) dans les File Local Variables à la fin de ton fichier,
et certaines valeurs et/ou comportement sont sécialisés pour ce
style.
Et cela au moyen de EIEIO, donc orienté-objet. Lorsque tu
définis un nouveau style, tu hérites d'un style existant, et tu
spécialises certaines méthodes, en fonction de ce que tu veux
faire.
J'ai par exemple utilisé cela pour personaliser les impressions
par PS Print de mes code sources. Il y avait trop de paramètres
à modifier à chaque impression lorsque je passais de projets
persos à des projets en commun pour mes cours ou des impressions
de brouillons dans le cadre de mon stage.
Avec les File Styles, je modifiais juste le style du fichier,
au choix :
;; drkm-style: drkm
ou :
;; drkm-style: ipl
ou :
;; drkm-style: cern
Il faut alors définir le style, par exemple 'cern', dans un
fichier cern-fstyle.el dans le 'load-path' :
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; File: cern-fstyle.el ;;
;; Author: F. Georges ;;
;; Date: 2005-02-24 ;;
;; Tags: ;;
;; Attrs: ;;
;; Copyright (c) 2005 Florent Georges ;;
;; --------------------------------------------------------- ;;
C'est drkm-lib/file-style/file-style.el qu'il faut reprendre je suppose.
Oops. J'ai oublié de préciser : drkm-lib/drkm/drkm-mml.el.
Est-ce que c'est indépendant ou ça appelle d'autres modules de tes libs ?
Normalement non. J'ai juste :
(require 'mailcap)
qui est un module de Gnus, donc normalement disponible si on utilise drkm MML ;-). D'ailleurs, ça n'a rien à faire dans drkm-lib/drkm, ça devrait plutôt être un package indépendant. Lorsque l'on en avait parlé il y a quelques mois, j'avais créé ce fichier machinalement dans drkm-lib/drkm.
En fait, la structure devrait elle-même changer. De :
drkm-lib/drkm drkm-lib/file-styles
je devrais passer à :
drkm-lib file-styles
tout simplement.
Donc pour répondre à ta question, le commentaire au début de drkm-mml.el doit être suffisant pour l'installer : il doit être dans le 'load-path', et soit tu charges le 'loaddefs.el' du même répertoire, soit tu te contentes d'un '(require 'drkm-mml)' (ce qui est acceptable dans ~/.gnus.el, il est assez petit).
Les File Styles, c'est encore autre chose :-). C'est un peu le même principe que les styles de CC Mode : tu attribues un style (un nom) dans les File Local Variables à la fin de ton fichier, et certaines valeurs et/ou comportement sont sécialisés pour ce style.
Et cela au moyen de EIEIO, donc orienté-objet. Lorsque tu définis un nouveau style, tu hérites d'un style existant, et tu spécialises certaines méthodes, en fonction de ce que tu veux faire.
J'ai par exemple utilisé cela pour personaliser les impressions par PS Print de mes code sources. Il y avait trop de paramètres à modifier à chaque impression lorsque je passais de projets persos à des projets en commun pour mes cours ou des impressions de brouillons dans le cadre de mon stage.
Avec les File Styles, je modifiais juste le style du fichier, au choix :
;; drkm-style: drkm
ou :
;; drkm-style: ipl
ou :
;; drkm-style: cern
Il faut alors définir le style, par exemple 'cern', dans un fichier cern-fstyle.el dans le 'load-path' :
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; File: cern-fstyle.el ;; ;; Author: F. Georges ;; ;; Date: 2005-02-24 ;; ;; Tags: ;; ;; Attrs: ;; ;; Copyright (c) 2005 Florent Georges ;; ;; --------------------------------------------------------- ;;
Plutôt sympa ;-). Mais comme d'hab', le module a besoin d'un petit nettoyage, et surtout manque de doc' :-(.
--drkm
drkm
drkm writes:
Il faut alors définir le style, par exemple 'cern', dans un fichier cern-fstyle.el dans le 'load-path' :
Oops, je n'ai même pas profité de cet exemple, dans ce thread, pour utiliser MML. Je me répète ici, pour que ceux qui essayent drkm-mml.el puissent tester le décodage.
Désolé pour le bruit :-(
<!#part type=application/emacs-lisp>
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; File: cern-fstyle.el ;; ;; Author: F. Georges ;; ;; Date: 2005-02-24 ;; ;; Tags: ;; ;; Attrs: ;; ;; Copyright (c) 2005 Florent Georges ;; ;; --------------------------------------------------------- ;;
Il faut alors définir le style, par exemple 'cern', dans un
fichier cern-fstyle.el dans le 'load-path' :
Oops, je n'ai même pas profité de cet exemple, dans ce thread,
pour utiliser MML. Je me répète ici, pour que ceux qui essayent
drkm-mml.el puissent tester le décodage.
Désolé pour le bruit :-(
<!#part type=application/emacs-lisp>
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; File: cern-fstyle.el ;;
;; Author: F. Georges ;;
;; Date: 2005-02-24 ;;
;; Tags: ;;
;; Attrs: ;;
;; Copyright (c) 2005 Florent Georges ;;
;; --------------------------------------------------------- ;;
Il faut alors définir le style, par exemple 'cern', dans un fichier cern-fstyle.el dans le 'load-path' :
Oops, je n'ai même pas profité de cet exemple, dans ce thread, pour utiliser MML. Je me répète ici, pour que ceux qui essayent drkm-mml.el puissent tester le décodage.
Désolé pour le bruit :-(
<!#part type=application/emacs-lisp>
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; File: cern-fstyle.el ;; ;; Author: F. Georges ;; ;; Date: 2005-02-24 ;; ;; Tags: ;; ;; Attrs: ;; ;; Copyright (c) 2005 Florent Georges ;; ;; --------------------------------------------------------- ;;
> Il faut alors définir le style, par exemple 'cern', dans un > fichier cern-fstyle.el dans le 'load-path' :
Oops, je n'ai même pas profité de cet exemple, dans ce thread, pour utiliser MML. Je me répète ici, pour que ceux qui essayent drkm-mml.el puissent tester le décodage.
> Il faut alors définir le style, par exemple 'cern', dans un
> fichier cern-fstyle.el dans le 'load-path' :
Oops, je n'ai même pas profité de cet exemple, dans ce thread,
pour utiliser MML. Je me répète ici, pour que ceux qui essayent
drkm-mml.el puissent tester le décodage.
> Il faut alors définir le style, par exemple 'cern', dans un > fichier cern-fstyle.el dans le 'load-path' :
Oops, je n'ai même pas profité de cet exemple, dans ce thread, pour utiliser MML. Je me répète ici, pour que ceux qui essayent drkm-mml.el puissent tester le décodage.
