[CODE]: Idée pour le chargement d'un fichier, d'une feature, etc..

Xavier Maillard writes:

Je tripatouille la drkm-lib d'un des membres de ce forum.

J'aime bien le système de configuration mais il me manque
certaines choses ou plutôt je voudrais voir autre chose.

N'hésite pas à demander. Si tu viens avec de bonnes idées
(enfin, que j'estime bonnes), ça peut bien sûr être intégré.

J'ai dans l'idée de me fabriquer une petite macro qui:

1. reprendrait plus ou moins l'existant de drkm-conf:configure
2. qui permettrait de passer à loisir une chaine ou un symbole ou
une liste de symboles voir une alist de symboles . un
keybinding

Oui. Comme je te l'ai dit, le fait de passer un symbole de
fonction me semble restrictif. Bien que jusqu'à présent je m'en
accomode. Je pense éventuellement à avoir un appel de la forme :

(drkm-conf:configure (mode le-mode)
...

ou :

(drkm-conf:configure (feature la-feature)
...

ou encore :

(drkm-conf:configure ((mode le-mode) (mode other-mode)
(feature la-feature))
...

3. qui pourrait éventuellement prendre un keymap en argument

C'est en effet un argument intéressant à ajouter. Comme je te
l'ai dit, il me semble que la manière actuelle de spécifier des
keywords n'est pas géniale. Ils sont spécifiés en dur dans la
définition de la macro. Mais tu peux déjà y ajouter un nouveau
keyword.

Je verrais bien avoir un argument '&rest' pour les keywords, la
macro se chargeant d'analyser les keywords présents et de
dispatcher vers des fonctions, renseignées dans une alist.
Quelque chose comme :

(defvar drkm-conf:config-keywords
'((config . drkm-conf::configure-config)
(auto-mode . drkm-conf::configure-auto-mode)
(info-dirs . drkm-conf:add-info-path)
(keys . zedek::configure-keys)
...)
"...")

;; Je laisse MODE comme dans le source, sans tenir compte
;; des notes ci-dessus. Pas de gestion d'erreurs, etc.
;; C'est pour donner l'idée.
;;
(defmacro drkm-conf:config (mode &rest args)
"..."
(let ((forms ...))
(while args
(push (funcall (cdr (assq (first args)))
(second args))
forms)
(setq args (cdr (cdr args))))
`(prog1 ,@(nreverse forms))))

Comme on est à la compilation, on peut s'amuser avec des choses
beaucoup plus compliquées. On peut facilement avoir des packages
qui étendent alors drkm-configure. Comme les 'top-config-....el'
ne dervaient contenir que des 'drkm-conf:configure', ou du moins
ne pas changer souvent, on peut les compiler sans que cela ne
soit pénible à l'utilisation. Les fichiers 'config-....el' eux,
sont moins critiques. Ils peuvent rester non-compilés, et donc
changer plus facilement au jour-le-jour.

;; Exemple de top-config file.

(require 'drkm-config-run-time)
(eval-when-compile
(require 'drkm-config-compile-time)
(require 'drkm-config-some-extension))

(drkm-conf:configure ...
:config 'config-file
:keys '(keymap ("key" function) ("key" function) ...)
...)

(drkm-conf:configure ...
...)

Bref une fonction du style:

load-ng (lib &key <les clés de drkm-config> keymap keybinding)

Pour le chargement de la feature, un moyen simple de savoir
comment charger est de le faire conditionnelement en fonction du
type de lib:

[...]

Yep.

Pour la keymap, c'est tout aussi facile:

;;; lisp code
(defvar keymap (make-sparse-keymap))
(global-set-key binding keymap)

Là, je comprends pas.

;; suivant la alist, ce qui suit pourrait faire l'affaire
(mapc (lambda (cellule)
(define-key keymap (cdr cellule) (car cellule)))
alist)
;;; end of lisp

L'usage que je souhaite faire de ce genre de chose ?

Charger tout ou parti d'un module en lui spécifiant en une seule
passe la configuration *complète*.

C'est marrant. C'est exactement la diretcion opposée de
'drkm-conf:configure'. Le but est de retaredr au plus possible
le chargement de code, tant des bibliothèques que de leur
configuration.

J'ai un semblant de truc qui fonctionne que j'utilise pour le
paquet boxquote. Actuellement, tout ce que je sais faire c'est
charger le module, créer la keymap, assigner les keybindings
suivant la alist).

Pourquoi crées-tu une keymap ? Il n'y en a pas dans boxquote ?

Ca donne un truc du genre:

;;; lisp code
(xm-use-library "boxquote"
:keymap xm-boxquote-prefix-map
:binding (kbd "C-c z B")
:xlist '((boxquote-region . "r")

[...]

Ha, ok, je comprends maintenant (et le defvar plus haut
également). Tu te crées tes propres bindings globaux pour le
package, rassemblés dans la même keymap (accessible globalement
par 'C-c z B').

BTW, l'intérêt de 'kbd', c'est de ne plus devoir jouer avec des
séquences d'échapement (par '') mais je noter les combinaisons
comme on le fait dans du texte (à la Emacs, bien sûr). "C-c z B"
suffit.

Je sais que ça va paraître farfelu à certains, mais c'est
typiquement le genre de chose que je voudrais faire: configurer
un paquet entier en un seul appel de fonction (enfin là en
l'occurence c'est une macro).

Ça, c'est illusoire. Et sans doute inutile. L'intérêt de
'drkm-conf:configure' c'est qu'il prend les infos nécessaire à la
gestion du chargement, les utilise, et permet de placer toute la
config du package dans un fichier externe, qui ne sera chargé
qu'au dernier moment.

En fait, je viens de me rendre compte qu'elle s'écarte déjà de
cet objectif. Elle comprend pour l'instant les keywords
suivants :

- config
- config-if-available
- auto-mode
- interpreters
- magic-mode
- autoloads
- autoload-files
- font-lock
- hooks
- info-dirs

:font-lock et :hooks sont de trop, ÀMHA. D'ailleurs, je pense
que si tu regardes dans mes fichiers de configuration, j'ai un
appel avec les autres keywords dans le top-config file, puis un
appel supplémentaire avec :font-lock dans le config file.

Là où je coince, c'est dans le fait de pouvoir charger par
require, load-library ou même par autoload. Je n'arrive pas à
gérer tout ça très proprement.

Je ne comprend pas.

Ce que je veux dire, c'est que si
je fais un require de "boxquote" entièrement alors que je défini
des bindings pour une partie seulement des fonctions, ça me
dérange. Je voudrais plutôt être capable de ne charger que les
features que je passe dans ma alist et assigner les bindings en
conséquence.

Je ne comprend toujours pas. Tu veux créer des bindings pour
chaque fonction de boxquote ?!? Ou ne charger qu'une partie des
fonctions ?!? (je n'abuse que rarement de la ponctuation
exclamative, mais là, j'avoue être perdu)

Je ne suis pas sûr d'avoir été clair, mais si le challenge vous
motive et que vous voyez à peu près où je en venir, ce serait
sympa de partager ça ici :)

Ben franchement, je ne vois pas trop où tu veux en venir. Mais
si tu développes (tes idées, je veux dire), pourquoi pas ?

--drkm

On 7 Jul 2005, drkm wrote:

Oui. Comme je te l'ai dit, le fait de passer un symbole de
fonction me semble restrictif. Bien que jusqu'à présent je m'en
accomode. Je pense éventuellement à avoir un appel de la
forme :

[ ... ]

J'aime bien ;) C'est vrai que se contenter d'une chose quand tout
est possible, c'est pas marrant ;)

> 3. qui pourrait éventuellement prendre un keymap en argument

[ ... ]

Je verrais bien avoir un argument '&rest' pour les keywords, la
macro se chargeant d'analyser les keywords présents et de
dispatcher vers des fonctions, renseignées dans une alist.
Quelque chose comme :

[ ... ]

Ca me semble être une bonne idée et un bon début.

> Charger tout ou parti d'un module en lui spécifiant en une
> seule passe la configuration *complète*.

C'est marrant. C'est exactement la diretcion opposée de
'drkm-conf:configure'. Le but est de retaredr au plus possible
le chargement de code, tant des bibliothèques que de leur
configuration.

Non, ce n'est pas si opposé. L'objectif poursuivi est exactement
le même: ne pas charger (ni configurer) un module tant qu'il n'y
en a pas l'utilité.

Ha, ok, je comprends maintenant (et le defvar plus haut
également). Tu te crées tes propres bindings globaux pour le
package, rassemblés dans la même keymap (accessible globalement
par 'C-c z B').

Tout à fait. C'est en gros ce que je souhaite faire pour une
paire de paquets "simples".

BTW, l'intérêt de 'kbd', c'est de ne plus devoir jouer avec des
séquences d'échapement (par '') mais je noter les combinaisons
comme on le fait dans du texte (à la Emacs, bien sûr). "C-c z
B" suffit.

Exact, mais comme j'ai toujours fait comme ça ... :)

> Je sais que ça va paraître farfelu à certains, mais c'est
> typiquement le genre de chose que je voudrais faire:
> configurer un paquet entier en un seul appel de fonction
> (enfin là en l'occurence c'est une macro).

Ça, c'est illusoire. Et sans doute inutile. L'intérêt de
'drkm-conf:configure' c'est qu'il prend les infos nécessaire à
la gestion du chargement, les utilise, et permet de placer
toute la config du package dans un fichier externe, qui ne sera
chargé qu'au dernier moment.

Euh, là je demande des explications.

> Là où je coince, c'est dans le fait de pouvoir charger par
> require, load-library ou même par autoload. Je n'arrive pas à
> gérer tout ça très proprement.

Je ne comprend pas.

C'est pas compliqué mais je m'exprime mal. Suivant les arguments
passés à la macro, je peux à loisir choisir "intelligemment"
quelle fonction utiliser pour charger un module.

Quelques exemples:

1. stringp et pas de alist: load-library
2. symbolp et pas de alist: require
3. symbolp et une alist: là soit un autoload soit un require sur
chaque car
...

Je ne comprend toujours pas. Tu veux créer des bindings pour
chaque fonction de boxquote ?!? Ou ne charger qu'une partie des

Non, je veux ne pouvoir mettre des bindings que pour certaines
fonctions et éviter de tout charger comme un goret.

Par exemple si j'ai la feature X et que je veux charger les
"fonctions" Y et Z, un appel comme:

(load-ng 'X :alist '((Y . un bind)(Z . un bind)))

doit me conduire à faire un require/autoload sur Y et Z + un
define-key sur chacun. Ni plus ni moins.

> Je ne suis pas sûr d'avoir été clair, mais si le challenge
> vous motive et que vous voyez à peu près où je en venir, ce
> serait sympa de partager ça ici :)

Ben franchement, je ne vois pas trop où tu veux en venir. Mais
si tu développes (tes idées, je veux dire), pourquoi pas ?

J'ai pas l'habitude de faire des explications par écrit. Je
préferre l'échange en direct. Sur USENET, ça parait compliqué :)

Je vais faire des efforts pour me faire comprendre mais c'est pas
évident :)
--
Xavier MAILLARD (GnuPG: 1024D/1E028EA5)
EmacsOS user (http://emacsfr.org)
APRIL (http://www.april.org)

Xavier Maillard writes:

On 7 Jul 2005, drkm wrote:

> Charger tout ou parti d'un module en lui spécifiant en une
> seule passe la configuration *complète*.

C'est marrant. C'est exactement la diretcion opposée de
'drkm-conf:configure'. Le but est de retaredr au plus possible
le chargement de code, tant des bibliothèques que de leur
configuration.

Non, ce n'est pas si opposé. L'objectif poursuivi est exactement
le même: ne pas charger (ni configurer) un module tant qu'il n'y
en a pas l'utilité.

Ah. C'est plutôt « configurer le chargement de ... » que
« charger ... », alors. Ok.

> Je sais que ça va paraître farfelu à certains, mais c'est
> typiquement le genre de chose que je voudrais faire:
> configurer un paquet entier en un seul appel de fonction
> (enfin là en l'occurence c'est une macro).

Ça, c'est illusoire. Et sans doute inutile. L'intérêt de
'drkm-conf:configure' c'est qu'il prend les infos nécessaire à
la gestion du chargement, les utilise, et permet de placer
toute la config du package dans un fichier externe, qui ne sera
chargé qu'au dernier moment.

Euh, là je demande des explications.

Prenons par exemple Gnus (c'est un exemple extrême, oui).
Lorsque tu dis : « configurer un paquet entier en un seul appel
de fonction », ça veut dire que tu veux inclure tout ton .gnus
dans un unique appel.

'drkm-conf:configure' ne prend que les infos de configuration
du *chargement* du module. En l'occurence, ce serait où se situe
Gnus, le fichier de config, etc. (évidemment, avec Gnus, c'est
géré différemment).

> Là où je coince, c'est dans le fait de pouvoir charger par
> require, load-library ou même par autoload. Je n'arrive pas à
> gérer tout ça très proprement.

Je ne comprend pas.

C'est pas compliqué mais je m'exprime mal. Suivant les arguments
passés à la macro, je peux à loisir choisir "intelligemment"
quelle fonction utiliser pour charger un module.

Quelques exemples:

1. stringp et pas de alist: load-library
2. symbolp et pas de alist: require
3. symbolp et une alist: là soit un autoload soit un require sur
chaque car
...

Ok. Je ne vois pas trop où tu coince. Tu utilise COND, les
tests qui vont bien, et les fonctions de chargement ad-hoc.
Qu'est-ce qui ne va pas, exactement ?

Je ne comprend toujours pas. Tu veux créer des bindings pour
chaque fonction de boxquote ?!? Ou ne charger qu'une partie des

Non, je veux ne pouvoir mettre des bindings que pour certaines
fonctions et éviter de tout charger comme un goret.

Par exemple si j'ai la feature X et que je veux charger les
"fonctions" Y et Z, un appel comme:

(load-ng 'X :alist '((Y . un bind)(Z . un bind)))

doit me conduire à faire un require/autoload sur Y et Z + un
define-key sur chacun. Ni plus ni moins.

On est d'accord que les requires ne sont pas applicables sur
les fonctions ? Alors je ne vois pas le problème. Tu génère un
autoload pour chaque fonction, c'est tout. Tu ne t'occupes pas
de require.

J'ai pas l'habitude de faire des explications par écrit. Je
préferre l'échange en direct. Sur USENET, ça parait compliqué :)

C'est quand même moins compliqué que de faire le
déplacement ;-)

J'espère avoir répondu à tes questions. Mais il reste encore
quelques points d'ombre. Je ne suis pas certain de voir
exactement ce que tu veux (notamment où tu coinces pour le
chargement de différents types, et sue le problème de génération
des autoloads).

Tiens, j'y pense. Si le problème avec les différents types à
charger est l'identification du dit type (c'est à dire quels
tests employer), utilise quelque chose comme ce dont j'ai parlé
dans un précédent article :

(load-ng (thing type)
...)

où 'thing' peut être 'feature', 'library', 'file', ou ce que tu
veux.

--drkm

Xavier Maillard <zedek@gnu-rox.org> writes:

Non, je veux ne pouvoir mettre des bindings que pour certaines
fonctions et éviter de tout charger comme un goret.

Si le mode est bien foutu, il doit déclarer ses ;;;###autoloads comme
il faut. Si le mode est mal foutu, en général, j'ajoute
les ;;;###autoloads et j'envoie un patch.

--
Matthieu

Matthieu Moy writes:

Si le mode est bien foutu, il doit déclarer ses ;;;###autoloads comme
il faut. Si le mode est mal foutu, en général, j'ajoute
les ;;;###autoloads et j'envoie un patch.

Sage habitude.

--drkm

On 8 Jul 2005, Matthieu Moy wrote:

Xavier Maillard <zedek@gnu-rox.org> writes:

> Non, je veux ne pouvoir mettre des bindings que pour
> certaines fonctions et éviter de tout charger comme un goret.

Si le mode est bien foutu, il doit déclarer ses ;;;###autoloads
comme il faut. Si le mode est mal foutu, en général, j'ajoute
les ;;;###autoloads et j'envoie un patch.

C'est tout à ton honneur et courageux. Il faudrait que je
m'impose une certaine discipline aussi dans ce que je fais.
--
GNUSFR.ORG http://gnusfr.org/
EMACSFR.ORG http://emacsfr.org/
Xavier Maillard Tel: +33 6 68 04 64 37

On 8 Jul 2005, drkm wrote:

> > Ça, c'est illusoire. Et sans doute inutile. L'intérêt de
> > 'drkm-conf:configure' c'est qu'il prend les infos
> > nécessaire à la gestion du chargement, les utilise, et
> > permet de placer toute la config du package dans un fichier
> > externe, qui ne sera chargé qu'au dernier moment.

> Euh, là je demande des explications.

Prenons par exemple Gnus (c'est un exemple extrême, oui).
Lorsque tu dis : « configurer un paquet entier en un seul appel
de fonction », ça veut dire que tu veux inclure tout ton .gnus
dans un unique appel.

'drkm-conf:configure' ne prend que les infos de configuration
du *chargement* du module. En l'occurence, ce serait où se
situe Gnus, le fichier de config, etc. (évidemment, avec Gnus,
c'est géré différemment).

Ok. Je comprends maintenant. Je confirme donc que je m'étais mal
exprimé. J'ai du mal à voir comment on peut arriver à faire ce
que je veux avec Gnus ;)

En fait Gnus ne tirerait partie de cette fonction qu'à minima
comme le fait actuellement drkm-conf:configure. Disons que ton
framework permet de faire déjà pas mal de choses "de base"
identiques pour tous les modules. Je veux simplement lui ajouter
quelques fonctionnalités pour aller plus loin et permettre de
faire quelques trucs supplémentaires pour des paquets de moyenne
envergure.

> Quelques exemples:

> 1. stringp et pas de alist: load-library
> 2. symbolp et pas de alist: require
> 3. symbolp et une alist: là soit un autoload soit un require
> sur
> chaque car
> ...

Ok. Je ne vois pas trop où tu coince. Tu utilise COND, les
tests qui vont bien, et les fonctions de chargement ad-hoc.
Qu'est-ce qui ne va pas, exactement ?

Moi ;) Ou plutôt c'est pas joli je trouve et du coup ça me
bloque.

On est d'accord que les requires ne sont pas applicables sur
les fonctions ? Alors je ne vois pas le problème. Tu génère un
autoload pour chaque fonction, c'est tout. Tu ne t'occupes pas
de require.

Certes, c'est en fait la solution à mes problèmes de "conscience"
et j'attendais que quelqu'un d'autre l'évoque. Donc oui, la
solution serait de faire un load-library ou un autoload pour
chaque fonction.

> J'ai pas l'habitude de faire des explications par écrit. Je
> préferre l'échange en direct. Sur USENET, ça parait
> compliqué :)

C'est quand même moins compliqué que de faire le
déplacement ;-)

;) Il faudra bien pourtant qu'un jour nous nous rencontrions tous
;(en ce serait sympa de mettre des visages sur tous ces noms :)).

A+ et merci pour le temps que tu passes à me répondre depuis
hier :)
--
In Gruuik we trust

Xavier Maillard <zedek@gnu-rox.org> writes:

On 8 Jul 2005, drkm wrote:

Je veux simplement lui ajouter
quelques fonctionnalités pour aller plus loin et permettre de
faire quelques trucs supplémentaires pour des paquets de moyenne
envergure.

Quels sont les « quelques trucs supplémentaires », exactement ?
Le fait de pouvoir spécifier autre chose qu'une fonction, si j'ai
bien compris. Et ensuite ?

Ok. Je ne vois pas trop où tu coince. Tu utilise COND, les
tests qui vont bien, et les fonctions de chargement ad-hoc.
Qu'est-ce qui ne va pas, exactement ?

Moi ;) Ou plutôt c'est pas joli je trouve et du coup ça me
bloque.

Pas joli ? Quoi ? Le COND ? Si tu préfères, tu peux avoir
une alist de ( fonction de test . fonction de traitement ). Ou
utiliser la syntaxe que j'ai introduite dans un autre article
utilisant un type explicite à l'appel (nommé par un symbole), et
une alist associant aux symboles de type les fonctions de
traitement. Ou stocker la fonction de traitement dans la plist
du symbole :

(put 'feature :load-ng-do-type 'require)
(put 'library :load-ng-do-type 'load-library)
(put ... :load-ng-do-type ...)

(defmacro load-ng (thing &rest args)
"..."
`(prog1
(,(get (car thing) :load-ng-do-type) ,(cdr thing))
...

(load-ng (feature boxquote)
...)

(load-ng (library "cc-mode")
...)

On est d'accord que les requires ne sont pas applicables sur
les fonctions ? Alors je ne vois pas le problème. Tu génère un
autoload pour chaque fonction, c'est tout. Tu ne t'occupes pas
de require.

Certes, c'est en fait la solution à mes problèmes de "conscience"
et j'attendais que quelqu'un d'autre l'évoque. Donc oui, la
solution serait de faire un load-library ou un autoload pour
chaque fonction.

Pourquoi 'load-library' ? Je génèrerais simplement les
autoloads. Où veux-tu introduire un 'load-library' ?

A+ et merci pour le temps que tu passes à me répondre depuis
hier :)

Pas de quoi. Ça me permet d'y voir plus clair, également :-).
Au fait, je me demande si l'on ne devient pas un peu HS (enfin,
fort spécifique) sur f.c.a.emacs ?

--drkm