je suis tombé sur un os en réécrivant mes variables dans le .emacs
concernant le load-path.
Voici un extrait du début du .emacs :
8<------8<------8<------8<------8<------8<------8<------8<------8<------
;; Déterminer si on emploie Emacs ou XEmacs
(defvar sk:is-xemacs (string-match "XEmacs" emacs-version)
"Variable interne différente de nil si on est dans XEmacs")
;;chez moi
(defvar sk:home (expand-file-name "~/") "Home sweet home")
;; Ajouter mon répertoire personnel à la liste des chemins de recherche
;(defvar sk:elisp-path (concat sk:home ".elisp/") "Chemin vers mes packages elisp")
(defvar sk:elisp-path "~/.elisp" "Chemin vers mes packages elisp")
(if sk:is-xemacs
(setq sk:elisp-path (expand-file-name sk:elisp-path)))
Vous pouvez remarquer que dans l'écriture actuelle
- sk:home vaut "/Users/seki/"
- sk:elisp-path vaut "~/.elisp"
Lorsque je décommente la ligne du defvar sk:elisp-path (à ce moment commente
la seconde version et le test sur sk:is-xemacs) je remarque que
normal-top-level-add-subdirs-to-load-path ne fonctionne plus pareil : les
répertoires présents dans sk:elisp-path (qui vaut "/Users/seki/.elisp/")
sont ajoutés à la fin.
Ce qui fait que certaines librairies plus récentes sont ignorées au profit
de celles incluses dans emacs.
Ça m'a cassé entre autres ecb qui ne trouve plus la speedbar fournie dans
cedet mais celle d'emacs et ça ne fonctionne plus (j'ai eu du mal à trouver
ce problème)
Vous comprenez pourquoi ça se passe comme cela ? La lecture du code de
normal-top-... ne m'a pas renseigné.
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 writes:
Lorsque je décommente la ligne du defvar sk:elisp-path (à ce moment commente la seconde version et le test sur sk:is-xemacs) je remarque que normal-top-level-add-subdirs-to-load-path ne fonctionne plus pareil : les répertoires présents dans sk:elisp-path (qui vaut "/Users/seki/.elisp/") sont ajoutés à la fin.
Après un rapide coup d'oeil à normal-top-level-add-to-load-path, qu'appelle normal-top-level-add-subdirs-to-load-path pour effectivement ajouter les répertoires au load-path, il semble bien que l'ajout est fait à la fin (regarde la condition de la boucle while).
Très franchement, je te conseille de faire ta propre fonction, fournissant exactement la sémantique dont tu as besoin/que tu désires.
Tu peux regarder dans drkm-config.el, il y a quelque chose du même style (ahem, si je me souviens bien, en fait, elle n'est pas du tout propre, j'étais parti sur une détection complète des erreurs, mais c'est extrêmement laid, si je me souviens bien).
--drkm
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
Lorsque je décommente la ligne du defvar sk:elisp-path (à ce moment commente
la seconde version et le test sur sk:is-xemacs) je remarque que
normal-top-level-add-subdirs-to-load-path ne fonctionne plus pareil : les
répertoires présents dans sk:elisp-path (qui vaut "/Users/seki/.elisp/")
sont ajoutés à la fin.
Après un rapide coup d'oeil à normal-top-level-add-to-load-path,
qu'appelle normal-top-level-add-subdirs-to-load-path pour
effectivement ajouter les répertoires au load-path, il semble bien que
l'ajout est fait à la fin (regarde la condition de la boucle while).
Très franchement, je te conseille de faire ta propre fonction,
fournissant exactement la sémantique dont tu as besoin/que tu désires.
Tu peux regarder dans drkm-config.el, il y a quelque chose du même
style (ahem, si je me souviens bien, en fait, elle n'est pas du tout
propre, j'étais parti sur une détection complète des erreurs, mais
c'est extrêmement laid, si je me souviens bien).
Lorsque je décommente la ligne du defvar sk:elisp-path (à ce moment commente la seconde version et le test sur sk:is-xemacs) je remarque que normal-top-level-add-subdirs-to-load-path ne fonctionne plus pareil : les répertoires présents dans sk:elisp-path (qui vaut "/Users/seki/.elisp/") sont ajoutés à la fin.
Après un rapide coup d'oeil à normal-top-level-add-to-load-path, qu'appelle normal-top-level-add-subdirs-to-load-path pour effectivement ajouter les répertoires au load-path, il semble bien que l'ajout est fait à la fin (regarde la condition de la boucle while).
Très franchement, je te conseille de faire ta propre fonction, fournissant exactement la sémantique dont tu as besoin/que tu désires.
Tu peux regarder dans drkm-config.el, il y a quelque chose du même style (ahem, si je me souviens bien, en fait, elle n'est pas du tout propre, j'étais parti sur une détection complète des erreurs, mais c'est extrêmement laid, si je me souviens bien).
--drkm
Sébastien Kirche
Le 6 Apr 2005, drkm a dit :
Après un rapide coup d'oeil à normal-top-level-add-to-load-path, qu'appelle normal-top-level-add-subdirs-to-load-path pour effectivement ajouter les répertoires au load-path, il semble bien que l'ajout est fait à la fin (regarde la condition de la boucle while).
Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en l'appelant inconditionnellement et sans) et que mon chemin est ~/.elisp/ tout se passe comme je veux et mon répertoire cedet (avec sa version de speedbar) est pris en charge.
Bizarre.
Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais plus où j'ai pêché ça mais ça ne vient certainement pas de moi. J'ai sans doute trouvé ça en cherchant comment avoir un répertoire lisp perso à ajouter au load-path...
Je vais regarder ta solution. Merci.
-- Sébastien Kirche
Le 6 Apr 2005, drkm a dit :
Après un rapide coup d'oeil à normal-top-level-add-to-load-path,
qu'appelle normal-top-level-add-subdirs-to-load-path pour
effectivement ajouter les répertoires au load-path, il semble bien que
l'ajout est fait à la fin (regarde la condition de la boucle while).
Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en l'appelant
inconditionnellement et sans) et que mon chemin est ~/.elisp/ tout se passe
comme je veux et mon répertoire cedet (avec sa version de speedbar) est pris
en charge.
Bizarre.
Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais plus
où j'ai pêché ça mais ça ne vient certainement pas de moi. J'ai sans doute
trouvé ça en cherchant comment avoir un répertoire lisp perso à ajouter au
load-path...
Après un rapide coup d'oeil à normal-top-level-add-to-load-path, qu'appelle normal-top-level-add-subdirs-to-load-path pour effectivement ajouter les répertoires au load-path, il semble bien que l'ajout est fait à la fin (regarde la condition de la boucle while).
Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en l'appelant inconditionnellement et sans) et que mon chemin est ~/.elisp/ tout se passe comme je veux et mon répertoire cedet (avec sa version de speedbar) est pris en charge.
Bizarre.
Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais plus où j'ai pêché ça mais ça ne vient certainement pas de moi. J'ai sans doute trouvé ça en cherchant comment avoir un répertoire lisp perso à ajouter au load-path...
Je vais regarder ta solution. Merci.
-- Sébastien Kirche
drkm
Sébastien Kirche writes:
Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en l'appelant inconditionnellement et sans) et que mon chemin est ~/.elisp/ tout se passe comme je veux et mon répertoire cedet (avec sa version de speedbar) est pris en charge.
Ah, d'accord. Ce serait donc à cause de l'appel à expand-file-name. Waw, c'est bizarre. Bon, a priori, le seul endroit où la position d'insertion peut changer est dans normal-top-level-add-to-load-path. Et le seul rapport avec une différence dans la chaîne de caractères identifiant le répertoire est un equal appelé dans la condition du while.
Essaies-tu d'insérer un répertoire qui se trouve déjà dans le load-path ? Peut-être le fait de poster la valeur du load-path juste avant et juste après pourrait aider (il y a tout de même une bonne partie inintéressante, avec les répertoires de site-lisp, que tu peux couper).
Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais plus où j'ai pêché ça
Moi je sais :-). <FILE:[emacs]/site-lisp/subdirs.el>.
--drkm
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en l'appelant
inconditionnellement et sans) et que mon chemin est ~/.elisp/ tout se passe
comme je veux et mon répertoire cedet (avec sa version de speedbar) est pris
en charge.
Ah, d'accord. Ce serait donc à cause de l'appel à expand-file-name.
Waw, c'est bizarre. Bon, a priori, le seul endroit où la position
d'insertion peut changer est dans normal-top-level-add-to-load-path.
Et le seul rapport avec une différence dans la chaîne de caractères
identifiant le répertoire est un equal appelé dans la condition du
while.
Essaies-tu d'insérer un répertoire qui se trouve déjà dans le
load-path ? Peut-être le fait de poster la valeur du load-path juste
avant et juste après pourrait aider (il y a tout de même une bonne
partie inintéressante, avec les répertoires de site-lisp, que tu peux
couper).
Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais plus
où j'ai pêché ça
Moi je sais :-). <FILE:[emacs]/site-lisp/subdirs.el>.
Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en l'appelant inconditionnellement et sans) et que mon chemin est ~/.elisp/ tout se passe comme je veux et mon répertoire cedet (avec sa version de speedbar) est pris en charge.
Ah, d'accord. Ce serait donc à cause de l'appel à expand-file-name. Waw, c'est bizarre. Bon, a priori, le seul endroit où la position d'insertion peut changer est dans normal-top-level-add-to-load-path. Et le seul rapport avec une différence dans la chaîne de caractères identifiant le répertoire est un equal appelé dans la condition du while.
Essaies-tu d'insérer un répertoire qui se trouve déjà dans le load-path ? Peut-être le fait de poster la valeur du load-path juste avant et juste après pourrait aider (il y a tout de même une bonne partie inintéressante, avec les répertoires de site-lisp, que tu peux couper).
Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais plus où j'ai pêché ça
Moi je sais :-). <FILE:[emacs]/site-lisp/subdirs.el>.
--drkm
Sébastien Kirche
Le 6 avr 2005, drkm a formulé :
Sébastien Kirche writes:
> Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en > l'appelant inconditionnellement et sans) et que mon chemin est ~/.elisp/ > tout se passe comme je veux et mon répertoire cedet (avec sa version de > speedbar) est pris en charge.
Ah, d'accord. Ce serait donc à cause de l'appel à expand-file-name.
Ben en fait non. J'ai fait quelques essais chez moi où je reproduis le problème et ça se situe plutôt au niveau du / final de ".elisp/".
Si sk:elisp-path vaut "~/.elisp" la suite fonctionne. S'il vaut "~/.elisp/" ça cafouille car mes répertoires sont à la fin.
Waw, c'est bizarre. Bon, a priori, le seul endroit où la position d'insertion peut changer est dans normal-top-level-add-to-load-path. Et le seul rapport avec une différence dans la chaîne de caractères identifiant le répertoire est un equal appelé dans la condition du while.
Essaies-tu d'insérer un répertoire qui se trouve déjà dans le load-path ? Peut-être le fait de poster la valeur du load-path juste avant et juste après pourrait aider (il y a tout de même une bonne partie inintéressante, avec les répertoires de site-lisp, que tu peux couper).
En annexe je joint la version avec et sans slash final du nom de répertoire. C'est assez moche mais tu verras que dans un cas la speedbar (c'est la lib qui m'a mis le doigt sur le problème) qui est au début du load-path est la version emacs, dans l'autre c'est celle que j'ai en local chez moi.
> Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais > plus où j'ai pêché ça
Moi je sais :-). <FILE:[emacs]/site-lisp/subdirs.el>.
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
> Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en
> l'appelant inconditionnellement et sans) et que mon chemin est ~/.elisp/
> tout se passe comme je veux et mon répertoire cedet (avec sa version de
> speedbar) est pris en charge.
Ah, d'accord. Ce serait donc à cause de l'appel à expand-file-name.
Ben en fait non. J'ai fait quelques essais chez moi où je reproduis le
problème et ça se situe plutôt au niveau du / final de ".elisp/".
Si sk:elisp-path vaut "~/.elisp" la suite fonctionne.
S'il vaut "~/.elisp/" ça cafouille car mes répertoires sont à la fin.
Waw, c'est bizarre. Bon, a priori, le seul endroit où la position
d'insertion peut changer est dans normal-top-level-add-to-load-path.
Et le seul rapport avec une différence dans la chaîne de caractères
identifiant le répertoire est un equal appelé dans la condition du
while.
Essaies-tu d'insérer un répertoire qui se trouve déjà dans le
load-path ? Peut-être le fait de poster la valeur du load-path juste
avant et juste après pourrait aider (il y a tout de même une bonne
partie inintéressante, avec les répertoires de site-lisp, que tu peux
couper).
En annexe je joint la version avec et sans slash final du nom de répertoire.
C'est assez moche mais tu verras que dans un cas la speedbar (c'est la lib qui
m'a mis le doigt sur le problème) qui est au début du load-path est la
version emacs, dans l'autre c'est celle que j'ai en local chez moi.
> Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais
> plus où j'ai pêché ça
Moi je sais :-). <FILE:[emacs]/site-lisp/subdirs.el>.
> Et pourtant, si je n'appelle pas expand-file-name (j'ai essayé en > l'appelant inconditionnellement et sans) et que mon chemin est ~/.elisp/ > tout se passe comme je veux et mon répertoire cedet (avec sa version de > speedbar) est pris en charge.
Ah, d'accord. Ce serait donc à cause de l'appel à expand-file-name.
Ben en fait non. J'ai fait quelques essais chez moi où je reproduis le problème et ça se situe plutôt au niveau du / final de ".elisp/".
Si sk:elisp-path vaut "~/.elisp" la suite fonctionne. S'il vaut "~/.elisp/" ça cafouille car mes répertoires sont à la fin.
Waw, c'est bizarre. Bon, a priori, le seul endroit où la position d'insertion peut changer est dans normal-top-level-add-to-load-path. Et le seul rapport avec une différence dans la chaîne de caractères identifiant le répertoire est un equal appelé dans la condition du while.
Essaies-tu d'insérer un répertoire qui se trouve déjà dans le load-path ? Peut-être le fait de poster la valeur du load-path juste avant et juste après pourrait aider (il y a tout de même une bonne partie inintéressante, avec les répertoires de site-lisp, que tu peux couper).
En annexe je joint la version avec et sans slash final du nom de répertoire. C'est assez moche mais tu verras que dans un cas la speedbar (c'est la lib qui m'a mis le doigt sur le problème) qui est au début du load-path est la version emacs, dans l'autre c'est celle que j'ai en local chez moi.
> Quand à l'appel de normal-top-level-add-subdirs-to-load-path je ne sais > plus où j'ai pêché ça
Moi je sais :-). <FILE:[emacs]/site-lisp/subdirs.el>.
Ok, je pense avoir compris le problème. D'après la condition du while, la sémantique de normal-top-level-add-to-load-path semble être d'ajouter la liste des sous-répertoires du répertoire courant juste après ce répertoire courant dans le load-path. S'il ne s'y trouve pas, on se retrouve à la fin du load-path pour l'insertion.
Pour faire la comparaison, elle utilise equal, et le nom du répertoire courant passé à directory-file-name. Le nom inséré ne doit donc pas contenir de slash final. Le mieux, ÀMHA, serait d'utiliser directory-file-name à l'insertion :
(defun sk:add-dir-and-subdirs-to-load-path (dir) "Je te laisse ce soin ..." ;; Pourrait être une commande. Pourquoi pas ? Je te laisse ;; chercher après le code qui va bien ... ;; (interactive "...") (push (directory-file-name dir) load-path) (let ((default-directory dir)) (normal-top-level-add-subdirs-to-load-path)))
(defvar sk:elisp-path (drkm-file:file-in-dir ".elisp/" sk:home-dir) "Je te laisse ce soin ...") (sk:add-dir-and-subdirs-to-load-path sk:elisp-path)
Attention, non testé. Dis-nous si ça fonctionne.
--drkm
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
[...]
Ok, je pense avoir compris le problème. D'après la condition du
while, la sémantique de normal-top-level-add-to-load-path semble être
d'ajouter la liste des sous-répertoires du répertoire courant juste
après ce répertoire courant dans le load-path. S'il ne s'y trouve
pas, on se retrouve à la fin du load-path pour l'insertion.
Pour faire la comparaison, elle utilise equal, et le nom du
répertoire courant passé à directory-file-name. Le nom inséré ne doit
donc pas contenir de slash final. Le mieux, ÀMHA, serait d'utiliser
directory-file-name à l'insertion :
(defun sk:add-dir-and-subdirs-to-load-path (dir)
"Je te laisse ce soin ..."
;; Pourrait être une commande. Pourquoi pas ? Je te laisse
;; chercher après le code qui va bien ...
;; (interactive "...")
(push (directory-file-name dir) load-path)
(let ((default-directory dir))
(normal-top-level-add-subdirs-to-load-path)))
(defvar sk:elisp-path (drkm-file:file-in-dir ".elisp/" sk:home-dir)
"Je te laisse ce soin ...")
(sk:add-dir-and-subdirs-to-load-path sk:elisp-path)
Ok, je pense avoir compris le problème. D'après la condition du while, la sémantique de normal-top-level-add-to-load-path semble être d'ajouter la liste des sous-répertoires du répertoire courant juste après ce répertoire courant dans le load-path. S'il ne s'y trouve pas, on se retrouve à la fin du load-path pour l'insertion.
Pour faire la comparaison, elle utilise equal, et le nom du répertoire courant passé à directory-file-name. Le nom inséré ne doit donc pas contenir de slash final. Le mieux, ÀMHA, serait d'utiliser directory-file-name à l'insertion :
(defun sk:add-dir-and-subdirs-to-load-path (dir) "Je te laisse ce soin ..." ;; Pourrait être une commande. Pourquoi pas ? Je te laisse ;; chercher après le code qui va bien ... ;; (interactive "...") (push (directory-file-name dir) load-path) (let ((default-directory dir)) (normal-top-level-add-subdirs-to-load-path)))
(defvar sk:elisp-path (drkm-file:file-in-dir ".elisp/" sk:home-dir) "Je te laisse ce soin ...") (sk:add-dir-and-subdirs-to-load-path sk:elisp-path)
Attention, non testé. Dis-nous si ça fonctionne.
--drkm
Sébastien Kirche
Le 7 Apr 2005, drkm a formulé :
Sébastien Kirche writes:
[...]
Ok, je pense avoir compris le problème. D'après la condition du while, la sémantique de normal-top-level-add-to-load-path semble être d'ajouter la liste des sous-répertoires du répertoire courant juste après ce répertoire courant dans le load-path. S'il ne s'y trouve pas, on se retrouve à la fin du load-path pour l'insertion.
Pour faire la comparaison, elle utilise equal, et le nom du répertoire courant passé à directory-file-name.
Ok, je comprends mieux.
Le nom inséré ne doit donc pas contenir de slash final.
En fait cela m'importe peu. Le tout est d'être cohérent tout au long du fichier, et je me suis retrouvé dans un cas bancale.
Quelle convention utilisez-vous pour la désignation d'un répertoire en général (fichiers de conf ou autres) ? Par exemple pour le home : ~ ou ~/ ?
Je me disais que de voir un slash final permettait de différencier au premier coup d'oeil un répertoire d'un fichier. Mais si ce n'est pas conventionnel et que les fonctions habituelles attendent des répertoires sans slash final je vais laisser tomber.
Le mieux, ÀMHA, serait d'utiliser directory-file-name à l'insertion :
(defun sk:add-dir-and-subdirs-to-load-path (dir) "Je te laisse ce soin ..."
Ben voyons ;)
;; Pourrait être une commande. Pourquoi pas ? Je te laisse ;; chercher après le code qui va bien ... ;; (interactive "...") (push (directory-file-name dir) load-path) (let ((default-directory dir))
^^^ Ça c'est un truc pour surcharger dans un bloc default-directory avec une valeur locale ? Et ça reprend la valeur d'avant en sortant du let ?
(normal-top-level-add-subdirs-to-load-path)))
(defvar sk:elisp-path (drkm-file:file-in-dir ".elisp/" sk:home-dir) "Je te laisse ce soin ...")
Je vais voir ça après le déjeuner. Merci pour les explications et la solution.
-- Sébastien Kirche
Le 7 Apr 2005, drkm a formulé :
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> writes:
[...]
Ok, je pense avoir compris le problème. D'après la condition du while, la
sémantique de normal-top-level-add-to-load-path semble être d'ajouter la
liste des sous-répertoires du répertoire courant juste après ce répertoire
courant dans le load-path. S'il ne s'y trouve pas, on se retrouve à la fin
du load-path pour l'insertion.
Pour faire la comparaison, elle utilise equal, et le nom du répertoire
courant passé à directory-file-name.
Ok, je comprends mieux.
Le nom inséré ne doit donc pas contenir de slash final.
En fait cela m'importe peu. Le tout est d'être cohérent tout au long du
fichier, et je me suis retrouvé dans un cas bancale.
Quelle convention utilisez-vous pour la désignation d'un répertoire en
général (fichiers de conf ou autres) ? Par exemple pour le home : ~ ou ~/ ?
Je me disais que de voir un slash final permettait de différencier au
premier coup d'oeil un répertoire d'un fichier. Mais si ce n'est pas
conventionnel et que les fonctions habituelles attendent des répertoires
sans slash final je vais laisser tomber.
Le mieux, ÀMHA, serait d'utiliser directory-file-name à l'insertion :
(defun sk:add-dir-and-subdirs-to-load-path (dir)
"Je te laisse ce soin ..."
Ben voyons ;)
;; Pourrait être une commande. Pourquoi pas ? Je te laisse
;; chercher après le code qui va bien ...
;; (interactive "...")
(push (directory-file-name dir) load-path)
(let ((default-directory dir))
^^^
Ça c'est un truc pour surcharger dans un bloc default-directory avec une
valeur locale ? Et ça reprend la valeur d'avant en sortant du let ?
(normal-top-level-add-subdirs-to-load-path)))
(defvar sk:elisp-path (drkm-file:file-in-dir ".elisp/" sk:home-dir)
"Je te laisse ce soin ...")
Ok, je pense avoir compris le problème. D'après la condition du while, la sémantique de normal-top-level-add-to-load-path semble être d'ajouter la liste des sous-répertoires du répertoire courant juste après ce répertoire courant dans le load-path. S'il ne s'y trouve pas, on se retrouve à la fin du load-path pour l'insertion.
Pour faire la comparaison, elle utilise equal, et le nom du répertoire courant passé à directory-file-name.
Ok, je comprends mieux.
Le nom inséré ne doit donc pas contenir de slash final.
En fait cela m'importe peu. Le tout est d'être cohérent tout au long du fichier, et je me suis retrouvé dans un cas bancale.
Quelle convention utilisez-vous pour la désignation d'un répertoire en général (fichiers de conf ou autres) ? Par exemple pour le home : ~ ou ~/ ?
Je me disais que de voir un slash final permettait de différencier au premier coup d'oeil un répertoire d'un fichier. Mais si ce n'est pas conventionnel et que les fonctions habituelles attendent des répertoires sans slash final je vais laisser tomber.
Le mieux, ÀMHA, serait d'utiliser directory-file-name à l'insertion :
(defun sk:add-dir-and-subdirs-to-load-path (dir) "Je te laisse ce soin ..."
Ben voyons ;)
;; Pourrait être une commande. Pourquoi pas ? Je te laisse ;; chercher après le code qui va bien ... ;; (interactive "...") (push (directory-file-name dir) load-path) (let ((default-directory dir))
^^^ Ça c'est un truc pour surcharger dans un bloc default-directory avec une valeur locale ? Et ça reprend la valeur d'avant en sortant du let ?
(normal-top-level-add-subdirs-to-load-path)))
(defvar sk:elisp-path (drkm-file:file-in-dir ".elisp/" sk:home-dir) "Je te laisse ce soin ...")
Je vais voir ça après le déjeuner. Merci pour les explications et la solution.
-- Sébastien Kirche
fgeorges
Sébastien Kirche wrote in message news:...
Le 7 Apr 2005, drkm a formulé :
> Le nom inséré ne doit donc pas contenir de slash final.
En fait cela m'importe peu. Le tout est d'être cohérent tout au long du fichier, et je me suis retrouvé dans un cas bancale.
Dans ce cas precis, je dirais plutot qu'il faut respecter les conventions auxquelles s'attend normal-top-level-add-to-load-path. Le probleme etant qu'elles ne sont pas documentees. Je n'ai rien trouve a ce propos dans (info: (elisp)Library Search), qui ne specifie aucune contrainte sur les elements du load-path.
Encore une fois, je pense qu'il est utile ici de definir exactement ce que l'on souhaite, et ensuite de l'implementer. Personnellement, je n'aime pas trop l'idee d'ajouter en bloc chaque sous-repertoire d'une hierarchie.
Quelle convention utilisez-vous pour la désignation d'un répertoire en général (fichiers de conf ou autres) ? Par exemple pour le home : ~ ou ~/ ?
Je termine mes reperoires d'un slash.
Je me disais que de voir un slash final permettait de différencier au premier coup d'oeil un répertoire d'un fichier. Mais si ce n'est pas conventionnel et que les fonctions habituelles attendent des répertoires sans slash final je vais laisser tomber.
Je ne pense pas que ce soit le cas (au contraire, meme). Tu peux lire a profit (info: (elisp)File Names), en particulier les trois permieres sections.
> (let ((default-directory dir)) ^^^ Ça c'est un truc pour surcharger dans un bloc default-directory avec une valeur locale ? Et ça reprend la valeur d'avant en sortant du let ?
Exactement. LET declare des variables locales. Si une variable existe deja, le binding local cache le binding existant. Dans ce cas, c'est la valeur de default-directory qui est affectee. Et donc le repertoire courant est modifie dans la portee du LET.
PS: Il semblerait que mon serveur de news ne se soit remis que peniblement d'une operation de maintenance, hier. Apparrement, les chirurgiens auraient rencontre des complications. Je garde donc un oeil sur Google Groups, mais je suis trop habitue a l'interface de Gnus. Il est possible que je manque des articles. Et je poste sans accents, mea culpa.
--drkm
Sébastien Kirche wrote in message news:<m21x9mq58z.fsf@seki.fr>...
Le 7 Apr 2005, drkm a formulé :
> Le nom inséré ne doit donc pas contenir de slash final.
En fait cela m'importe peu. Le tout est d'être cohérent tout au long du
fichier, et je me suis retrouvé dans un cas bancale.
Dans ce cas precis, je dirais plutot qu'il faut respecter les
conventions auxquelles s'attend normal-top-level-add-to-load-path. Le
probleme etant qu'elles ne sont pas documentees. Je n'ai rien trouve
a ce propos dans (info: (elisp)Library Search), qui ne specifie aucune
contrainte sur les elements du load-path.
Encore une fois, je pense qu'il est utile ici de definir exactement
ce que l'on souhaite, et ensuite de l'implementer. Personnellement,
je n'aime pas trop l'idee d'ajouter en bloc chaque sous-repertoire
d'une hierarchie.
Quelle convention utilisez-vous pour la désignation d'un répertoire en
général (fichiers de conf ou autres) ? Par exemple pour le home : ~ ou ~/ ?
Je termine mes reperoires d'un slash.
Je me disais que de voir un slash final permettait de différencier au
premier coup d'oeil un répertoire d'un fichier. Mais si ce n'est pas
conventionnel et que les fonctions habituelles attendent des répertoires
sans slash final je vais laisser tomber.
Je ne pense pas que ce soit le cas (au contraire, meme). Tu peux
lire a profit (info: (elisp)File Names), en particulier les trois
permieres sections.
> (let ((default-directory dir))
^^^
Ça c'est un truc pour surcharger dans un bloc default-directory avec une
valeur locale ? Et ça reprend la valeur d'avant en sortant du let ?
Exactement. LET declare des variables locales. Si une variable
existe deja, le binding local cache le binding existant. Dans ce cas,
c'est la valeur de default-directory qui est affectee. Et donc le
repertoire courant est modifie dans la portee du LET.
PS: Il semblerait que mon serveur de news ne se soit remis que
peniblement d'une operation de maintenance, hier. Apparrement, les
chirurgiens auraient rencontre des complications. Je garde donc un
oeil sur Google Groups, mais je suis trop habitue a l'interface de
Gnus. Il est possible que je manque des articles. Et je poste sans
accents, mea culpa.
> Le nom inséré ne doit donc pas contenir de slash final.
En fait cela m'importe peu. Le tout est d'être cohérent tout au long du fichier, et je me suis retrouvé dans un cas bancale.
Dans ce cas precis, je dirais plutot qu'il faut respecter les conventions auxquelles s'attend normal-top-level-add-to-load-path. Le probleme etant qu'elles ne sont pas documentees. Je n'ai rien trouve a ce propos dans (info: (elisp)Library Search), qui ne specifie aucune contrainte sur les elements du load-path.
Encore une fois, je pense qu'il est utile ici de definir exactement ce que l'on souhaite, et ensuite de l'implementer. Personnellement, je n'aime pas trop l'idee d'ajouter en bloc chaque sous-repertoire d'une hierarchie.
Quelle convention utilisez-vous pour la désignation d'un répertoire en général (fichiers de conf ou autres) ? Par exemple pour le home : ~ ou ~/ ?
Je termine mes reperoires d'un slash.
Je me disais que de voir un slash final permettait de différencier au premier coup d'oeil un répertoire d'un fichier. Mais si ce n'est pas conventionnel et que les fonctions habituelles attendent des répertoires sans slash final je vais laisser tomber.
Je ne pense pas que ce soit le cas (au contraire, meme). Tu peux lire a profit (info: (elisp)File Names), en particulier les trois permieres sections.
> (let ((default-directory dir)) ^^^ Ça c'est un truc pour surcharger dans un bloc default-directory avec une valeur locale ? Et ça reprend la valeur d'avant en sortant du let ?
Exactement. LET declare des variables locales. Si une variable existe deja, le binding local cache le binding existant. Dans ce cas, c'est la valeur de default-directory qui est affectee. Et donc le repertoire courant est modifie dans la portee du LET.
PS: Il semblerait que mon serveur de news ne se soit remis que peniblement d'une operation de maintenance, hier. Apparrement, les chirurgiens auraient rencontre des complications. Je garde donc un oeil sur Google Groups, mais je suis trop habitue a l'interface de Gnus. Il est possible que je manque des articles. Et je poste sans accents, mea culpa.
--drkm
Sébastien Kirche
Le 8 Apr 2005, drkm a formulé :
PS: Il semblerait que mon serveur de news ne se soit remis que peniblement d'une operation de maintenance, hier. Apparrement, les chirurgiens auraient rencontre des complications.
Ah oui, tiens. T'es au Cern ?
-- Sébastien Kirche
Le 8 Apr 2005, drkm a formulé :
PS: Il semblerait que mon serveur de news ne se soit remis que
peniblement d'une operation de maintenance, hier. Apparrement, les
chirurgiens auraient rencontre des complications.
PS: Il semblerait que mon serveur de news ne se soit remis que peniblement d'une operation de maintenance, hier. Apparrement, les chirurgiens auraient rencontre des complications.
Ah oui, tiens. T'es au Cern ?
-- Sébastien Kirche
Sébastien Kirche
Le 8 Apr 2005, drkm a formulé :
Encore une fois, je pense qu'il est utile ici de definir exactement ce que l'on souhaite, et ensuite de l'implementer. Personnellement, je n'aime pas trop l'idee d'ajouter en bloc chaque sous-repertoire d'une hierarchie.
Simple : bien que tout seul sur mes systèmes, je n'installe pas toujours (chez moi) et jamais (au boulot) que paquetage pour Emacs au niveau système.
Et je n'installe jamais des tar.gz avec un «make install» par défaut. Je préfère les dé-tarrer dans mon répartoire lisp perso. Ou si le makefile le permet je configure préalablement le répertoire préfixe ou ce genre de réglage pour que ça aille chez moi.
(Exception : Emacs lui même qui est installé proprement pour tout le monde.)
Et je récupère aussi de temps à autres des scripts sur le ouaibe (j'en écris même ;) que je place aussi dans mon répertoire.
J'ai donc besoin d'un moyen de rendre accessible ces modules - si le répertoire existe - et que ce soient ceux-là qui soient pris en compte et pas ceux de la release dans le cas de versions que je vais chercher dans le cvs pour être à jour (ex: bbdb, gnus)
Accessoirement j'ai aussi besoin de d'ajouter les documentations de ces modules (quand ils en proposent, je m'arrange pour qu'elles s'installent dans ~/.elisp/info et ~/.elisp/man) aux docs systèmes.
Hier sur Linux j'ai pu confirmer un comportement bizarre en ce qui concerne load-path en fonction du slash final et _aussi_ de la présence de ~. Pas très cohérent tout ça.
Et j'ai eu aussi un problème avec un code que tu avait proposé pour l'INFOPATH qui m'a amené à écrire ce truc moche :
parce que sur OSX ici j'ai besoin de la valeur de Info-default-directory-list plus que de celle d'INFOPATH qui est paramétré spécialement pour les applis graphiques.
Je viens tout juste de découvrir une bidouille dans la doc d'Info-directory-list pour faire ce que je veux : en terminant INFOPATH avec un ":" il concatène Info-default-directory-list.
Quand à ton code d'hier sk:add-dir-and-subdirs-to-load-path j'ai déjà un peu regardé mais il y a des dépendances sur des fonctions de ton cvs, et je n'ai pas fini de regarder.
-- Sébastien Kirche
Le 8 Apr 2005, drkm a formulé :
Encore une fois, je pense qu'il est utile ici de definir exactement
ce que l'on souhaite, et ensuite de l'implementer. Personnellement,
je n'aime pas trop l'idee d'ajouter en bloc chaque sous-repertoire
d'une hierarchie.
Simple : bien que tout seul sur mes systèmes, je n'installe pas toujours
(chez moi) et jamais (au boulot) que paquetage pour Emacs au niveau système.
Et je n'installe jamais des tar.gz avec un «make install» par défaut. Je
préfère les dé-tarrer dans mon répartoire lisp perso. Ou si le makefile le
permet je configure préalablement le répertoire préfixe ou ce genre de
réglage pour que ça aille chez moi.
(Exception : Emacs lui même qui est installé proprement pour tout le monde.)
Et je récupère aussi de temps à autres des scripts sur le ouaibe (j'en écris
même ;) que je place aussi dans mon répertoire.
J'ai donc besoin d'un moyen de rendre accessible ces modules
- si le répertoire existe
- et que ce soient ceux-là qui soient pris en compte et pas ceux de la
release dans le cas de versions que je vais chercher dans le cvs pour être
à jour (ex: bbdb, gnus)
Accessoirement j'ai aussi besoin de d'ajouter les documentations de ces
modules (quand ils en proposent, je m'arrange pour qu'elles s'installent
dans ~/.elisp/info et ~/.elisp/man) aux docs systèmes.
Hier sur Linux j'ai pu confirmer un comportement bizarre en ce qui concerne
load-path en fonction du slash final et _aussi_ de la présence de ~.
Pas très cohérent tout ça.
Et j'ai eu aussi un problème avec un code que tu avait proposé pour
l'INFOPATH qui m'a amené à écrire ce truc moche :
parce que sur OSX ici j'ai besoin de la valeur de
Info-default-directory-list plus que de celle d'INFOPATH qui est paramétré
spécialement pour les applis graphiques.
Je viens tout juste de découvrir une bidouille dans la doc
d'Info-directory-list pour faire ce que je veux : en terminant INFOPATH avec
un ":" il concatène Info-default-directory-list.
Quand à ton code d'hier sk:add-dir-and-subdirs-to-load-path j'ai déjà un peu
regardé mais il y a des dépendances sur des fonctions de ton cvs, et je n'ai
pas fini de regarder.
Encore une fois, je pense qu'il est utile ici de definir exactement ce que l'on souhaite, et ensuite de l'implementer. Personnellement, je n'aime pas trop l'idee d'ajouter en bloc chaque sous-repertoire d'une hierarchie.
Simple : bien que tout seul sur mes systèmes, je n'installe pas toujours (chez moi) et jamais (au boulot) que paquetage pour Emacs au niveau système.
Et je n'installe jamais des tar.gz avec un «make install» par défaut. Je préfère les dé-tarrer dans mon répartoire lisp perso. Ou si le makefile le permet je configure préalablement le répertoire préfixe ou ce genre de réglage pour que ça aille chez moi.
(Exception : Emacs lui même qui est installé proprement pour tout le monde.)
Et je récupère aussi de temps à autres des scripts sur le ouaibe (j'en écris même ;) que je place aussi dans mon répertoire.
J'ai donc besoin d'un moyen de rendre accessible ces modules - si le répertoire existe - et que ce soient ceux-là qui soient pris en compte et pas ceux de la release dans le cas de versions que je vais chercher dans le cvs pour être à jour (ex: bbdb, gnus)
Accessoirement j'ai aussi besoin de d'ajouter les documentations de ces modules (quand ils en proposent, je m'arrange pour qu'elles s'installent dans ~/.elisp/info et ~/.elisp/man) aux docs systèmes.
Hier sur Linux j'ai pu confirmer un comportement bizarre en ce qui concerne load-path en fonction du slash final et _aussi_ de la présence de ~. Pas très cohérent tout ça.
Et j'ai eu aussi un problème avec un code que tu avait proposé pour l'INFOPATH qui m'a amené à écrire ce truc moche :
parce que sur OSX ici j'ai besoin de la valeur de Info-default-directory-list plus que de celle d'INFOPATH qui est paramétré spécialement pour les applis graphiques.
Je viens tout juste de découvrir une bidouille dans la doc d'Info-directory-list pour faire ce que je veux : en terminant INFOPATH avec un ":" il concatène Info-default-directory-list.
Quand à ton code d'hier sk:add-dir-and-subdirs-to-load-path j'ai déjà un peu regardé mais il y a des dépendances sur des fonctions de ton cvs, et je n'ai pas fini de regarder.
-- Sébastien Kirche
Sébastien Kirche
Le 8 avr 2005, drkm a dit :
> Ah oui, tiens. T'es au Cern ?
En effet (toi aussi ?).
Pas du tout. Ça m'aurait sans doute plu, mais on n'y rentre pas comme ça. J'ai un copain qui postulait chaque année il y a un moment. Mais il a dû jeter l'éponge.
Moi je suis simple développeur chez un éditeur de logiciels de gestion.
-- Sébastien Kirche
Le 8 avr 2005, drkm a dit :
> Ah oui, tiens. T'es au Cern ?
En effet (toi aussi ?).
Pas du tout. Ça m'aurait sans doute plu, mais on n'y rentre pas comme ça.
J'ai un copain qui postulait chaque année il y a un moment. Mais il a dû
jeter l'éponge.
Moi je suis simple développeur chez un éditeur de logiciels de gestion.
Pas du tout. Ça m'aurait sans doute plu, mais on n'y rentre pas comme ça. J'ai un copain qui postulait chaque année il y a un moment. Mais il a dû jeter l'éponge.
Moi je suis simple développeur chez un éditeur de logiciels de gestion.
