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 :
1. du multipart goret qui saoule tout le monde 2. un autre balisage comme ';;; lisp code ... ;;; end of lisp code'
3. aucun balisage, juste le code copié collé, comme tout le monde.
J'oubliais:
4. Du code un peu plus intelligent qui repère "^(def" et la parenthèse fermante correspondante, et qui pourrait colorier du code y compris si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une portion de code et de faire une incantation magique genre M-x set-mode-for-selection RET emacs-lisp RET.
Une solution qui ne marche que si l'envoyeur fait quelque chose de particulier et si le destinataire a la bonne extension et utilise le bon lecteur de news, c'est un bénéfice mineur (la coloration syntaxique, on peut vivre sans, et tu peux l'avoir "out-of-the-box" pour le prix d'un copier-coller dans un buffer lisp) pour une minorité de gens, alors qu'il y a des solutions qui n'embêtent personne (cf. ci-dessus).
1. du multipart goret qui saoule tout le monde
2. un autre balisage comme ';;; lisp code ... ;;; end of lisp
code'
3. aucun balisage, juste le code copié collé, comme tout le monde.
J'oubliais:
4. Du code un peu plus intelligent qui repère "^(def" et la parenthèse
fermante correspondante, et qui pourrait colorier du code y compris
si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une portion de
code et de faire une incantation magique genre M-x
set-mode-for-selection RET emacs-lisp RET.
Une solution qui ne marche que si l'envoyeur fait quelque chose de
particulier et si le destinataire a la bonne extension et utilise le
bon lecteur de news, c'est un bénéfice mineur (la coloration
syntaxique, on peut vivre sans, et tu peux l'avoir "out-of-the-box"
pour le prix d'un copier-coller dans un buffer lisp) pour une minorité
de gens, alors qu'il y a des solutions qui n'embêtent personne (cf.
ci-dessus).
1. du multipart goret qui saoule tout le monde 2. un autre balisage comme ';;; lisp code ... ;;; end of lisp code'
3. aucun balisage, juste le code copié collé, comme tout le monde.
J'oubliais:
4. Du code un peu plus intelligent qui repère "^(def" et la parenthèse fermante correspondante, et qui pourrait colorier du code y compris si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une portion de code et de faire une incantation magique genre M-x set-mode-for-selection RET emacs-lisp RET.
Une solution qui ne marche que si l'envoyeur fait quelque chose de particulier et si le destinataire a la bonne extension et utilise le bon lecteur de news, c'est un bénéfice mineur (la coloration syntaxique, on peut vivre sans, et tu peux l'avoir "out-of-the-box" pour le prix d'un copier-coller dans un buffer lisp) pour une minorité de gens, alors qu'il y a des solutions qui n'embêtent personne (cf. ci-dessus).
-- Matthieu
Romain Francoise
Xavier Maillard writes:
Certes mais je ne vois pas trop l'intérêt d'utiliser des outils comme ceux que nous utilisons si c'est pour se contenter d'en faire le minimum.
Si tu avais un très beau marteau, le meilleur marteau du monde, est-ce que pour autant tu irais taper sur tout ce que tu vois ?
-- Romain Francoise | And you never lay down and it's a miracle -- http://orebokech.com/ | you never stay home...
Xavier Maillard <zedek@gnu-rox.org> writes:
Certes mais je ne vois pas trop l'intérêt d'utiliser des outils
comme ceux que nous utilisons si c'est pour se contenter d'en
faire le minimum.
Si tu avais un très beau marteau, le meilleur marteau du monde, est-ce
que pour autant tu irais taper sur tout ce que tu vois ?
--
Romain Francoise <romain@orebokech.com> | And you never lay down and
it's a miracle -- http://orebokech.com/ | you never stay home...
Certes mais je ne vois pas trop l'intérêt d'utiliser des outils comme ceux que nous utilisons si c'est pour se contenter d'en faire le minimum.
Si tu avais un très beau marteau, le meilleur marteau du monde, est-ce que pour autant tu irais taper sur tout ce que tu vois ?
-- Romain Francoise | And you never lay down and it's a miracle -- http://orebokech.com/ | you never stay home...
Xavier Maillard
On 19 Jul 2005, Matthieu Moy wrote:
Matthieu Moy writes:
> Xavier Maillard writes: > > > Bah c'est ça ou: > > > > 1. du multipart goret qui saoule tout le monde > > 2. un autre balisage comme ';;; lisp code ... ;;; end of > > lisp > > code' > > 3. aucun balisage, juste le code copié collé, comme tout le > monde.
J'oubliais:
4. Du code un peu plus intelligent qui repère "^(def" et la parenthèse fermante correspondante, et qui pourrait colorier du code y compris si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une portion de code et de faire une incantation magique genre M-x set-mode-for-selection RET emacs-lisp RET.
Oh voilà deux pistes tout à fait interessante ! Je te concède que ce seraient des évolutions/directions que pourraient prendre le module de notre cher drkm. Mais bon, c'est un début. Je ne doute pas que la chose soit faisable un seul instant.
Une solution qui ne marche que si l'envoyeur fait quelque chose de particulier et si le destinataire a la bonne extension et utilise le bon lecteur de news, c'est un bénéfice mineur (la coloration syntaxique, on peut vivre sans, et tu peux l'avoir "out-of-the-box" pour le prix d'un copier-coller dans un buffer lisp) pour une minorité de gens, alors qu'il y a des solutions qui n'embêtent personne (cf. ci-dessus).
Reste plus qu'à coder le bousin :) Mais j'aime bien l'idée.
drkm< ? Est-ce envisageable d'avoir ce genre de fonctionnalité ? C'est vrai que ça devient nettement moins intrusif quand on y regarde de plus près ;)
Ceci dit, en attendant de voir quelque chose à l'horizon, il y a de fortes chances que je "balise" mon code soit avec le module de drkm soit par un moyen détourné que j'utilisais depuis quelques temps. -- GNUSFR.ORG http://gnusfr.org/ EMACSFR.ORG http://emacsfr.org/ Xavier Maillard Tel: +33 6 68 04 64 37
> Xavier Maillard <zedek@gnu-rox.org> writes:
>
> > Bah c'est ça ou:
> >
> > 1. du multipart goret qui saoule tout le monde
> > 2. un autre balisage comme ';;; lisp code ... ;;; end of
> > lisp
> > code'
>
> 3. aucun balisage, juste le code copié collé, comme tout le
> monde.
J'oubliais:
4. Du code un peu plus intelligent qui repère "^(def" et la
parenthèse
fermante correspondante, et qui pourrait colorier du code y compris
si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une
portion de
code et de faire une incantation magique genre M-x
set-mode-for-selection RET emacs-lisp RET.
Oh voilà deux pistes tout à fait interessante ! Je te concède que
ce seraient des évolutions/directions que pourraient prendre le
module de notre cher drkm. Mais bon, c'est un début. Je ne doute
pas que la chose soit faisable un seul instant.
Une solution qui ne marche que si l'envoyeur fait quelque chose
de particulier et si le destinataire a la bonne extension et
utilise le bon lecteur de news, c'est un bénéfice mineur (la
coloration syntaxique, on peut vivre sans, et tu peux l'avoir
"out-of-the-box" pour le prix d'un copier-coller dans un buffer
lisp) pour une minorité de gens, alors qu'il y a des solutions
qui n'embêtent personne (cf. ci-dessus).
Reste plus qu'à coder le bousin :) Mais j'aime bien l'idée.
drkm< ? Est-ce envisageable d'avoir ce genre de fonctionnalité ?
C'est vrai que ça devient nettement moins intrusif quand on y
regarde de plus près ;)
Ceci dit, en attendant de voir quelque chose à l'horizon, il y a
de fortes chances que je "balise" mon code soit avec le module de
drkm soit par un moyen détourné que j'utilisais depuis quelques
temps.
--
GNUSFR.ORG http://gnusfr.org/
EMACSFR.ORG http://emacsfr.org/
Xavier Maillard Tel: +33 6 68 04 64 37
> Xavier Maillard writes: > > > Bah c'est ça ou: > > > > 1. du multipart goret qui saoule tout le monde > > 2. un autre balisage comme ';;; lisp code ... ;;; end of > > lisp > > code' > > 3. aucun balisage, juste le code copié collé, comme tout le > monde.
J'oubliais:
4. Du code un peu plus intelligent qui repère "^(def" et la parenthèse fermante correspondante, et qui pourrait colorier du code y compris si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une portion de code et de faire une incantation magique genre M-x set-mode-for-selection RET emacs-lisp RET.
Oh voilà deux pistes tout à fait interessante ! Je te concède que ce seraient des évolutions/directions que pourraient prendre le module de notre cher drkm. Mais bon, c'est un début. Je ne doute pas que la chose soit faisable un seul instant.
Une solution qui ne marche que si l'envoyeur fait quelque chose de particulier et si le destinataire a la bonne extension et utilise le bon lecteur de news, c'est un bénéfice mineur (la coloration syntaxique, on peut vivre sans, et tu peux l'avoir "out-of-the-box" pour le prix d'un copier-coller dans un buffer lisp) pour une minorité de gens, alors qu'il y a des solutions qui n'embêtent personne (cf. ci-dessus).
Reste plus qu'à coder le bousin :) Mais j'aime bien l'idée.
drkm< ? Est-ce envisageable d'avoir ce genre de fonctionnalité ? C'est vrai que ça devient nettement moins intrusif quand on y regarde de plus près ;)
Ceci dit, en attendant de voir quelque chose à l'horizon, il y a de fortes chances que je "balise" mon code soit avec le module de drkm soit par un moyen détourné que j'utilisais depuis quelques temps. -- GNUSFR.ORG http://gnusfr.org/ EMACSFR.ORG http://emacsfr.org/ Xavier Maillard Tel: +33 6 68 04 64 37
drkm
Romain Francoise writes:
drkm writes:
Au fait, si ceux qui n'utilisent pas MML trouvent que le balisage supplémentaire introduit est dérangeant, j'aimerais un retour.
En effet c'est un peu distrayant, surtout quand il y a deux lignes de balisage pour une ligne de contenu...
C'est sûr que l'idée était de ne l'employer qu'à partir d'une quantité significative de code, pour une définition adaptée de « significative ».
De manière à ne pas promouvoir une pratique jugée dérangeante (et donc supprimer ce package).
De toute façon à moins que j'aie mal compris la chose n'est utile que si l'émetteur et le destinataire utilisent Gnus, et donc imposer le balisage aux gens qui n'utilisent pas Gnus est une indélicatesse manifeste...
Mmh, peut-être. J'avais du mal à me décider. D'un côté, si l'on inclus un code de 50 lignes, je ne trouve pas le balisage, somme toute assez léger, très dérangeant. D'un autre côté, si on l'utilise avec deux lignes de code, je trouve cela clairement dérangeant.
Peut-être as-tu raison. Je vais attendre de voir si d'autres opinions s'élèveront (je vois qu'il y a quelques réponses déjà dans ce fil).
En passant, je ne voudrais pas que l'on prenne ce petit bout de code comme une « indélicatesse manifeste ». Ma demande de retour, à laquelle tu réponds ici, se veut justement tout le contraire.
Merci pour ton opinion,
--drkm
Romain Francoise writes:
drkm <usenet.fcaemacs@fgeorges.org> writes:
Au fait, si ceux qui n'utilisent pas MML trouvent que le balisage
supplémentaire introduit est dérangeant, j'aimerais un retour.
En effet c'est un peu distrayant, surtout quand il y a deux lignes de
balisage pour une ligne de contenu...
C'est sûr que l'idée était de ne l'employer qu'à partir d'une
quantité significative de code, pour une définition adaptée de
« significative ».
De manière à ne pas promouvoir une pratique jugée dérangeante (et donc
supprimer ce package).
De toute façon à moins que j'aie mal compris la chose n'est utile que si
l'émetteur et le destinataire utilisent Gnus, et donc imposer le
balisage aux gens qui n'utilisent pas Gnus est une indélicatesse
manifeste...
Mmh, peut-être. J'avais du mal à me décider. D'un côté, si
l'on inclus un code de 50 lignes, je ne trouve pas le balisage,
somme toute assez léger, très dérangeant. D'un autre côté, si on
l'utilise avec deux lignes de code, je trouve cela clairement
dérangeant.
Peut-être as-tu raison. Je vais attendre de voir si d'autres
opinions s'élèveront (je vois qu'il y a quelques réponses déjà
dans ce fil).
En passant, je ne voudrais pas que l'on prenne ce petit bout de
code comme une « indélicatesse manifeste ». Ma demande de
retour, à laquelle tu réponds ici, se veut justement tout le
contraire.
Au fait, si ceux qui n'utilisent pas MML trouvent que le balisage supplémentaire introduit est dérangeant, j'aimerais un retour.
En effet c'est un peu distrayant, surtout quand il y a deux lignes de balisage pour une ligne de contenu...
C'est sûr que l'idée était de ne l'employer qu'à partir d'une quantité significative de code, pour une définition adaptée de « significative ».
De manière à ne pas promouvoir une pratique jugée dérangeante (et donc supprimer ce package).
De toute façon à moins que j'aie mal compris la chose n'est utile que si l'émetteur et le destinataire utilisent Gnus, et donc imposer le balisage aux gens qui n'utilisent pas Gnus est une indélicatesse manifeste...
Mmh, peut-être. J'avais du mal à me décider. D'un côté, si l'on inclus un code de 50 lignes, je ne trouve pas le balisage, somme toute assez léger, très dérangeant. D'un autre côté, si on l'utilise avec deux lignes de code, je trouve cela clairement dérangeant.
Peut-être as-tu raison. Je vais attendre de voir si d'autres opinions s'élèveront (je vois qu'il y a quelques réponses déjà dans ce fil).
En passant, je ne voudrais pas que l'on prenne ce petit bout de code comme une « indélicatesse manifeste ». Ma demande de retour, à laquelle tu réponds ici, se veut justement tout le contraire.
Merci pour ton opinion,
--drkm
drkm
Xavier Maillard writes:
Je me demande si un bête client telnet ne serait pas aussi bon...
Il m'arrive fréquemment de faire un « telnet news.mon.serveur 119 » :-)
--drkm
Xavier Maillard writes:
Je me demande si un bête client telnet ne serait pas aussi
bon...
Il m'arrive fréquemment de faire un « telnet news.mon.serveur
119 » :-)
Je me demande si un bête client telnet ne serait pas aussi bon...
Il m'arrive fréquemment de faire un « telnet news.mon.serveur 119 » :-)
--drkm
drkm
Matthieu Moy writes:
4. Du code un peu plus intelligent qui repère "^(def" et la parenthèse fermante correspondante, et qui pourrait colorier du code y compris si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une portion de code et de faire une incantation magique genre M-x set-mode-for-selection RET emacs-lisp RET.
En effet, tu as raison. Une fonction s'exécutant à l'affichage de l'article, tentant de repérer des portions de code (selon le groupe, il est simple de connaître le(s) langage(s) employé(s)).
Je vois simplement quelque difficultés à identifier correctement les parties de code. Mais avec quelques heuristiques bien choisies, et une commande de nettoyage pour les cas où l'article est massacré, ça devrait être faisable sans trop de problèmes.
Merci,
--drkm
Matthieu Moy writes:
4. Du code un peu plus intelligent qui repère "^(def" et la parenthèse
fermante correspondante, et qui pourrait colorier du code y compris
si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une portion de
code et de faire une incantation magique genre M-x
set-mode-for-selection RET emacs-lisp RET.
En effet, tu as raison. Une fonction s'exécutant à l'affichage
de l'article, tentant de repérer des portions de code (selon le
groupe, il est simple de connaître le(s) langage(s) employé(s)).
Je vois simplement quelque difficultés à identifier
correctement les parties de code. Mais avec quelques
heuristiques bien choisies, et une commande de nettoyage pour les
cas où l'article est massacré, ça devrait être faisable sans trop
de problèmes.
4. Du code un peu plus intelligent qui repère "^(def" et la parenthèse fermante correspondante, et qui pourrait colorier du code y compris si il a été posté sans les balises.
5. Un module qui permet au destinataire de sélectionner une portion de code et de faire une incantation magique genre M-x set-mode-for-selection RET emacs-lisp RET.
En effet, tu as raison. Une fonction s'exécutant à l'affichage de l'article, tentant de repérer des portions de code (selon le groupe, il est simple de connaître le(s) langage(s) employé(s)).
Je vois simplement quelque difficultés à identifier correctement les parties de code. Mais avec quelques heuristiques bien choisies, et une commande de nettoyage pour les cas où l'article est massacré, ça devrait être faisable sans trop de problèmes.
Merci,
--drkm
drkm
Xavier Maillard writes:
drkm< ? Est-ce envisageable d'avoir ce genre de fonctionnalité ? C'est vrai que ça devient nettement moins intrusif quand on y regarde de plus près ;)
Matthieu m'a convaincu. Mais là, je ne peux rien avant octobre. Je ne promets rien, mais ça ne m'étonnerait pas que j'essaie quelque chose dans quelques mois.
Merci à tous pour vos remarques,
--drkm
Xavier Maillard writes:
drkm< ? Est-ce envisageable d'avoir ce genre de fonctionnalité ?
C'est vrai que ça devient nettement moins intrusif quand on y
regarde de plus près ;)
Matthieu m'a convaincu. Mais là, je ne peux rien avant
octobre. Je ne promets rien, mais ça ne m'étonnerait pas que
j'essaie quelque chose dans quelques mois.
drkm< ? Est-ce envisageable d'avoir ce genre de fonctionnalité ? C'est vrai que ça devient nettement moins intrusif quand on y regarde de plus près ;)
Matthieu m'a convaincu. Mais là, je ne peux rien avant octobre. Je ne promets rien, mais ça ne m'étonnerait pas que j'essaie quelque chose dans quelques mois.
Merci à tous pour vos remarques,
--drkm
Matthieu Moy
drkm writes:
En effet, tu as raison. Une fonction s'exécutant à l'affichage de l'article, tentant de repérer des portions de code (selon le groupe, il est simple de connaître le(s) langage(s) employé(s)).
De toutes façons, ta solution avec balisage est difficilement utilisable avec autre chose que du lisp. Sur un newsgroup dédié au C++ ou à Java, si tu postes des trucs spécifiques à Gnus, et en plus spécifiques à un package, la probabilité pour qu'un de tes lecteurs en bénéficie est proche de zero.
-- Matthieu
drkm <usenet.fcaemacs@fgeorges.org> writes:
En effet, tu as raison. Une fonction s'exécutant à l'affichage
de l'article, tentant de repérer des portions de code (selon le
groupe, il est simple de connaître le(s) langage(s) employé(s)).
De toutes façons, ta solution avec balisage est difficilement
utilisable avec autre chose que du lisp. Sur un newsgroup dédié au C++
ou à Java, si tu postes des trucs spécifiques à Gnus, et en plus
spécifiques à un package, la probabilité pour qu'un de tes lecteurs en
bénéficie est proche de zero.
En effet, tu as raison. Une fonction s'exécutant à l'affichage de l'article, tentant de repérer des portions de code (selon le groupe, il est simple de connaître le(s) langage(s) employé(s)).
De toutes façons, ta solution avec balisage est difficilement utilisable avec autre chose que du lisp. Sur un newsgroup dédié au C++ ou à Java, si tu postes des trucs spécifiques à Gnus, et en plus spécifiques à un package, la probabilité pour qu'un de tes lecteurs en bénéficie est proche de zero.
-- Matthieu
Xavier Maillard
On 19 Jul 2005, drkm wrote:
Xavier Maillard writes:
> Je me demande si un bête client telnet ne serait pas aussi > bon...
Il m'arrive fréquemment de faire un « telnet news.mon.serveur 119 » :-)
Pareil mais pas pour lire USENET hein :)
-- Registered Linux-User #340967 with the Linux Counter, http://counter.li.org.
On 19 Jul 2005, drkm wrote:
Xavier Maillard writes:
> Je me demande si un bête client telnet ne serait pas aussi
> bon...
Il m'arrive fréquemment de faire un « telnet news.mon.serveur
119 » :-)
Pareil mais pas pour lire USENET hein :)
--
Registered Linux-User #340967 with the Linux Counter, http://counter.li.org.
> Je me demande si un bête client telnet ne serait pas aussi > bon...
Il m'arrive fréquemment de faire un « telnet news.mon.serveur 119 » :-)
Pareil mais pas pour lire USENET hein :)
-- Registered Linux-User #340967 with the Linux Counter, http://counter.li.org.
Xavier Maillard
On 19 Jul 2005, drkm wrote:
Matthieu Moy writes:
> 4. Du code un peu plus intelligent qui repère "^(def" et la > parenthèse > fermante correspondante, et qui pourrait colorier du code y compris > si il a été posté sans les balises.
> 5. Un module qui permet au destinataire de sélectionner une > portion de > code et de faire une incantation magique genre M-x > set-mode-for-selection RET emacs-lisp RET.
En effet, tu as raison. Une fonction s'exécutant à l'affichage de l'article, tentant de repérer des portions de code (selon le groupe, il est simple de connaître le(s) langage(s) employé(s)).
Ca c'est assez simple à faire (j'ai quelque chose qui fait ça).
Par contre, ne pourrais-tu pas utiliser les fonctionnalités de mm finalement ?
En effet, si on se base sur le fait qu'on détecte les bouts de code qui vont bien, rien ne nous empêche de créer des mm-handler à l'affichage (et à l'affichage seulement) et les ajouter au type-alist qui va bien pour affichage automatique.
Je vois simplement quelque difficultés à identifier correctement les parties de code. Mais avec quelques heuristiques bien choisies, et une commande de nettoyage pour les cas où l'article est massacré, ça devrait être faisable sans trop de problèmes.
Je suis moins optimiste que toi pour cette partie :) -- .o. | zedek (at) gnu-rox.org ..o Hacker Wonderland | ooo |
On 19 Jul 2005, drkm wrote:
Matthieu Moy writes:
> 4. Du code un peu plus intelligent qui repère "^(def" et la
> parenthèse
> fermante correspondante, et qui pourrait colorier du code y compris
> si il a été posté sans les balises.
> 5. Un module qui permet au destinataire de sélectionner une
> portion de
> code et de faire une incantation magique genre M-x
> set-mode-for-selection RET emacs-lisp RET.
En effet, tu as raison. Une fonction s'exécutant à l'affichage
de l'article, tentant de repérer des portions de code (selon le
groupe, il est simple de connaître le(s) langage(s)
employé(s)).
Ca c'est assez simple à faire (j'ai quelque chose qui fait ça).
Par contre, ne pourrais-tu pas utiliser les fonctionnalités de mm
finalement ?
En effet, si on se base sur le fait qu'on détecte les bouts de
code qui vont bien, rien ne nous empêche de créer des mm-handler
à l'affichage (et à l'affichage seulement) et les ajouter au
type-alist qui va bien pour affichage automatique.
Je vois simplement quelque difficultés à identifier
correctement les parties de code. Mais avec quelques
heuristiques bien choisies, et une commande de nettoyage pour
les cas où l'article est massacré, ça devrait être faisable
sans trop de problèmes.
Je suis moins optimiste que toi pour cette partie :)
--
.o. | zedek (at) gnu-rox.org
..o Hacker Wonderland |
ooo |
> 4. Du code un peu plus intelligent qui repère "^(def" et la > parenthèse > fermante correspondante, et qui pourrait colorier du code y compris > si il a été posté sans les balises.
> 5. Un module qui permet au destinataire de sélectionner une > portion de > code et de faire une incantation magique genre M-x > set-mode-for-selection RET emacs-lisp RET.
En effet, tu as raison. Une fonction s'exécutant à l'affichage de l'article, tentant de repérer des portions de code (selon le groupe, il est simple de connaître le(s) langage(s) employé(s)).
Ca c'est assez simple à faire (j'ai quelque chose qui fait ça).
Par contre, ne pourrais-tu pas utiliser les fonctionnalités de mm finalement ?
En effet, si on se base sur le fait qu'on détecte les bouts de code qui vont bien, rien ne nous empêche de créer des mm-handler à l'affichage (et à l'affichage seulement) et les ajouter au type-alist qui va bien pour affichage automatique.
Je vois simplement quelque difficultés à identifier correctement les parties de code. Mais avec quelques heuristiques bien choisies, et une commande de nettoyage pour les cas où l'article est massacré, ça devrait être faisable sans trop de problèmes.
Je suis moins optimiste que toi pour cette partie :) -- .o. | zedek (at) gnu-rox.org ..o Hacker Wonderland | ooo |
