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 :
Le 31 octobre 2005 à 07:10, Romain Francoise vraute :
C'est un bug dans Emacs (déjà corrigé)
Pour info, j'ai fait un update vers 9h et je viens de recompiler : le problème semble toujours là (?) puisqu'il me parle toujours de drkm-mml.e
Entre temps j'ai changé de machine et j'ai installé drkm-mml.el sur mon G4.
Par contre ça ne semble pas stabilisé avec le test de mémoire pleine de RMS : à l'entrée dans un groupe il stoppe à la recherche d'une fonction introuvable memory-full-p
Donc je reste pour le moment sur ma version du 14/10 qui ne présente pas le bug sur le nom des module lisp.
-- Sébastien Kirche
Le 31 octobre 2005 à 07:10, Romain Francoise vraute :
C'est un bug dans Emacs (déjà corrigé)
Pour info, j'ai fait un update vers 9h et je viens de recompiler : le
problème semble toujours là (?) puisqu'il me parle toujours de
drkm-mml.e
Entre temps j'ai changé de machine et j'ai installé drkm-mml.el sur mon
G4.
Par contre ça ne semble pas stabilisé avec le test de mémoire pleine de
RMS : à l'entrée dans un groupe il stoppe à la recherche d'une fonction
introuvable memory-full-p
Donc je reste pour le moment sur ma version du 14/10 qui ne présente pas
le bug sur le nom des module lisp.
Le 31 octobre 2005 à 07:10, Romain Francoise vraute :
C'est un bug dans Emacs (déjà corrigé)
Pour info, j'ai fait un update vers 9h et je viens de recompiler : le problème semble toujours là (?) puisqu'il me parle toujours de drkm-mml.e
Entre temps j'ai changé de machine et j'ai installé drkm-mml.el sur mon G4.
Par contre ça ne semble pas stabilisé avec le test de mémoire pleine de RMS : à l'entrée dans un groupe il stoppe à la recherche d'une fonction introuvable memory-full-p
Donc je reste pour le moment sur ma version du 14/10 qui ne présente pas le bug sur le nom des module lisp.
-- Sébastien Kirche
Romain Francoise
Sébastien Kirche writes:
Pour info, j'ai fait un update vers 9h et je viens de recompiler : le problème semble toujours là (?) puisqu'il me parle toujours de drkm-mml.e
Étonnant, vu que je l'ai corrigé samedi...
Par contre ça ne semble pas stabilisé avec le test de mémoire pleine de RMS : à l'entrée dans un groupe il stoppe à la recherche d'une fonction introuvable memory-full-p
Étonnant aussi, vu qu'il n'y a aucun appel à cette fonction (qui a été effectivement supprimée) dans Emacs... tu es sûr d'avoir tout bien recompilé ?
-- Romain Francoise | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
Pour info, j'ai fait un update vers 9h et je viens de recompiler : le
problème semble toujours là (?) puisqu'il me parle toujours de
drkm-mml.e
Étonnant, vu que je l'ai corrigé samedi...
Par contre ça ne semble pas stabilisé avec le test de mémoire pleine
de RMS : à l'entrée dans un groupe il stoppe à la recherche d'une
fonction introuvable memory-full-p
Étonnant aussi, vu qu'il n'y a aucun appel à cette fonction (qui a été
effectivement supprimée) dans Emacs... tu es sûr d'avoir tout bien
recompilé ?
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
Pour info, j'ai fait un update vers 9h et je viens de recompiler : le problème semble toujours là (?) puisqu'il me parle toujours de drkm-mml.e
Étonnant, vu que je l'ai corrigé samedi...
Par contre ça ne semble pas stabilisé avec le test de mémoire pleine de RMS : à l'entrée dans un groupe il stoppe à la recherche d'une fonction introuvable memory-full-p
Étonnant aussi, vu qu'il n'y a aucun appel à cette fonction (qui a été effectivement supprimée) dans Emacs... tu es sûr d'avoir tout bien recompilé ?
-- Romain Francoise | The sea! the sea! the open it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the | ever free! --Bryan W. Procter
Sébastien Kirche
Le 31 octobre 2005 à 12:10, Romain Francoise vraute :
Sébastien Kirche writes:
> Pour info, j'ai fait un update vers 9h et je viens de recompiler : > le problème semble toujours là (?) puisqu'il me parle toujours de > drkm-mml.e
Étonnant, vu que je l'ai corrigé samedi...
M'enfin ??
C'est dans quel fichier ta correction ?
> Par contre ça ne semble pas stabilisé avec le test de mémoire pleine > de RMS : à l'entrée dans un groupe il stoppe à la recherche d'une > fonction introuvable memory-full-p
Étonnant aussi, vu qu'il n'y a aucun appel à cette fonction (qui a été effectivement supprimée) dans Emacs... tu es sûr d'avoir tout bien recompilé ?
Comprend pas : j'ai essayé sur la machine actuelle une compilation «en place» alors que d'habitude je passe par le mac/make-package qui compile tous les modules dans un répertoire temporaire. Mais avant de transférer les sources sur le G4 je suis _sûr_ d'avoir passé un coup de make maintainer-clean. Il aurait sauté ce fichier ?
Je retente un cvs up pour voir... -- Sébastien Kirche
Le 31 octobre 2005 à 12:10, Romain Francoise vraute :
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
> Pour info, j'ai fait un update vers 9h et je viens de recompiler :
> le problème semble toujours là (?) puisqu'il me parle toujours de
> drkm-mml.e
Étonnant, vu que je l'ai corrigé samedi...
M'enfin ??
C'est dans quel fichier ta correction ?
> Par contre ça ne semble pas stabilisé avec le test de mémoire pleine
> de RMS : à l'entrée dans un groupe il stoppe à la recherche d'une
> fonction introuvable memory-full-p
Étonnant aussi, vu qu'il n'y a aucun appel à cette fonction (qui a été
effectivement supprimée) dans Emacs... tu es sûr d'avoir tout bien
recompilé ?
Comprend pas : j'ai essayé sur la machine actuelle une compilation «en
place» alors que d'habitude je passe par le mac/make-package qui compile
tous les modules dans un répertoire temporaire.
Mais avant de transférer les sources sur le G4 je suis _sûr_ d'avoir passé
un coup de make maintainer-clean. Il aurait sauté ce fichier ?
Je retente un cvs up pour voir...
--
Sébastien Kirche
Le 31 octobre 2005 à 12:10, Romain Francoise vraute :
Sébastien Kirche writes:
> Pour info, j'ai fait un update vers 9h et je viens de recompiler : > le problème semble toujours là (?) puisqu'il me parle toujours de > drkm-mml.e
Étonnant, vu que je l'ai corrigé samedi...
M'enfin ??
C'est dans quel fichier ta correction ?
> Par contre ça ne semble pas stabilisé avec le test de mémoire pleine > de RMS : à l'entrée dans un groupe il stoppe à la recherche d'une > fonction introuvable memory-full-p
Étonnant aussi, vu qu'il n'y a aucun appel à cette fonction (qui a été effectivement supprimée) dans Emacs... tu es sûr d'avoir tout bien recompilé ?
Comprend pas : j'ai essayé sur la machine actuelle une compilation «en place» alors que d'habitude je passe par le mac/make-package qui compile tous les modules dans un répertoire temporaire. Mais avant de transférer les sources sur le G4 je suis _sûr_ d'avoir passé un coup de make maintainer-clean. Il aurait sauté ce fichier ?
Je retente un cvs up pour voir... -- Sébastien Kirche
Sébastien Kirche
Le 31 octobre 2005 à 13:10, Sébastien Kirche s'est exprimé ainsi :
je suis _sûr_ d'avoir passé un coup de make maintainer-clean
Ben en fait, il reste tous les .elc dans lisp...
J'ai dû merder quelque part. -- Sébastien Kirche
Le 31 octobre 2005 à 13:10, Sébastien Kirche s'est exprimé ainsi :
je suis _sûr_ d'avoir passé un coup de make maintainer-clean
Il ne sert a rien d'utiliser 'autoload' avec 'require' (le but d''autoload' est justement d'eviter un 'require', et de deferer le chargement a la premiere utilisation).
Argl. Je me suis fais enduire d'erreur
:-D
par le commentaire en début de drkm-mml.el qui parle de générer l'autoload ou d'utiliser un require. J'ai mis le require car je n'ai pas encore installé cedet sur ce système.
À propos de 'require', 'autoload' et des Loaddefs Files.
'require' sert à s'assurer de la présence d'un fonctionnalité, désignée par un symbole. Comment cela marche-t-il ? On peut renseigner une fonctionnalité comme présente au moyen de 'provide'. Lors du 'require', si la fonctionnalité est présente, il ne se passe rien. Sinon, il va essayer de charger la bibliothèque ad-hoc. Il se base sur le nom du symbole, et cherche dans le 'load-path' une bibliothèque de même nom.
Les autoloads sont une sorte particulière de fonction (pour faire simple). Grosso-modo, l'autoload garde le nom de la bibliothèque où est réellement définie la fonction (plus éventuellement la docstring, et l'une ou l'autre chose). Lors de l'exécution de la fonction, la bibliothèque est chargée, et la fonction réelle exécutée. Ils sont créés par la fonction 'autoload'.
Les autoloads permettent donc d'éviter de charger une bibliothèque (par exemple en requérant une fonctionnalité) juste pour rendre disponible une ou deux fonctions (points d'entrée principaux de la bibliothèque).
Les Loaddefs Files sont des fichiers, généralement assez petits en regard des bibliothèques qu'ils rendent accessibles, contenant principalement des création d'autoloads (donc des appels à la fonction 'autoload'). Plus éventuellement d'autres choses comme des variables clefs, ou des déclarations de customs.
Un intérêt pour l'utilisateur est que le mainteneur d'une bibliothèque fournit un tel fichier, et dit : « mettez les fichier dans le 'load-path' et charger le Loaddefs File » (qui déclarera tous les points d'entrée principaux au moyen des autoloads, donc directement utilisables).
Un intérêt pour les mainteneurs est que ce fichiers peut être généré automatiquement. Grâce à des commentaires spéciaux placés avant les fonctions que l'on veut inclure comme des autoloads dans le Loaddefs File. Il suffit d'écrire « ;;;###autoload » sur la ligne précédente, et le tour est joué. Des commandes d'Emacs analysent un fichier ELisp (ou les fichiers ELisp d'un répertoire entier) et génèrent un Loaddefs File en se basant sur ces commentaires (des « autoload cookies » si je ne m'abuse). CEDET fournit un petit module facilitant encore plus la génération de ces fichiers.
Donc pour en revenir à 'drkm-mml', il faut soit i) utiliser 'require', soit ii) générer un Loaddefs File au moyen des commandes d'Emacs ou de CEDET et le charger dans ~/.emacs.el, soit (et ce n'est pas indiqué dans 'drkm-mml') iii) créer soi-même l'autoload kivabien dans ~/.emacs.el.
J'espère que c'est un peu plus clair ...
Une dernière remarque, à propos de l'ajout de ces lignes dans ~/.gnus.el. Si je ne m'abuse, mais ce n'est pas moi l'expert ès Gnus, ce fichier est chargé à chaque démarrage de Gnus, ce qui peut arriver plusieurs fois par session Emacs. Il me semble donc que toutes la config de Gnus ne doit pas aller dans ce fichier. Il faudrait plutôt réfléchir à chaque ajout : « doit-il être évalué à chaque lancement de Gnus, ou juste au premier (ou au chargement d'Emacs) ? ». J'aurais donc tendance à mettre ces lignes dans ~/.emacs.el ou autre.
Qu'en pensez-vous ?
--drkm
Sébastien Kirche writes:
Le 31 octobre 2005 à 02:10, drkm s'est exprimé ainsi :
Il ne sert a rien d'utiliser 'autoload' avec 'require' (le but
d''autoload' est justement d'eviter un 'require', et de deferer le
chargement a la premiere utilisation).
Argl. Je me suis fais enduire d'erreur
:-D
par le commentaire en début de
drkm-mml.el qui parle de générer l'autoload ou d'utiliser un require.
J'ai mis le require car je n'ai pas encore installé cedet sur ce
système.
À propos de 'require', 'autoload' et des Loaddefs Files.
'require' sert à s'assurer de la présence d'un fonctionnalité,
désignée par un symbole. Comment cela marche-t-il ? On peut
renseigner une fonctionnalité comme présente au moyen de
'provide'. Lors du 'require', si la fonctionnalité est présente,
il ne se passe rien. Sinon, il va essayer de charger la
bibliothèque ad-hoc. Il se base sur le nom du symbole, et
cherche dans le 'load-path' une bibliothèque de même nom.
Les autoloads sont une sorte particulière de fonction (pour
faire simple). Grosso-modo, l'autoload garde le nom de la
bibliothèque où est réellement définie la fonction (plus
éventuellement la docstring, et l'une ou l'autre chose). Lors de
l'exécution de la fonction, la bibliothèque est chargée, et la
fonction réelle exécutée. Ils sont créés par la fonction
'autoload'.
Les autoloads permettent donc d'éviter de charger une
bibliothèque (par exemple en requérant une fonctionnalité) juste
pour rendre disponible une ou deux fonctions (points d'entrée
principaux de la bibliothèque).
Les Loaddefs Files sont des fichiers, généralement assez petits
en regard des bibliothèques qu'ils rendent accessibles, contenant
principalement des création d'autoloads (donc des appels à la
fonction 'autoload'). Plus éventuellement d'autres choses comme
des variables clefs, ou des déclarations de customs.
Un intérêt pour l'utilisateur est que le mainteneur d'une
bibliothèque fournit un tel fichier, et dit : « mettez les
fichier dans le 'load-path' et charger le Loaddefs File » (qui
déclarera tous les points d'entrée principaux au moyen des
autoloads, donc directement utilisables).
Un intérêt pour les mainteneurs est que ce fichiers peut être
généré automatiquement. Grâce à des commentaires spéciaux placés
avant les fonctions que l'on veut inclure comme des autoloads
dans le Loaddefs File. Il suffit d'écrire « ;;;###autoload » sur
la ligne précédente, et le tour est joué. Des commandes d'Emacs
analysent un fichier ELisp (ou les fichiers ELisp d'un répertoire
entier) et génèrent un Loaddefs File en se basant sur ces
commentaires (des « autoload cookies » si je ne m'abuse). CEDET
fournit un petit module facilitant encore plus la génération de
ces fichiers.
Donc pour en revenir à 'drkm-mml', il faut soit i) utiliser
'require', soit ii) générer un Loaddefs File au moyen des
commandes d'Emacs ou de CEDET et le charger dans ~/.emacs.el,
soit (et ce n'est pas indiqué dans 'drkm-mml') iii) créer
soi-même l'autoload kivabien dans ~/.emacs.el.
J'espère que c'est un peu plus clair ...
Une dernière remarque, à propos de l'ajout de ces lignes dans
~/.gnus.el. Si je ne m'abuse, mais ce n'est pas moi l'expert ès
Gnus, ce fichier est chargé à chaque démarrage de Gnus, ce qui
peut arriver plusieurs fois par session Emacs. Il me semble donc
que toutes la config de Gnus ne doit pas aller dans ce fichier.
Il faudrait plutôt réfléchir à chaque ajout : « doit-il être
évalué à chaque lancement de Gnus, ou juste au premier (ou au
chargement d'Emacs) ? ». J'aurais donc tendance à mettre ces
lignes dans ~/.emacs.el ou autre.
Il ne sert a rien d'utiliser 'autoload' avec 'require' (le but d''autoload' est justement d'eviter un 'require', et de deferer le chargement a la premiere utilisation).
Argl. Je me suis fais enduire d'erreur
:-D
par le commentaire en début de drkm-mml.el qui parle de générer l'autoload ou d'utiliser un require. J'ai mis le require car je n'ai pas encore installé cedet sur ce système.
À propos de 'require', 'autoload' et des Loaddefs Files.
'require' sert à s'assurer de la présence d'un fonctionnalité, désignée par un symbole. Comment cela marche-t-il ? On peut renseigner une fonctionnalité comme présente au moyen de 'provide'. Lors du 'require', si la fonctionnalité est présente, il ne se passe rien. Sinon, il va essayer de charger la bibliothèque ad-hoc. Il se base sur le nom du symbole, et cherche dans le 'load-path' une bibliothèque de même nom.
Les autoloads sont une sorte particulière de fonction (pour faire simple). Grosso-modo, l'autoload garde le nom de la bibliothèque où est réellement définie la fonction (plus éventuellement la docstring, et l'une ou l'autre chose). Lors de l'exécution de la fonction, la bibliothèque est chargée, et la fonction réelle exécutée. Ils sont créés par la fonction 'autoload'.
Les autoloads permettent donc d'éviter de charger une bibliothèque (par exemple en requérant une fonctionnalité) juste pour rendre disponible une ou deux fonctions (points d'entrée principaux de la bibliothèque).
Les Loaddefs Files sont des fichiers, généralement assez petits en regard des bibliothèques qu'ils rendent accessibles, contenant principalement des création d'autoloads (donc des appels à la fonction 'autoload'). Plus éventuellement d'autres choses comme des variables clefs, ou des déclarations de customs.
Un intérêt pour l'utilisateur est que le mainteneur d'une bibliothèque fournit un tel fichier, et dit : « mettez les fichier dans le 'load-path' et charger le Loaddefs File » (qui déclarera tous les points d'entrée principaux au moyen des autoloads, donc directement utilisables).
Un intérêt pour les mainteneurs est que ce fichiers peut être généré automatiquement. Grâce à des commentaires spéciaux placés avant les fonctions que l'on veut inclure comme des autoloads dans le Loaddefs File. Il suffit d'écrire « ;;;###autoload » sur la ligne précédente, et le tour est joué. Des commandes d'Emacs analysent un fichier ELisp (ou les fichiers ELisp d'un répertoire entier) et génèrent un Loaddefs File en se basant sur ces commentaires (des « autoload cookies » si je ne m'abuse). CEDET fournit un petit module facilitant encore plus la génération de ces fichiers.
Donc pour en revenir à 'drkm-mml', il faut soit i) utiliser 'require', soit ii) générer un Loaddefs File au moyen des commandes d'Emacs ou de CEDET et le charger dans ~/.emacs.el, soit (et ce n'est pas indiqué dans 'drkm-mml') iii) créer soi-même l'autoload kivabien dans ~/.emacs.el.
J'espère que c'est un peu plus clair ...
Une dernière remarque, à propos de l'ajout de ces lignes dans ~/.gnus.el. Si je ne m'abuse, mais ce n'est pas moi l'expert ès Gnus, ce fichier est chargé à chaque démarrage de Gnus, ce qui peut arriver plusieurs fois par session Emacs. Il me semble donc que toutes la config de Gnus ne doit pas aller dans ce fichier. Il faudrait plutôt réfléchir à chaque ajout : « doit-il être évalué à chaque lancement de Gnus, ou juste au premier (ou au chargement d'Emacs) ? ». J'aurais donc tendance à mettre ces lignes dans ~/.emacs.el ou autre.
Qu'en pensez-vous ?
--drkm
drkm
Sébastien Kirche writes:
Le 31 octobre 2005 à 02:10, drkm s'est exprimé ainsi :
Tu ne vois rien ? Les deux chaines de caracteres devraient etre dans une face differente, tout comme 'eval-after-load' dans la face des mots-clefs. Et le commentaire, evidemment.
Non, le code n'est pas fontifié. Et je n'ai pas d'autre idée pour le moment.
J'ai corrigé une petite erreur, et ajouté des sorties de debug, toujours à <URL:http://www.fgeorges.org/tmp/drkm-mml.el>. Je recopie le bout de code ci-dessus, pour test :
(autoload 'drkm-mml:decode-parts "drkm-mml") ;; Je ne suis pas sur que l''eval-after-load' soit ;; necessaire pour un hook. (eval-after-load "gnus-art" '(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Pour ce qui est du debug, la sortie doit être activée, et va dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
(setq drkm-mml:debug t)
--drkm
Sébastien Kirche writes:
Le 31 octobre 2005 à 02:10, drkm s'est exprimé ainsi :
Tu ne vois rien ? Les deux chaines de caracteres devraient etre dans
une face differente, tout comme 'eval-after-load' dans la face des
mots-clefs. Et le commentaire, evidemment.
Non, le code n'est pas fontifié. Et je n'ai pas d'autre idée pour le
moment.
J'ai corrigé une petite erreur, et ajouté des sorties de debug,
toujours à <URL:http://www.fgeorges.org/tmp/drkm-mml.el>. Je
recopie le bout de code ci-dessus, pour test :
(autoload 'drkm-mml:decode-parts "drkm-mml")
;; Je ne suis pas sur que l''eval-after-load' soit
;; necessaire pour un hook.
(eval-after-load "gnus-art"
'(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Pour ce qui est du debug, la sortie doit être activée, et va
dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
Le 31 octobre 2005 à 02:10, drkm s'est exprimé ainsi :
Tu ne vois rien ? Les deux chaines de caracteres devraient etre dans une face differente, tout comme 'eval-after-load' dans la face des mots-clefs. Et le commentaire, evidemment.
Non, le code n'est pas fontifié. Et je n'ai pas d'autre idée pour le moment.
J'ai corrigé une petite erreur, et ajouté des sorties de debug, toujours à <URL:http://www.fgeorges.org/tmp/drkm-mml.el>. Je recopie le bout de code ci-dessus, pour test :
(autoload 'drkm-mml:decode-parts "drkm-mml") ;; Je ne suis pas sur que l''eval-after-load' soit ;; necessaire pour un hook. (eval-after-load "gnus-art" '(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Pour ce qui est du debug, la sortie doit être activée, et va dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
(setq drkm-mml:debug t)
--drkm
Sébastien Kirche
Le 31 octobre 2005 à 16:10, drkm vraute :
J'espère que c'est un peu plus clair ...
Beaucoup plus je dirais. On en a déjà parlé, mais là tu décris précisément à quoi servent ces fameux loaddefs et comment les obtenir.
La partie autoloads m'était plus familière.
Une dernière remarque, à propos de l'ajout de ces lignes dans ~/.gnus.el. Si je ne m'abuse, mais ce n'est pas moi l'expert ès Gnus, ce fichier est chargé à chaque démarrage de Gnus, ce qui peut arriver plusieurs fois par session Emacs.
C'est une possibilité. Mais si je regarde mon usage personnel d'Emacs/Gnus, il est très rare que je relance un Gnus dans la même session d'Emacs. Généralement mon Emacs est lancé sur des durées assez longues (lire : plusieurs jours ou semaines) entre deux mises à jours du cvs ou éventuellement deux plantages, ce qui arrive parfois avec une version cvs.
Et quand il s'agit de modifier la config ou de tester un paramètre, dans la mesure du possible je me contente de sauver le fichier et d'exécuter la portion de code correspondante avec C-x C-e ou dans le scratch.
Il me semble donc que toutes la config de Gnus ne doit pas aller dans ce fichier. Il faudrait plutôt réfléchir à chaque ajout : « doit-il être évalué à chaque lancement de Gnus, ou juste au premier (ou au chargement d'Emacs) ? ». J'aurais donc tendance à mettre ces lignes dans ~/.emacs.el ou autre.
Qu'en pensez-vous ?
D'un autre côté, drkm-mml ne concerne que gnus, donc il n'est peut-être pas pertinent de placer ça dans la partie générale (?).
-- Sébastien Kirche
Le 31 octobre 2005 à 16:10, drkm vraute :
J'espère que c'est un peu plus clair ...
Beaucoup plus je dirais. On en a déjà parlé, mais là tu décris
précisément à quoi servent ces fameux loaddefs et comment les obtenir.
La partie autoloads m'était plus familière.
Une dernière remarque, à propos de l'ajout de ces lignes dans
~/.gnus.el. Si je ne m'abuse, mais ce n'est pas moi l'expert ès
Gnus, ce fichier est chargé à chaque démarrage de Gnus, ce qui
peut arriver plusieurs fois par session Emacs.
C'est une possibilité. Mais si je regarde mon usage personnel
d'Emacs/Gnus, il est très rare que je relance un Gnus dans la même
session d'Emacs. Généralement mon Emacs est lancé sur des durées assez
longues (lire : plusieurs jours ou semaines) entre deux mises à jours du
cvs ou éventuellement deux plantages, ce qui arrive parfois avec une
version cvs.
Et quand il s'agit de modifier la config ou de tester un paramètre, dans
la mesure du possible je me contente de sauver le fichier et d'exécuter
la portion de code correspondante avec C-x C-e ou dans le scratch.
Il me semble donc
que toutes la config de Gnus ne doit pas aller dans ce fichier.
Il faudrait plutôt réfléchir à chaque ajout : « doit-il être
évalué à chaque lancement de Gnus, ou juste au premier (ou au
chargement d'Emacs) ? ». J'aurais donc tendance à mettre ces
lignes dans ~/.emacs.el ou autre.
Qu'en pensez-vous ?
D'un autre côté, drkm-mml ne concerne que gnus, donc il n'est peut-être
pas pertinent de placer ça dans la partie générale (?).
Beaucoup plus je dirais. On en a déjà parlé, mais là tu décris précisément à quoi servent ces fameux loaddefs et comment les obtenir.
La partie autoloads m'était plus familière.
Une dernière remarque, à propos de l'ajout de ces lignes dans ~/.gnus.el. Si je ne m'abuse, mais ce n'est pas moi l'expert ès Gnus, ce fichier est chargé à chaque démarrage de Gnus, ce qui peut arriver plusieurs fois par session Emacs.
C'est une possibilité. Mais si je regarde mon usage personnel d'Emacs/Gnus, il est très rare que je relance un Gnus dans la même session d'Emacs. Généralement mon Emacs est lancé sur des durées assez longues (lire : plusieurs jours ou semaines) entre deux mises à jours du cvs ou éventuellement deux plantages, ce qui arrive parfois avec une version cvs.
Et quand il s'agit de modifier la config ou de tester un paramètre, dans la mesure du possible je me contente de sauver le fichier et d'exécuter la portion de code correspondante avec C-x C-e ou dans le scratch.
Il me semble donc que toutes la config de Gnus ne doit pas aller dans ce fichier. Il faudrait plutôt réfléchir à chaque ajout : « doit-il être évalué à chaque lancement de Gnus, ou juste au premier (ou au chargement d'Emacs) ? ». J'aurais donc tendance à mettre ces lignes dans ~/.emacs.el ou autre.
Qu'en pensez-vous ?
D'un autre côté, drkm-mml ne concerne que gnus, donc il n'est peut-être pas pertinent de placer ça dans la partie générale (?).
-- Sébastien Kirche
Sébastien Kirche
Le 31 octobre 2005 à 16:10, drkm a formulé :
Pour ce qui est du debug, la sortie doit être activée, et va dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
(setq drkm-mml:debug t)
Je ne vois rien qui saute au yeux, aussi je reproduis le buffer correspondant à ton dernier message :
[**] BEFORE DECODE PART: [1,1,nil,nil,921] nntp+news.cuq.org:fr.comp.applications.emacs:<FIXME: Message-ID> [**] DECODE PART: (1310) Sébastien Kirche writes:
Le 31 octobre 2005 à 02:10, drkm s'est exprimé ainsi :
Tu ne vois rien ? Les deux chaines de caracteres devraient etre dans une face differente, tout comme 'eval-after-load' dans la face des mots-clefs. Et le commentaire, evidemment.
Non, le code n'est pas fontifié. Et je n'ai pas d'autre idée pour le moment.
J'ai corrigé une petite erreur, et ajouté des sorties de debug, toujours à <URL:http://www.fgeorges.org/tmp/drkm-mml.el>. Je recopie le bout de code ci-dessus, pour test :
(autoload 'drkm-mml:decode-parts "drkm-mml") ;; Je ne suis pas sur que l''eval-after-load' soit ;; necessaire pour un hook. (eval-after-load "gnus-art" '(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Pour ce qui est du debug, la sortie doit être activée, et va dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
(setq drkm-mml:debug t)
--drkm
[**] DISPLAY: 533->767 (1843->2077), nil: (autoload 'drkm-mml:decode-parts "drkm-mml") ;; Je ne suis pas sur que l''eval-after-load' soit ;; necessaire pour un hook. (eval-after-load "gnus-art" '(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
[**] BEFORE DECODE PART: [nil,nil,nil,head,1309] nntp+news.cuq.org:fr.comp.applications.emacs:<FIXME: Message-ID>
-- Sébastien Kirche
Le 31 octobre 2005 à 16:10, drkm a formulé :
Pour ce qui est du debug, la sortie doit être activée, et va
dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
(setq drkm-mml:debug t)
Je ne vois rien qui saute au yeux, aussi je reproduis le buffer
correspondant à ton dernier message :
[**] BEFORE DECODE PART: [1,1,nil,nil,921]
nntp+news.cuq.org:fr.comp.applications.emacs:<FIXME: Message-ID>
[**] DECODE PART: (1310)
Sébastien Kirche writes:
Le 31 octobre 2005 à 02:10, drkm s'est exprimé ainsi :
Tu ne vois rien ? Les deux chaines de caracteres devraient etre dans
une face differente, tout comme 'eval-after-load' dans la face des
mots-clefs. Et le commentaire, evidemment.
Non, le code n'est pas fontifié. Et je n'ai pas d'autre idée pour le
moment.
J'ai corrigé une petite erreur, et ajouté des sorties de debug,
toujours à <URL:http://www.fgeorges.org/tmp/drkm-mml.el>. Je
recopie le bout de code ci-dessus, pour test :
(autoload 'drkm-mml:decode-parts "drkm-mml")
;; Je ne suis pas sur que l''eval-after-load' soit
;; necessaire pour un hook.
(eval-after-load "gnus-art"
'(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Pour ce qui est du debug, la sortie doit être activée, et va
dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
(setq drkm-mml:debug t)
--drkm
[**] DISPLAY: 533->767 (1843->2077), nil:
(autoload 'drkm-mml:decode-parts "drkm-mml")
;; Je ne suis pas sur que l''eval-after-load' soit
;; necessaire pour un hook.
(eval-after-load "gnus-art"
'(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Pour ce qui est du debug, la sortie doit être activée, et va dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
(setq drkm-mml:debug t)
Je ne vois rien qui saute au yeux, aussi je reproduis le buffer correspondant à ton dernier message :
[**] BEFORE DECODE PART: [1,1,nil,nil,921] nntp+news.cuq.org:fr.comp.applications.emacs:<FIXME: Message-ID> [**] DECODE PART: (1310) Sébastien Kirche writes:
Le 31 octobre 2005 à 02:10, drkm s'est exprimé ainsi :
Tu ne vois rien ? Les deux chaines de caracteres devraient etre dans une face differente, tout comme 'eval-after-load' dans la face des mots-clefs. Et le commentaire, evidemment.
Non, le code n'est pas fontifié. Et je n'ai pas d'autre idée pour le moment.
J'ai corrigé une petite erreur, et ajouté des sorties de debug, toujours à <URL:http://www.fgeorges.org/tmp/drkm-mml.el>. Je recopie le bout de code ci-dessus, pour test :
(autoload 'drkm-mml:decode-parts "drkm-mml") ;; Je ne suis pas sur que l''eval-after-load' soit ;; necessaire pour un hook. (eval-after-load "gnus-art" '(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Pour ce qui est du debug, la sortie doit être activée, et va dans le buffer '*drkm-mml DEBUG*'. Pour l'activer :
(setq drkm-mml:debug t)
--drkm
[**] DISPLAY: 533->767 (1843->2077), nil: (autoload 'drkm-mml:decode-parts "drkm-mml") ;; Je ne suis pas sur que l''eval-after-load' soit ;; necessaire pour un hook. (eval-after-load "gnus-art" '(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
[**] BEFORE DECODE PART: [nil,nil,nil,head,1309] nntp+news.cuq.org:fr.comp.applications.emacs:<FIXME: Message-ID>
-- Sébastien Kirche
drkm
Sébastien Kirche writes:
[**] DISPLAY: 533->767 (1843->2077), nil: (autoload 'drkm-mml:decode-parts "drkm-mml") ;; Je ne suis pas sur que l''eval-after-load' soit ;; necessaire pour un hook. (eval-after-load "gnus-art" '(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Les parties de code semblent correctement identifiées. Il semblerait donc qu'il s'agisse de la routine de font-locking. Je me suis pourtant principalement inspiré d'une routine de Gnus. Je vais voir cela de plus près (peut-être y a-t-il des modifications dans le CVS ?).
Merci pour ton aide,
--drkm
Sébastien Kirche writes:
[**] DISPLAY: 533->767 (1843->2077), nil:
(autoload 'drkm-mml:decode-parts "drkm-mml")
;; Je ne suis pas sur que l''eval-after-load' soit
;; necessaire pour un hook.
(eval-after-load "gnus-art"
'(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Les parties de code semblent correctement identifiées. Il
semblerait donc qu'il s'agisse de la routine de font-locking. Je
me suis pourtant principalement inspiré d'une routine de Gnus.
Je vais voir cela de plus près (peut-être y a-t-il des
modifications dans le CVS ?).
[**] DISPLAY: 533->767 (1843->2077), nil: (autoload 'drkm-mml:decode-parts "drkm-mml") ;; Je ne suis pas sur que l''eval-after-load' soit ;; necessaire pour un hook. (eval-after-load "gnus-art" '(add-hook 'gnus-part-display-hook 'drkm-mml:decode-parts))
Les parties de code semblent correctement identifiées. Il semblerait donc qu'il s'agisse de la routine de font-locking. Je me suis pourtant principalement inspiré d'une routine de Gnus. Je vais voir cela de plus près (peut-être y a-t-il des modifications dans le CVS ?).
