dans le cadre des récents fils sur l'intégration de version custom ou cvs à
la configuration standard, de la modification des paths, etc., je suis en
train de remanier mes fichiers de configuration.
Je profite avec bonheur des trucs et conseils que vous me prodiguez ici
ainsi que de parfois de fonctions entières. Habituellement je place ces
fonctions vers la fin du .emacs mais ça commence à grossir.
Second problème : drkm me conseillait dernièrement une fonction pour
modifier le load-path que je devrais placer en début de mon .emcs mais je ne
trouve pas cette idée élégante et ça nuit à la lisibilité (àma) du fichier.
Est-il possible d'appeler en début de fichier une fonction qui n'est définie
que plus tard dans le fichier ?
Faudrait-il plutôt regrouper cette fonction avec d'autres à venir dans un
autre module et passer par un require ?
Quels conseils ou réflexions pouvez-vous me donner concernant l'organisation
des fichiers de conf ? Je sais que certains d'entre vous (drkm, zeDek) sont
en plein dedans, alors c'est le moment d'en parler :)
(Je précise que je suis développeur et que j'essaie d'améliorer mon niveau
de lisp pour pouvoir écrire du code au lieu de simplement deviner le
fonctionnement de modules et bricoler ma config, aussi je n'ai rien contre
mettre les mains dans le cambouis et taper du code pour arriver à ce que je
recherche)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
drkm
Sébastien Kirche wrote:
Second problème : drkm me conseillait dernièrement une
fonction pour
modifier le load-path que je devrais placer en début de mon .emcs
mais je ne
trouve pas cette idée élégante et ça nuit à la lisibilité
(àma) du fichier.
Est-il possible d'appeler en début de fichier une fonction qui n'est
définie
que plus tard dans le fichier ?
Non. Personnellement, je trouve qu'un point extremement important est la decoupe du code. Le fait d'avoir une section de "pre-requis" n'est pas tres grave, si tu utilises les commentaires qui vont bien pour avoir une decoupe interessante :
;;; Pre-requis. [...] ;;; Edition de texte. [...] ;;; Langages de programmation. [...]
Faudrait-il plutôt regrouper cette fonction avec d'autres à venir
dans un
autre module et passer par un require ?
C'est le pas supplementaire. Partant de la decouope ci-dessus, tu peux utiliser plusieurs fichiers. Cela a le merite de clarifier un peu ces fichiers s'il deviennent trop gros.
Mais surtout, tu peux te developper tes outils pour afire en sorte que tout ne soit pas charge inconditionnellement. Mais seulement lorsque tu l'utilises. Mon propre .emacs (hors commentaires), ne contient que :
C'est a dire que je charge drkm-config (que je configure elle-meme un peu), puis j'appelle drkm-conf:init (c'est la que par exemple le load-path est parcouru a la recherche des Subdirs Files, etc.). Apres quoi, je charge chaque aspect de ma config.
Le truc, c'est que la plupart ne contiennent principalement que des appels a drkm-conf:configure. Dans top-config-prog.el, par exemple, j'ai des appels comme :
Cela represente, hors commentaires, la moitie ou le tiers du fichier. Ce qui reste raisonnable. A la premiere utilisation de perl-mode ou cperl-mode, config-perl.el sera charge. De meme pour sql-mode et config-sql.el. Ou c-mode, c++-mode, objc-mode, java-mode, idl-mode, pike-mode et awk-mode pour config-cc-mode.el.
Au passage, j'ai quand meme specifie les valeurs necessaires pour auto-mode-alist et interpreter-mode-alist, afin de pouvoir determiner le bon mode a employer.
Mais je ne suis pas vraiment content pour l'instant de drkm-conf:configure. Ni reellement de son interface, ni surtout de son implementation. Mais je pense qu'il y a des concepts interessants a developper (lorsque j'aurai plus de temps, c'est toujours la meme rengaine :-p).
Je pense qu'il est temps que je clarifie ces points, et que je documente clairement le tout. Un jour, peut-etre (on peut rever), cela arrivera.
--drkm
Sébastien Kirche wrote:
Second problème : drkm me conseillait dernièrement une
fonction pour
modifier le load-path que je devrais placer en début de mon .emcs
mais je ne
trouve pas cette idée élégante et ça nuit à la lisibilité
(àma) du fichier.
Est-il possible d'appeler en début de fichier une fonction qui n'est
définie
que plus tard dans le fichier ?
Non. Personnellement, je trouve qu'un point extremement important
est la decoupe du code. Le fait d'avoir une section de "pre-requis"
n'est pas tres grave, si tu utilises les commentaires qui vont bien
pour avoir une decoupe interessante :
;;; Pre-requis.
[...]
;;; Edition de texte.
[...]
;;; Langages de programmation.
[...]
Faudrait-il plutôt regrouper cette fonction avec d'autres à venir
dans un
autre module et passer par un require ?
C'est le pas supplementaire. Partant de la decouope ci-dessus, tu
peux utiliser plusieurs fichiers. Cela a le merite de clarifier un
peu ces fichiers s'il deviennent trop gros.
Mais surtout, tu peux te developper tes outils pour afire en sorte
que tout ne soit pas charge inconditionnellement. Mais seulement
lorsque tu l'utilises. Mon propre .emacs (hors commentaires), ne
contient que :
C'est a dire que je charge drkm-config (que je configure elle-meme
un peu), puis j'appelle drkm-conf:init (c'est la que par exemple le
load-path est parcouru a la recherche des Subdirs Files, etc.). Apres
quoi, je charge chaque aspect de ma config.
Le truc, c'est que la plupart ne contiennent principalement que des
appels a drkm-conf:configure. Dans top-config-prog.el, par exemple,
j'ai des appels comme :
Cela represente, hors commentaires, la moitie ou le tiers du
fichier. Ce qui reste raisonnable. A la premiere utilisation de
perl-mode ou cperl-mode, config-perl.el sera charge. De meme pour
sql-mode et config-sql.el. Ou c-mode, c++-mode, objc-mode, java-mode,
idl-mode, pike-mode et awk-mode pour config-cc-mode.el.
Au passage, j'ai quand meme specifie les valeurs necessaires pour
auto-mode-alist et interpreter-mode-alist, afin de pouvoir determiner
le bon mode a employer.
Mais je ne suis pas vraiment content pour l'instant de
drkm-conf:configure. Ni reellement de son interface, ni surtout de
son implementation. Mais je pense qu'il y a des concepts interessants
a developper (lorsque j'aurai plus de temps, c'est toujours la meme
rengaine :-p).
Je pense qu'il est temps que je clarifie ces points, et que je
documente clairement le tout. Un jour, peut-etre (on peut rever),
cela arrivera.
Second problème : drkm me conseillait dernièrement une
fonction pour
modifier le load-path que je devrais placer en début de mon .emcs
mais je ne
trouve pas cette idée élégante et ça nuit à la lisibilité
(àma) du fichier.
Est-il possible d'appeler en début de fichier une fonction qui n'est
définie
que plus tard dans le fichier ?
Non. Personnellement, je trouve qu'un point extremement important est la decoupe du code. Le fait d'avoir une section de "pre-requis" n'est pas tres grave, si tu utilises les commentaires qui vont bien pour avoir une decoupe interessante :
;;; Pre-requis. [...] ;;; Edition de texte. [...] ;;; Langages de programmation. [...]
Faudrait-il plutôt regrouper cette fonction avec d'autres à venir
dans un
autre module et passer par un require ?
C'est le pas supplementaire. Partant de la decouope ci-dessus, tu peux utiliser plusieurs fichiers. Cela a le merite de clarifier un peu ces fichiers s'il deviennent trop gros.
Mais surtout, tu peux te developper tes outils pour afire en sorte que tout ne soit pas charge inconditionnellement. Mais seulement lorsque tu l'utilises. Mon propre .emacs (hors commentaires), ne contient que :
C'est a dire que je charge drkm-config (que je configure elle-meme un peu), puis j'appelle drkm-conf:init (c'est la que par exemple le load-path est parcouru a la recherche des Subdirs Files, etc.). Apres quoi, je charge chaque aspect de ma config.
Le truc, c'est que la plupart ne contiennent principalement que des appels a drkm-conf:configure. Dans top-config-prog.el, par exemple, j'ai des appels comme :
Cela represente, hors commentaires, la moitie ou le tiers du fichier. Ce qui reste raisonnable. A la premiere utilisation de perl-mode ou cperl-mode, config-perl.el sera charge. De meme pour sql-mode et config-sql.el. Ou c-mode, c++-mode, objc-mode, java-mode, idl-mode, pike-mode et awk-mode pour config-cc-mode.el.
Au passage, j'ai quand meme specifie les valeurs necessaires pour auto-mode-alist et interpreter-mode-alist, afin de pouvoir determiner le bon mode a employer.
Mais je ne suis pas vraiment content pour l'instant de drkm-conf:configure. Ni reellement de son interface, ni surtout de son implementation. Mais je pense qu'il y a des concepts interessants a developper (lorsque j'aurai plus de temps, c'est toujours la meme rengaine :-p).
Je pense qu'il est temps que je clarifie ces points, et que je documente clairement le tout. Un jour, peut-etre (on peut rever), cela arrivera.
