Chargement d'une bibliothèque s'appliquant un type de fichier.
8 réponses
valrik
Bonjour =C3=A0 tous,
j'ai un tas de petites fonctions pratiques pour faire de la saisie de
code (html, C++, etc...). J'ai plac=C3=A9 celles-ci dans des fichiers
diff=C3=A9rents et je les charge au moyen de la fonction require.
L'inconv=C3=A9nient de cette m=C3=A9thode, c'est que mes fonctions personne=
lles
et les raccourcis clavier qui vont avec sont valides dans tous les
modes.
Afin d'=C3=A9viter des conflits entre tout ce petit monde, j'aimerais faire
en sorte qu'une biblioth=C3=A8que soit uniquement valide pour le mode
idoine.
Donc, les hooks me semblaient la solution la plus appropri=C3=A9e pour
atteindre cet objectif.
Ce que j'ai compris des hooks, pour le mode HTML par exemple, peut
=C3=AAtre r=C3=A9sum=C3=A9 ainsi :
Mais, si je charge ma biblioth=C3=A8que personnelle "html.el" gr=C3=A2ce =
=C3=A0 la
fonction my-html-library() en utilisant require, son usage est tout
aussi globale.
Il faut mettre dans le corps de my-html-library du code qui modifie des variables locales au buffer, ou du moins, qui ne touche qu'à des variables du mode html (en étant conscient que ça sera réexecuté à chaque fois qu'un buffer passe dans ce mode, donc il faut que ce soit involutif; certains modes ont un machinploum-mode-load-hook qui a l'avantage de n'être exécuté qu'une seule fois). Par exemple, des local-set-key, qui s'appliquent à la keymap du buffer, qui est en général partagée entre tous les buffers du même mode.
valrik@laposte.net :
Afin d'éviter des conflits entre tout ce petit monde, j'aimerais faire
en sorte qu'une bibliothèque soit uniquement valide pour le mode
idoine.
Donc, les hooks me semblaient la solution la plus appropriée pour
atteindre cet objectif.
Ce que j'ai compris des hooks, pour le mode HTML par exemple, peut
être résumé ainsi :
Il faut mettre dans le corps de my-html-library du code qui modifie des
variables locales au buffer, ou du moins, qui ne touche qu'à des variables
du mode html (en étant conscient que ça sera réexecuté à chaque fois qu'un
buffer passe dans ce mode, donc il faut que ce soit involutif; certains
modes ont un machinploum-mode-load-hook qui a l'avantage de n'être exécuté
qu'une seule fois). Par exemple, des local-set-key, qui s'appliquent à la
keymap du buffer, qui est en général partagée entre tous les buffers du même
mode.
Il faut mettre dans le corps de my-html-library du code qui modifie des variables locales au buffer, ou du moins, qui ne touche qu'à des variables du mode html (en étant conscient que ça sera réexecuté à chaque fois qu'un buffer passe dans ce mode, donc il faut que ce soit involutif; certains modes ont un machinploum-mode-load-hook qui a l'avantage de n'être exécuté qu'une seule fois). Par exemple, des local-set-key, qui s'appliquent à la keymap du buffer, qui est en général partagée entre tous les buffers du même mode.
Pascal J. Bourguignon
writes:
Bonjour à tous,
j'ai un tas de petites fonctions pratiques pour faire de la saisie de code (html, C++, etc...). J'ai placé celles-ci dans des fichiers différents et je les charge au moyen de la fonction require.
L'inconvénient de cette méthode, c'est que mes fonctions personnelles et les raccourcis clavier qui vont avec sont valides dans tous les modes.
Afin d'éviter des conflits entre tout ce petit monde, j'aimerais faire en sorte qu'une bibliothèque soit uniquement valide pour le mode idoine.
Donc, les hooks me semblaient la solution la plus appropriée pour atteindre cet objectif.
Ce que j'ai compris des hooks, pour le mode HTML par exemple, peut être résumé ainsi :
Mais, si je charge ma bibliothèque personnelle "html.el" grâce à la fonction my-html-library() en utilisant require, son usage est tout aussi globale.
Je reviens donc au point de départ.
Quelqu'un aurait-il une idée là dessus?
Défini des modes mineurs, cf. define-minor-mode.
Chaque mode mineur a une keymap dans laquelle tu pourras définir les bindings que tu veux. (info "(elisp) Defining Minor Modes") C-x C-e
Aussi, personnellement j'utilise H- (et secondairement A-) dans mes key-bindings, aussi il n'y a aucune collision. Sur les claviers actuels, il y a suffisament de touches sur la rangée du bas:
Control Return Shift Shift super Hyper Meta -------Space------- Meta Hyper super Alt
S- Shift C- Control M- Meta H- Hyper s- super A- Alt
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
valrik@laposte.net writes:
Bonjour à tous,
j'ai un tas de petites fonctions pratiques pour faire de la saisie de
code (html, C++, etc...). J'ai placé celles-ci dans des fichiers
différents et je les charge au moyen de la fonction require.
L'inconvénient de cette méthode, c'est que mes fonctions personnelles
et les raccourcis clavier qui vont avec sont valides dans tous les
modes.
Afin d'éviter des conflits entre tout ce petit monde, j'aimerais faire
en sorte qu'une bibliothèque soit uniquement valide pour le mode
idoine.
Donc, les hooks me semblaient la solution la plus appropriée pour
atteindre cet objectif.
Ce que j'ai compris des hooks, pour le mode HTML par exemple, peut
être résumé ainsi :
Mais, si je charge ma bibliothèque personnelle "html.el" grâce à la
fonction my-html-library() en utilisant require, son usage est tout
aussi globale.
Je reviens donc au point de départ.
Quelqu'un aurait-il une idée là dessus?
Défini des modes mineurs, cf. define-minor-mode.
Chaque mode mineur a une keymap dans laquelle tu pourras définir les
bindings que tu veux. (info "(elisp) Defining Minor Modes") C-x C-e
Aussi, personnellement j'utilise H- (et secondairement A-) dans mes
key-bindings, aussi il n'y a aucune collision. Sur les claviers
actuels, il y a suffisament de touches sur la rangée du bas:
Control Return
Shift Shift
super Hyper Meta -------Space------- Meta Hyper super Alt
S- Shift
C- Control
M- Meta
H- Hyper
s- super
A- Alt
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
j'ai un tas de petites fonctions pratiques pour faire de la saisie de code (html, C++, etc...). J'ai placé celles-ci dans des fichiers différents et je les charge au moyen de la fonction require.
L'inconvénient de cette méthode, c'est que mes fonctions personnelles et les raccourcis clavier qui vont avec sont valides dans tous les modes.
Afin d'éviter des conflits entre tout ce petit monde, j'aimerais faire en sorte qu'une bibliothèque soit uniquement valide pour le mode idoine.
Donc, les hooks me semblaient la solution la plus appropriée pour atteindre cet objectif.
Ce que j'ai compris des hooks, pour le mode HTML par exemple, peut être résumé ainsi :
Mais, si je charge ma bibliothèque personnelle "html.el" grâce à la fonction my-html-library() en utilisant require, son usage est tout aussi globale.
Je reviens donc au point de départ.
Quelqu'un aurait-il une idée là dessus?
Défini des modes mineurs, cf. define-minor-mode.
Chaque mode mineur a une keymap dans laquelle tu pourras définir les bindings que tu veux. (info "(elisp) Defining Minor Modes") C-x C-e
Aussi, personnellement j'utilise H- (et secondairement A-) dans mes key-bindings, aussi il n'y a aucune collision. Sur les claviers actuels, il y a suffisament de touches sur la rangée du bas:
Control Return Shift Shift super Hyper Meta -------Space------- Meta Hyper super Alt
S- Shift C- Control M- Meta H- Hyper s- super A- Alt
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
valrik
(Luc Habert) writes:
Il faut mettre dans le corps de my-html-library du code qui modifie des variables locales au buffer, ou du moins, qui ne touche qu'Ã des var iables du mode html...
Il faut mettre dans le corps de my-html-library du code qui modifie des
variables locales au buffer, ou du moins, qui ne touche qu'Ã des var iables
du mode html...
Il faut mettre dans le corps de my-html-library du code qui modifie des variables locales au buffer, ou du moins, qui ne touche qu'Ã des var iables du mode html...
Control Return Shift Shift super Hyper Meta -------Space------- Meta Hyper super Alt
S- Shift C- Control M- Meta H- Hyper s- super A- Alt
Luc.Habert.00__arjf
:
Donc, si je comprends bien, le hook ne peut servir qu'à opérer des définitions de variables "locales" appartenant au buffer?
Il peut servir à n'importe quoi, mais c'est plus logique de ne toucher qu'à des choses plus ou moins locales. Je dis plus ou moins parce que la keymap est en général "locale au mode" et non au buffer.
Si je cherche à définir des fonctions par ce biais, elles seront forcément globales?
Une définition de fonction via defun est toujours globale. On peut faire une définition locale en stockant un lambda dans une variable locale, mais la syntaxe d'appel est chiante, donc en pratique, on ne s'* pas et on fait des définitions globales, en namespaçant à la main avec des prefixes.
(en étant conscient que ça sera réexecuté à chaque fois qu'un buffer passe dans ce mode, donc il faut que ce soit involutif;...
involutif? J'avoue ne pas connaître cette notion. J'ai trouvé une entrée wikipedia, mais en math...
Bah oui, l'info, c'est des maths. Une fonction involutive, en maths, c'est une fonction telle que f(f(x)) = f(x). En l'occurence, je veux dire que si l'on appelle plus d'une fois la fonction, on ne doit pas changer l'état des variables globales après le premier appel (donc dans le formalisme de la phrase précédente, x est l'état global et non un éventuel argument à la fonction elisp, qui a priori est sans argument).
Donc, si je comprends bien, le hook ne peut servir qu'à opérer des
définitions de variables "locales" appartenant au buffer?
Il peut servir à n'importe quoi, mais c'est plus logique de ne toucher qu'à
des choses plus ou moins locales. Je dis plus ou moins parce que la keymap
est en général "locale au mode" et non au buffer.
Si je cherche à définir des fonctions par ce biais, elles seront
forcément globales?
Une définition de fonction via defun est toujours globale. On peut faire une
définition locale en stockant un lambda dans une variable locale, mais la
syntaxe d'appel est chiante, donc en pratique, on ne s'* pas et on fait des
définitions globales, en namespaçant à la main avec des prefixes.
(en étant conscient que ça sera réexecuté à chaque fois qu'un
buffer passe dans ce mode, donc il faut que ce soit involutif;...
involutif? J'avoue ne pas connaître cette notion. J'ai trouvé une
entrée wikipedia, mais en math...
Bah oui, l'info, c'est des maths. Une fonction involutive, en maths, c'est
une fonction telle que f(f(x)) = f(x). En l'occurence, je veux dire que si
l'on appelle plus d'une fois la fonction, on ne doit pas changer l'état
des variables globales après le premier appel (donc dans le formalisme de la
phrase précédente, x est l'état global et non un éventuel argument à la
fonction elisp, qui a priori est sans argument).
Donc, si je comprends bien, le hook ne peut servir qu'à opérer des définitions de variables "locales" appartenant au buffer?
Il peut servir à n'importe quoi, mais c'est plus logique de ne toucher qu'à des choses plus ou moins locales. Je dis plus ou moins parce que la keymap est en général "locale au mode" et non au buffer.
Si je cherche à définir des fonctions par ce biais, elles seront forcément globales?
Une définition de fonction via defun est toujours globale. On peut faire une définition locale en stockant un lambda dans une variable locale, mais la syntaxe d'appel est chiante, donc en pratique, on ne s'* pas et on fait des définitions globales, en namespaçant à la main avec des prefixes.
(en étant conscient que ça sera réexecuté à chaque fois qu'un buffer passe dans ce mode, donc il faut que ce soit involutif;...
involutif? J'avoue ne pas connaître cette notion. J'ai trouvé une entrée wikipedia, mais en math...
Bah oui, l'info, c'est des maths. Une fonction involutive, en maths, c'est une fonction telle que f(f(x)) = f(x). En l'occurence, je veux dire que si l'on appelle plus d'une fois la fonction, on ne doit pas changer l'état des variables globales après le premier appel (donc dans le formalisme de la phrase précédente, x est l'état global et non un éventuel argument à la fonction elisp, qui a priori est sans argument).
OK, je ne suis pas encore très au fait de ce sujet, mais je vais m'y mettre. J'ai cru comprendre que cela demandait pas mal d'effort.
Ça dépend, il y a des modes qui sont simple, et on peut en faire d'aussi compliqué que l'on veut.
Chaque mode mineur a une keymap dans laquelle tu pourras définir les bindings que tu veux. (info "(elisp) Defining Minor Modes") C-x C-e
Chez moi, la commande ne passe pas... Je ne sais pas pourquoi les pages info d'Emacs ne sont pas installées d'office sur une Debian! J'ai cherché un peu, mais comme je manque de temps, je n'ai pas creusé de ce coté : avis aux Debianistes qui passent par là! ;-)
En fait, l'idée est de rendre les key bindings locaux à un buffer, sans se soucier de la porté des fonctions?
Il est vrai, qu'avec mes nons de fonctions très "frenchy", je ne risque pas le conflit avec les fonctions "natives" d'Emacs. :-))
Oui, c'est une solution valable :-)
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
valrik@laposte.net writes:
"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
Défini des modes mineurs, cf. define-minor-mode.
OK, je ne suis pas encore très au fait de ce sujet, mais je vais m'y
mettre. J'ai cru comprendre que cela demandait pas mal d'effort.
Ça dépend, il y a des modes qui sont simple, et on peut en faire d'aussi
compliqué que l'on veut.
Chaque mode mineur a une keymap dans laquelle tu pourras définir les
bindings que tu veux. (info "(elisp) Defining Minor Modes") C-x C-e
Chez moi, la commande ne passe pas... Je ne sais pas pourquoi les
pages info d'Emacs ne sont pas installées d'office sur une Debian!
J'ai cherché un peu, mais comme je manque de temps, je n'ai pas creusé
de ce coté : avis aux Debianistes qui passent par là! ;-)
En fait, l'idée est de rendre les key bindings locaux à un buffer,
sans se soucier de la porté des fonctions?
Il est vrai, qu'avec mes nons de fonctions très "frenchy", je ne
risque pas le conflit avec les fonctions "natives" d'Emacs. :-))
Oui, c'est une solution valable :-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
OK, je ne suis pas encore très au fait de ce sujet, mais je vais m'y mettre. J'ai cru comprendre que cela demandait pas mal d'effort.
Ça dépend, il y a des modes qui sont simple, et on peut en faire d'aussi compliqué que l'on veut.
Chaque mode mineur a une keymap dans laquelle tu pourras définir les bindings que tu veux. (info "(elisp) Defining Minor Modes") C-x C-e
Chez moi, la commande ne passe pas... Je ne sais pas pourquoi les pages info d'Emacs ne sont pas installées d'office sur une Debian! J'ai cherché un peu, mais comme je manque de temps, je n'ai pas creusé de ce coté : avis aux Debianistes qui passent par là! ;-)
En fait, l'idée est de rendre les key bindings locaux à un buffer, sans se soucier de la porté des fonctions?
Il est vrai, qu'avec mes nons de fonctions très "frenchy", je ne risque pas le conflit avec les fonctions "natives" d'Emacs. :-))
Oui, c'est une solution valable :-)
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
