j'utilise BBDB comme gestionnaire d'adresses pour Gnus sur mes différents
postes (presque) sans souci.
Au boulot qui est majoritairement équipé windows on a également un serveur
de messagerie Exchange sur lequel je peux me connecter par LDAP pour
chercher un correspondant. J'y arrive par Emacs via le menu
«Tools/Directory search».
J'aimerais bien interfacer Gnus et/ou BBDB pour pouvoir rechercher via EUDC
dans la base LDAP au moment de la saisie du destinataire de la même façon
qu'actuellement quand je rentre le début du nom suivi de TAB BBDB me
complète ou me propose la liste des alternatives.
J'ai cherché sur Google sans trouver quelque chose de mieux qu'appeler via
un binding eudc-expand-inline (qui fonctionne mais pour le moment ne me fait
que l'expension du premier trouvé).
D'une manière générale, toucher à [emacs]/lisp/, c'est chercher les ennuis, assurément.
et c'est une mauvaise habitude a prendre : Le jour où on se retrouve sur une machine vraiment utilisateurs (au boulot ...), il faut tout réapprendre.
-- Matthieu
drkm
Christophe Cuq writes:
C'est àmha un peu risqué, lors d'une màj d'emacs tu vas te retrouver avec la version du cvs d'emacs et plus celle du cvs de gnus.
Tout à fait.
Perso, j'ai créé un ~/site-lisp dans lequel je mets tout ce qui n'est pas standard emacs.
C'est une pratique courante (je dirais indispensable). Mais c'est surtout utile pour les packages vraiment perso. Un truc comme Gnus devrait être installé au niveau du système, dans [emacs]/site-lisp/.
Enfin, pour une version CVS, le répertoire perso est effectivement plus adapté.
Je mets donc le cvs-gnus dans ~/site-lisp/gnus et j'ai rajouté ce qu'il fallait dans le .emacs pour qu'il aille le chager là.
[ Cfr. un autre article, add-to-list parcours toute la liste. Tu peux regarder à quoi elle ressemble, elle est souvent assez longue ... ]
Il ne me reste plus qu'à trouver comment faire un truc équivalent pour la doc plutôt que d'aller changer la doc de base (qui est reconstituée à chaque maj d'emacs et qu'il faut donc que je modifie à chaque fois...)
Un truc comme (de mémoire, je n'ai pas pris la peine de vérifier, donc à prendre avec les précautions d'usage) :
~> cd ~/site-lisp/gnus ~> installinfo --dir-file=dir gnus.info
devrait t'intéresser.
--drkm
Christophe Cuq <christophe@cuq.org> writes:
C'est àmha un peu risqué, lors d'une màj d'emacs tu vas te retrouver
avec la version du cvs d'emacs et plus celle du cvs de gnus.
Tout à fait.
Perso, j'ai créé un ~/site-lisp dans lequel je mets tout ce qui n'est
pas standard emacs.
C'est une pratique courante (je dirais indispensable). Mais c'est
surtout utile pour les packages vraiment perso. Un truc comme Gnus
devrait être installé au niveau du système, dans [emacs]/site-lisp/.
Enfin, pour une version CVS, le répertoire perso est effectivement
plus adapté.
Je mets donc le cvs-gnus dans ~/site-lisp/gnus et j'ai rajouté ce
qu'il fallait dans le .emacs pour qu'il aille le chager là.
[ Cfr. un autre article, add-to-list parcours toute la liste. Tu
peux regarder à quoi elle ressemble, elle est souvent assez
longue ... ]
Il ne me reste plus qu'à trouver comment faire un truc équivalent pour
la doc plutôt que d'aller changer la doc de base (qui est reconstituée
à chaque maj d'emacs et qu'il faut donc que je modifie à chaque fois...)
Un truc comme (de mémoire, je n'ai pas pris la peine de vérifier,
donc à prendre avec les précautions d'usage) :
C'est àmha un peu risqué, lors d'une màj d'emacs tu vas te retrouver avec la version du cvs d'emacs et plus celle du cvs de gnus.
Tout à fait.
Perso, j'ai créé un ~/site-lisp dans lequel je mets tout ce qui n'est pas standard emacs.
C'est une pratique courante (je dirais indispensable). Mais c'est surtout utile pour les packages vraiment perso. Un truc comme Gnus devrait être installé au niveau du système, dans [emacs]/site-lisp/.
Enfin, pour une version CVS, le répertoire perso est effectivement plus adapté.
Je mets donc le cvs-gnus dans ~/site-lisp/gnus et j'ai rajouté ce qu'il fallait dans le .emacs pour qu'il aille le chager là.
[ Cfr. un autre article, add-to-list parcours toute la liste. Tu peux regarder à quoi elle ressemble, elle est souvent assez longue ... ]
Il ne me reste plus qu'à trouver comment faire un truc équivalent pour la doc plutôt que d'aller changer la doc de base (qui est reconstituée à chaque maj d'emacs et qu'il faut donc que je modifie à chaque fois...)
Un truc comme (de mémoire, je n'ai pas pris la peine de vérifier, donc à prendre avec les précautions d'usage) :
~> cd ~/site-lisp/gnus ~> installinfo --dir-file=dir gnus.info
devrait t'intéresser.
--drkm
drkm
Matthieu Moy writes:
drkm writes:
D'une manière générale, toucher à [emacs]/lisp/, c'est chercher les ennuis, assurément.
et c'est une mauvaise habitude a prendre : Le jour où on se retrouve sur une machine vraiment utilisateurs (au boulot ...), il faut tout réapprendre.
Tout à fait. Voici les trois répertoires que j'utilise, personnellement. Il y a d'abord le répertoire [emacs]/lisp/, de la distribution d'Emacs. Celui-là, c'est « pas touche ». Il y a ensuite [emacs]/site-lisp/. C'est là que j'installe la plupart des packages stables et d'intérêt général. Puis ~/.emacs.d/home-lisp/ pour des packages plus spécifiques, ou que je suis en train de tester, etc.
En fait, il y en a d'autres. Par exemple ~/emacs.d/overloads/. Il est un peu spécial, dans le sens où j'y stocke des modifications de fichiers de [emacs]/lisp/, sur lesquels je travaille, ou d'autres packages que je m'amuse à modifier. J'essaie de garantir, à la fin de ~/.emacs, si je me souviens bien, qu'il soit en tête du load-path.
Puis il y a ~/.emacs.d/configs/ aussi. Il contient l'ensemble de mes fichiers de configuration. Pour l'instant :
-rw-r--r-- 1 fgeorges 8151 Jan 6 01:38 config-TMP.el -rw-r--r-- 1 fgeorges 9609 Jan 2 21:50 config-apropos.el -rw-r--r-- 1 fgeorges 15894 Dec 31 07:57 config-cc-mode.el -rw-r--r-- 1 fgeorges 39367 Dec 31 07:57 config-cedet.el -rw-r--r-- 1 fgeorges 9587 Dec 31 07:57 config-drkm-lib.el -rw-r--r-- 1 fgeorges 9541 Dec 31 07:57 config-ediff.el -rw-r--r-- 1 fgeorges 29146 Jan 10 01:14 config-font-lock.el -rw-r--r-- 1 fgeorges 4219 Dec 31 07:57 config-make.el -rw-r--r-- 1 fgeorges 19470 Jan 2 21:50 config-nxml.el -rw-r--r-- 1 fgeorges 2446 Dec 31 07:57 config-perl.el -rw-r--r-- 1 fgeorges 26575 Jan 10 01:45 config-ps-print.el -rw-r--r-- 1 fgeorges 15979 Dec 31 07:57 config-psgml.el -rw-r--r-- 1 fgeorges 5383 Dec 31 07:57 config-sql.el -rw-r--r-- 1 fgeorges 21589 Jan 18 19:23 top-config-misc.el -rw-r--r-- 1 fgeorges 2684 Jan 8 18:22 top-config-other-edit.el -rw-r--r-- 1 fgeorges 4840 Mar 3 09:36 top-config-pim.el -rw-r--r-- 1 fgeorges 15501 Mar 14 12:20 top-config-prog.el -rw-r--r-- 1 fgeorges 9426 Dec 31 07:57 top-config-text.el -rw-r--r-- 1 fgeorges 3852 Dec 31 07:57 top-config-various-dev.el -rw-r--r-- 1 fgeorges 4618 Jan 18 17:38 top-config-web.el
D'une manière générale, toucher à [emacs]/lisp/, c'est chercher les
ennuis, assurément.
et c'est une mauvaise habitude a prendre : Le jour où on se retrouve
sur une machine vraiment utilisateurs (au boulot ...), il faut tout
réapprendre.
Tout à fait. Voici les trois répertoires que j'utilise,
personnellement. Il y a d'abord le répertoire [emacs]/lisp/, de la
distribution d'Emacs. Celui-là, c'est « pas touche ». Il y a ensuite
[emacs]/site-lisp/. C'est là que j'installe la plupart des packages
stables et d'intérêt général. Puis ~/.emacs.d/home-lisp/ pour des
packages plus spécifiques, ou que je suis en train de tester, etc.
En fait, il y en a d'autres. Par exemple ~/emacs.d/overloads/. Il
est un peu spécial, dans le sens où j'y stocke des modifications de
fichiers de [emacs]/lisp/, sur lesquels je travaille, ou d'autres
packages que je m'amuse à modifier. J'essaie de garantir, à la fin de
~/.emacs, si je me souviens bien, qu'il soit en tête du load-path.
Puis il y a ~/.emacs.d/configs/ aussi. Il contient l'ensemble de
mes fichiers de configuration. Pour l'instant :
-rw-r--r-- 1 fgeorges 8151 Jan 6 01:38 config-TMP.el
-rw-r--r-- 1 fgeorges 9609 Jan 2 21:50 config-apropos.el
-rw-r--r-- 1 fgeorges 15894 Dec 31 07:57 config-cc-mode.el
-rw-r--r-- 1 fgeorges 39367 Dec 31 07:57 config-cedet.el
-rw-r--r-- 1 fgeorges 9587 Dec 31 07:57 config-drkm-lib.el
-rw-r--r-- 1 fgeorges 9541 Dec 31 07:57 config-ediff.el
-rw-r--r-- 1 fgeorges 29146 Jan 10 01:14 config-font-lock.el
-rw-r--r-- 1 fgeorges 4219 Dec 31 07:57 config-make.el
-rw-r--r-- 1 fgeorges 19470 Jan 2 21:50 config-nxml.el
-rw-r--r-- 1 fgeorges 2446 Dec 31 07:57 config-perl.el
-rw-r--r-- 1 fgeorges 26575 Jan 10 01:45 config-ps-print.el
-rw-r--r-- 1 fgeorges 15979 Dec 31 07:57 config-psgml.el
-rw-r--r-- 1 fgeorges 5383 Dec 31 07:57 config-sql.el
-rw-r--r-- 1 fgeorges 21589 Jan 18 19:23 top-config-misc.el
-rw-r--r-- 1 fgeorges 2684 Jan 8 18:22 top-config-other-edit.el
-rw-r--r-- 1 fgeorges 4840 Mar 3 09:36 top-config-pim.el
-rw-r--r-- 1 fgeorges 15501 Mar 14 12:20 top-config-prog.el
-rw-r--r-- 1 fgeorges 9426 Dec 31 07:57 top-config-text.el
-rw-r--r-- 1 fgeorges 3852 Dec 31 07:57 top-config-various-dev.el
-rw-r--r-- 1 fgeorges 4618 Jan 18 17:38 top-config-web.el
D'une manière générale, toucher à [emacs]/lisp/, c'est chercher les ennuis, assurément.
et c'est une mauvaise habitude a prendre : Le jour où on se retrouve sur une machine vraiment utilisateurs (au boulot ...), il faut tout réapprendre.
Tout à fait. Voici les trois répertoires que j'utilise, personnellement. Il y a d'abord le répertoire [emacs]/lisp/, de la distribution d'Emacs. Celui-là, c'est « pas touche ». Il y a ensuite [emacs]/site-lisp/. C'est là que j'installe la plupart des packages stables et d'intérêt général. Puis ~/.emacs.d/home-lisp/ pour des packages plus spécifiques, ou que je suis en train de tester, etc.
En fait, il y en a d'autres. Par exemple ~/emacs.d/overloads/. Il est un peu spécial, dans le sens où j'y stocke des modifications de fichiers de [emacs]/lisp/, sur lesquels je travaille, ou d'autres packages que je m'amuse à modifier. J'essaie de garantir, à la fin de ~/.emacs, si je me souviens bien, qu'il soit en tête du load-path.
Puis il y a ~/.emacs.d/configs/ aussi. Il contient l'ensemble de mes fichiers de configuration. Pour l'instant :
-rw-r--r-- 1 fgeorges 8151 Jan 6 01:38 config-TMP.el -rw-r--r-- 1 fgeorges 9609 Jan 2 21:50 config-apropos.el -rw-r--r-- 1 fgeorges 15894 Dec 31 07:57 config-cc-mode.el -rw-r--r-- 1 fgeorges 39367 Dec 31 07:57 config-cedet.el -rw-r--r-- 1 fgeorges 9587 Dec 31 07:57 config-drkm-lib.el -rw-r--r-- 1 fgeorges 9541 Dec 31 07:57 config-ediff.el -rw-r--r-- 1 fgeorges 29146 Jan 10 01:14 config-font-lock.el -rw-r--r-- 1 fgeorges 4219 Dec 31 07:57 config-make.el -rw-r--r-- 1 fgeorges 19470 Jan 2 21:50 config-nxml.el -rw-r--r-- 1 fgeorges 2446 Dec 31 07:57 config-perl.el -rw-r--r-- 1 fgeorges 26575 Jan 10 01:45 config-ps-print.el -rw-r--r-- 1 fgeorges 15979 Dec 31 07:57 config-psgml.el -rw-r--r-- 1 fgeorges 5383 Dec 31 07:57 config-sql.el -rw-r--r-- 1 fgeorges 21589 Jan 18 19:23 top-config-misc.el -rw-r--r-- 1 fgeorges 2684 Jan 8 18:22 top-config-other-edit.el -rw-r--r-- 1 fgeorges 4840 Mar 3 09:36 top-config-pim.el -rw-r--r-- 1 fgeorges 15501 Mar 14 12:20 top-config-prog.el -rw-r--r-- 1 fgeorges 9426 Dec 31 07:57 top-config-text.el -rw-r--r-- 1 fgeorges 3852 Dec 31 07:57 top-config-various-dev.el -rw-r--r-- 1 fgeorges 4618 Jan 18 17:38 top-config-web.el
--drkm
Xavier Maillard
On 30 Mar 2005, drkm wrote:
Xavier Maillard writes:
> Sinon, il reste la possibilité suivante (moins élégante mais > à le mérite d'être fiable et sans ambiguité):
En effet, puisque add-to-list vérifie que l'élément ajouté ne se trouve pas encore dans la liste, ce qui peut être couteux dans le cas du load-path, et ne sert à rien. Néanmoins, cette ligne (ci-dessus) s'écrit plus naturellement, je trouve, par :
En effet, puisque add-to-list vérifie que l'élément ajouté ne
se trouve pas encore dans la liste, ce qui peut être couteux
dans le cas du load-path, et ne sert à rien. Néanmoins, cette
ligne (ci-dessus) s'écrit plus naturellement, je trouve, par :
En effet, puisque add-to-list vérifie que l'élément ajouté ne se trouve pas encore dans la liste, ce qui peut être couteux dans le cas du load-path, et ne sert à rien. Néanmoins, cette ligne (ci-dessus) s'écrit plus naturellement, je trouve, par :
Le 29 Mar 2005, Sébastien Kirche s'est exprimé ainsi :
J'aimerais bien interfacer Gnus et/ou BBDB pour pouvoir rechercher via EUDC dans la base LDAP au moment de la saisie du destinataire de la même façon qu'actuellement quand je rentre le début du nom suivi de TAB BBDB me complète ou me propose la liste des alternatives.
Bon, depuis ce matin je suis avec NoGnus 0.3 (tiré du CVS et installé dans mon ~/.elisp/gnus ;) et j'ai une version de message-expand-name qui interroge eudc et bbdb.
Enfin qui est /censé/ interroger ces deux système, mais je remarque que eudc a pris le pas sur bbdb. Pourtant d'après le code ça ne devrait pas.
Je vous reproduit ce morceau de code pour pouvoir en discuter : ,---- | (defun message-expand-name () | (cond ((and (memq 'eudc message-expand-name-databases) | (boundp 'eudc-protocol) | eudc-protocol) | (eudc-expand-inline)) | ((and (memq 'bbdb message-expand-name-databases) | (fboundp 'bbdb-complete-name)) | (bbdb-complete-name)) | (t | (expand-abbrev)))) `---- message-expand-name-databases vaut ici (bbdb eudc) qui est la valeur par défaut.
eudc est paramétré correctement puisque je peux interroger le serveur ldap de manière interactive (form) ou en completion par M-x eudc-expand-inline.
bbdb est fonctionne également puisque c'est ce que j'utilisais exclusivement jusqu'à ce matin. L'appel manuel sur le nom d'un contact fonctionne.
Si je comprend bien le code de la fonction message-expand-name, si eudc-expand-inline est capable de trouver un résultat, bbdb-complete-name ne trouvera rien. Par contre si eudc ne trouve rien et qu'il s'agit d'un contact connu, bbdb devrait logiquement me le trouver. Or en fait si eudc trouve mon contact c'est bien, sinon je n'ai aucun résultat...
Je nage un peu là.
-- Sébastien Kirche
Le 29 Mar 2005, Sébastien Kirche s'est exprimé ainsi :
J'aimerais bien interfacer Gnus et/ou BBDB pour pouvoir rechercher via
EUDC dans la base LDAP au moment de la saisie du destinataire de la même
façon qu'actuellement quand je rentre le début du nom suivi de TAB BBDB me
complète ou me propose la liste des alternatives.
Bon, depuis ce matin je suis avec NoGnus 0.3 (tiré du CVS et installé dans
mon ~/.elisp/gnus ;) et j'ai une version de message-expand-name qui
interroge eudc et bbdb.
Enfin qui est /censé/ interroger ces deux système, mais je remarque que eudc
a pris le pas sur bbdb. Pourtant d'après le code ça ne devrait pas.
Je vous reproduit ce morceau de code pour pouvoir en discuter :
,----
| (defun message-expand-name ()
| (cond ((and (memq 'eudc message-expand-name-databases)
| (boundp 'eudc-protocol)
| eudc-protocol)
| (eudc-expand-inline))
| ((and (memq 'bbdb message-expand-name-databases)
| (fboundp 'bbdb-complete-name))
| (bbdb-complete-name))
| (t
| (expand-abbrev))))
`----
message-expand-name-databases vaut ici (bbdb eudc) qui est la valeur par
défaut.
eudc est paramétré correctement puisque je peux interroger le serveur ldap
de manière interactive (form) ou en completion par M-x eudc-expand-inline.
bbdb est fonctionne également puisque c'est ce que j'utilisais exclusivement
jusqu'à ce matin. L'appel manuel sur le nom d'un contact fonctionne.
Si je comprend bien le code de la fonction message-expand-name, si
eudc-expand-inline est capable de trouver un résultat, bbdb-complete-name ne
trouvera rien. Par contre si eudc ne trouve rien et qu'il s'agit d'un
contact connu, bbdb devrait logiquement me le trouver. Or en fait si eudc
trouve mon contact c'est bien, sinon je n'ai aucun résultat...
Le 29 Mar 2005, Sébastien Kirche s'est exprimé ainsi :
J'aimerais bien interfacer Gnus et/ou BBDB pour pouvoir rechercher via EUDC dans la base LDAP au moment de la saisie du destinataire de la même façon qu'actuellement quand je rentre le début du nom suivi de TAB BBDB me complète ou me propose la liste des alternatives.
Bon, depuis ce matin je suis avec NoGnus 0.3 (tiré du CVS et installé dans mon ~/.elisp/gnus ;) et j'ai une version de message-expand-name qui interroge eudc et bbdb.
Enfin qui est /censé/ interroger ces deux système, mais je remarque que eudc a pris le pas sur bbdb. Pourtant d'après le code ça ne devrait pas.
Je vous reproduit ce morceau de code pour pouvoir en discuter : ,---- | (defun message-expand-name () | (cond ((and (memq 'eudc message-expand-name-databases) | (boundp 'eudc-protocol) | eudc-protocol) | (eudc-expand-inline)) | ((and (memq 'bbdb message-expand-name-databases) | (fboundp 'bbdb-complete-name)) | (bbdb-complete-name)) | (t | (expand-abbrev)))) `---- message-expand-name-databases vaut ici (bbdb eudc) qui est la valeur par défaut.
eudc est paramétré correctement puisque je peux interroger le serveur ldap de manière interactive (form) ou en completion par M-x eudc-expand-inline.
bbdb est fonctionne également puisque c'est ce que j'utilisais exclusivement jusqu'à ce matin. L'appel manuel sur le nom d'un contact fonctionne.
Si je comprend bien le code de la fonction message-expand-name, si eudc-expand-inline est capable de trouver un résultat, bbdb-complete-name ne trouvera rien. Par contre si eudc ne trouve rien et qu'il s'agit d'un contact connu, bbdb devrait logiquement me le trouver. Or en fait si eudc trouve mon contact c'est bien, sinon je n'ai aucun résultat...
et en supposant que eudc-protocol existe et est toujours non-nil, cette fonction est équivalente à appeler directement eudc-expand-inline, indépendamment de sa valeur (« de retour »), puisque :
et en supposant que eudc-protocol existe et est toujours non-nil,
cette fonction est équivalente à appeler directement
eudc-expand-inline, indépendamment de sa valeur (« de retour »),
puisque :
et en supposant que eudc-protocol existe et est toujours non-nil, cette fonction est équivalente à appeler directement eudc-expand-inline, indépendamment de sa valeur (« de retour »), puisque :
J'ai l'inpression que ce qu'il te faut, c'est une boucle, ou une imbrication de if.
--drkm
Sébastien Kirche
Le 30 Mar 2005, drkm vraute :
cond, ça exécute la forme associée à la *première* excpression non-nil.
Ah. Ceci explique cela. Encore une mauvaise compréhension de la doc : je pensais que chaque forme de cond était exécutée du moment que la condition était vérifiée.
J'ai l'inpression que ce qu'il te faut, c'est une boucle, ou une imbrication de if.
L'idéal : si la première méthode échoue (= ne renvoie rien), essayer la seconde.
Je pensais même chercher un moyen de modifier le code pour interroger eudc et bbdb dans l'ordre de la variable message-expand-name-databases. Ça permettrait de définir une priorité mais mon lisp est pauvre.
Comment on fait un «for variable in liste do; done» en lisp ?
-- Sébastien Kirche
Le 30 Mar 2005, drkm vraute :
cond, ça exécute la forme associée à la *première* excpression
non-nil.
Ah. Ceci explique cela. Encore une mauvaise compréhension de la doc : je
pensais que chaque forme de cond était exécutée du moment que la condition
était vérifiée.
J'ai l'inpression que ce qu'il te faut, c'est une boucle, ou une
imbrication de if.
L'idéal : si la première méthode échoue (= ne renvoie rien), essayer la
seconde.
Je pensais même chercher un moyen de modifier le code pour interroger eudc
et bbdb dans l'ordre de la variable message-expand-name-databases. Ça
permettrait de définir une priorité mais mon lisp est pauvre.
Comment on fait un «for variable in liste do; done» en lisp ?
cond, ça exécute la forme associée à la *première* excpression non-nil.
Ah. Ceci explique cela. Encore une mauvaise compréhension de la doc : je pensais que chaque forme de cond était exécutée du moment que la condition était vérifiée.
J'ai l'inpression que ce qu'il te faut, c'est une boucle, ou une imbrication de if.
L'idéal : si la première méthode échoue (= ne renvoie rien), essayer la seconde.
Je pensais même chercher un moyen de modifier le code pour interroger eudc et bbdb dans l'ordre de la variable message-expand-name-databases. Ça permettrait de définir une priorité mais mon lisp est pauvre.
Comment on fait un «for variable in liste do; done» en lisp ?
-- Sébastien Kirche
Matthieu Moy
Sébastien Kirche writes:
Le 30 Mar 2005, drkm vraute :
cond, ça exécute la forme associée à la *première* excpression non-nil.
Ah. Ceci explique cela. Encore une mauvaise compréhension de la doc : je pensais que chaque forme de cond était exécutée du moment que la condition était vérifiée.
Pour ça, il y a `if' :
(if cond1 (...)) (if cond2 (...)) ...
;-)
-- Matthieu
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
Le 30 Mar 2005, drkm vraute :
cond, ça exécute la forme associée à la *première* excpression
non-nil.
Ah. Ceci explique cela. Encore une mauvaise compréhension de la doc : je
pensais que chaque forme de cond était exécutée du moment que la condition
était vérifiée.
cond, ça exécute la forme associée à la *première* excpression non-nil.
Ah. Ceci explique cela. Encore une mauvaise compréhension de la doc : je pensais que chaque forme de cond était exécutée du moment que la condition était vérifiée.
