bizarrerie de path
Le
Sébastien Kirche
Bonjour,
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)))
(add-to-list 'load-path sk:elisp-path)
(progn (cd sk:elisp-path)
(normal-top-level-add-subdirs-to-load-path)
(cd sk:home))
8<8<8<8<8<8<8<8<8<
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é.
--
Sébastien Kirche
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)))
(add-to-list 'load-path sk:elisp-path)
(progn (cd sk:elisp-path)
(normal-top-level-add-subdirs-to-load-path)
(cd sk:home))
8<8<8<8<8<8<8<8<8<
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é.
--
Sébastien Kirche
Poser une question
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
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
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).
Moi je sais :-).
--drkm
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.
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.
Ah ptêt bien :)
8<------8<------8<------8<------8<------8<------8<------8<------8<------
sk:home = /home/seki/
sk:elisp-path = ~/.elisp
avant appel à
(add-to-list 'load-path sk:elisp-path)
(progn (cd sk:elisp-path)
(normal-top-level-add-subdirs-to-load-path)
(cd sk:home))
(/usr/share/emacs/site-lisp/speedbar/ [...] /usr/share/emacs/22.0.50/lisp/calc)
après appel :
(~/.elisp /home/seki/.elisp/bbdb-2.35 /home/seki/.elisp/cedet [...]
/home/seki/.elisp/cedet/speedbar [...] /usr/share/emacs/site-lisp/speedbar/
[...] /usr/share/emacs/22.0.50/lisp/calc)
8<------8<------8<------8<------8<------8<------8<------8<------8<------
sk:home = /home/seki/
sk:elisp-path = ~/.elisp/
avant appel
(/usr/share/emacs/site-lisp/speedbar/ [...] /usr/share/emacs/22.0.50/lisp/calc)
après appel
(~/.elisp/ /usr/share/emacs/site-lisp/speedbar/ [...]
/usr/share/emacs/22.0.50/lisp/calc /home/seki/.elisp/bbdb-2.35
/home/seki/.elisp/cedet [...] /home/seki/.elisp/cedet/speedbar [...] )
--
Sébastien Kirche
[...]
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