J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de problème
de librairies à mette à jour. Avant de patauger d'avantage, je voudrais
m'assurer qu'il n'y a pas de versions qui ne coexistent pas.
J'ai installé le dernier CEDET : cedet-1.0beta2b, dont la version de
semantic est "2.0beta2". ECB (le dernier : ecb-2.31) se plaint à
l'activation et me réclame des versions apparemment beaucoup plus
anciennes : "ECB requires semantic [1.4, 1.4.9] and eieio [0.17, 0.17.9].
Download now? ". Enfin j'ai aussi des problèmes, quand ecb est lancé, avec
JDE (2.2.8, une version peut être ancienne pour le coup).
Les dernières versions de CEDET et ECB sont elles bien compatibles entre
elles ?
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
Sébastien Kirche
Le 13 June 2005 à 22:06, SL s'est exprimé ainsi :
Bonjour,
Bonjour,
J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de problème de librairies à mette à jour. Avant de patauger d'avantage, je voudrais m'assurer qu'il n'y a pas de versions qui ne coexistent pas.
Comment et où ECB a-t-il été installé ?
J'ai installé le dernier CEDET : cedet-1.0beta2b, dont la version de semantic est "2.0beta2". ECB (le dernier : ecb-2.31) se plaint à l'activation et me réclame des versions apparemment beaucoup plus anciennes : "ECB requires semantic [1.4, 1.4.9] and eieio [0.17, 0.17.9]. Download now? ". Enfin j'ai aussi des problèmes, quand ecb est lancé, avec JDE (2.2.8, une version peut être ancienne pour le coup).
Les dernières versions de CEDET et ECB sont elles bien compatibles entre elles ?
Moi je penche plus pour un problème de bibliothèque en double dont l'ancienne version masque la nouvelle.
Est-ce que M-x locate-library sur cedet et les différents sous modules correspond bien avec l'emplacement de l'installation ?
Pour installer un package custom, il vaut mieux toujours s'arranger pour ajouter son emplacement au début du load-path.
Un truc que j'ai appris dernièrement peut permettre d'aider : M-x list-load-path-shadows Ça indique les modules accessibles par le load-path qui sont masqués par d'autres.
HTH. -- Sébastien Kirche
Le 13 June 2005 à 22:06, SL s'est exprimé ainsi :
Bonjour,
Bonjour,
J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de
problème de librairies à mette à jour. Avant de patauger d'avantage,
je voudrais m'assurer qu'il n'y a pas de versions qui ne coexistent
pas.
Comment et où ECB a-t-il été installé ?
J'ai installé le dernier CEDET : cedet-1.0beta2b, dont la version de
semantic est "2.0beta2". ECB (le dernier : ecb-2.31) se plaint à
l'activation et me réclame des versions apparemment beaucoup plus
anciennes : "ECB requires semantic [1.4, 1.4.9] and eieio [0.17,
0.17.9]. Download now? ". Enfin j'ai aussi des problèmes, quand ecb
est lancé, avec JDE (2.2.8, une version peut être ancienne pour le
coup).
Les dernières versions de CEDET et ECB sont elles bien compatibles
entre elles ?
Moi je penche plus pour un problème de bibliothèque en double dont
l'ancienne version masque la nouvelle.
Est-ce que M-x locate-library sur cedet et les différents sous modules
correspond bien avec l'emplacement de l'installation ?
Pour installer un package custom, il vaut mieux toujours s'arranger pour
ajouter son emplacement au début du load-path.
Un truc que j'ai appris dernièrement peut permettre d'aider :
M-x list-load-path-shadows
Ça indique les modules accessibles par le load-path qui sont masqués par
d'autres.
J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de problème de librairies à mette à jour. Avant de patauger d'avantage, je voudrais m'assurer qu'il n'y a pas de versions qui ne coexistent pas.
Comment et où ECB a-t-il été installé ?
J'ai installé le dernier CEDET : cedet-1.0beta2b, dont la version de semantic est "2.0beta2". ECB (le dernier : ecb-2.31) se plaint à l'activation et me réclame des versions apparemment beaucoup plus anciennes : "ECB requires semantic [1.4, 1.4.9] and eieio [0.17, 0.17.9]. Download now? ". Enfin j'ai aussi des problèmes, quand ecb est lancé, avec JDE (2.2.8, une version peut être ancienne pour le coup).
Les dernières versions de CEDET et ECB sont elles bien compatibles entre elles ?
Moi je penche plus pour un problème de bibliothèque en double dont l'ancienne version masque la nouvelle.
Est-ce que M-x locate-library sur cedet et les différents sous modules correspond bien avec l'emplacement de l'installation ?
Pour installer un package custom, il vaut mieux toujours s'arranger pour ajouter son emplacement au début du load-path.
Un truc que j'ai appris dernièrement peut permettre d'aider : M-x list-load-path-shadows Ça indique les modules accessibles par le load-path qui sont masqués par d'autres.
HTH. -- Sébastien Kirche
SL
J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de problème de librairies à mette à jour. Avant de patauger d'avantage, je voudrais m'assurer qu'il n'y a pas de versions qui ne coexistent pas.
Comment et où ECB a-t-il été installé ?
En décompressant l'archive et copiant son contenu dans un répertoire de packages elisp. Il n'y avait pas d'anciennes version d'ECB présente. C'est la distribution d'emacs faite pas la TEI, pour Windows.
Dans le cas de CEDET je n'ai pas fait la byte-compilation décrite dans le fichier install, n'ayant pas de make ; mises à part les performances, ça n'a pas d'incidence ?
Les dernières versions de CEDET et ECB sont elles bien compatibles entre elles ?
Moi je penche plus pour un problème de bibliothèque en double dont l'ancienne version masque la nouvelle.
En effet, il y a une version antérieure de cedet.
Est-ce que M-x locate-library sur cedet et les différents sous modules correspond bien avec l'emplacement de l'installation ?
oui
Pour installer un package custom, il vaut mieux toujours s'arranger pour ajouter son emplacement au début du load-path.
Un truc que j'ai appris dernièrement peut permettre d'aider : M-x list-load-path-shadows
Effectivement : tous les nouveaux packages cachent les anciens.
mais dans ce cas ce sont les packages ajouté dans load-path en dernier qui priment sur les autres ? Que vouliez vous dire avec "ajouter son emplacement au début du load-path" ?
slv
J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de
problème de librairies à mette à jour. Avant de patauger d'avantage,
je voudrais m'assurer qu'il n'y a pas de versions qui ne coexistent
pas.
Comment et où ECB a-t-il été installé ?
En décompressant l'archive et copiant son contenu dans un répertoire de
packages elisp. Il n'y avait pas d'anciennes version d'ECB présente. C'est
la distribution d'emacs faite pas la TEI, pour Windows.
Dans le cas de CEDET je n'ai pas fait la byte-compilation décrite dans le
fichier install, n'ayant pas de make ; mises à part les performances, ça
n'a pas d'incidence ?
Les dernières versions de CEDET et ECB sont elles bien compatibles
entre elles ?
Moi je penche plus pour un problème de bibliothèque en double dont
l'ancienne version masque la nouvelle.
En effet, il y a une version antérieure de cedet.
Est-ce que M-x locate-library sur cedet et les différents sous modules
correspond bien avec l'emplacement de l'installation ?
oui
Pour installer un package custom, il vaut mieux toujours s'arranger pour
ajouter son emplacement au début du load-path.
Un truc que j'ai appris dernièrement peut permettre d'aider :
M-x list-load-path-shadows
Effectivement : tous les nouveaux packages cachent les anciens.
mais dans ce cas ce sont les packages ajouté dans load-path en dernier qui
priment sur les autres ? Que vouliez vous dire avec "ajouter son
emplacement au début du load-path" ?
J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de problème de librairies à mette à jour. Avant de patauger d'avantage, je voudrais m'assurer qu'il n'y a pas de versions qui ne coexistent pas.
Comment et où ECB a-t-il été installé ?
En décompressant l'archive et copiant son contenu dans un répertoire de packages elisp. Il n'y avait pas d'anciennes version d'ECB présente. C'est la distribution d'emacs faite pas la TEI, pour Windows.
Dans le cas de CEDET je n'ai pas fait la byte-compilation décrite dans le fichier install, n'ayant pas de make ; mises à part les performances, ça n'a pas d'incidence ?
Les dernières versions de CEDET et ECB sont elles bien compatibles entre elles ?
Moi je penche plus pour un problème de bibliothèque en double dont l'ancienne version masque la nouvelle.
En effet, il y a une version antérieure de cedet.
Est-ce que M-x locate-library sur cedet et les différents sous modules correspond bien avec l'emplacement de l'installation ?
oui
Pour installer un package custom, il vaut mieux toujours s'arranger pour ajouter son emplacement au début du load-path.
Un truc que j'ai appris dernièrement peut permettre d'aider : M-x list-load-path-shadows
Effectivement : tous les nouveaux packages cachent les anciens.
mais dans ce cas ce sont les packages ajouté dans load-path en dernier qui priment sur les autres ? Que vouliez vous dire avec "ajouter son emplacement au début du load-path" ?
slv
SL
Problème résolu, c'était bien un problème de de librairy ancienne trainant toujours dans load-paht (senator).
Merci, Sylvain
Problème résolu, c'était bien un problème de de librairy ancienne trainant
toujours dans load-paht (senator).
Problème résolu, c'était bien un problème de de librairy ancienne trainant toujours dans load-paht (senator).
Merci, Sylvain
Sébastien Kirche
Le 14 June 2005 à 13:06, SL s'est exprimé ainsi :
> > J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de > > problème de librairies à mette à jour. Avant de patauger > > d'avantage, je voudrais m'assurer qu'il n'y a pas de versions qui > > ne coexistent pas. > > Comment et où ECB a-t-il été installé ?
En décompressant l'archive et copiant son contenu dans un répertoire de packages elisp. Il n'y avait pas d'anciennes version d'ECB présente. C'est la distribution d'emacs faite pas la TEI, pour Windows.
Dans le cas de CEDET je n'ai pas fait la byte-compilation décrite dans le fichier install, n'ayant pas de make ; mises à part les performances, ça n'a pas d'incidence ?
D'après le contenu du fichier INSTALL make n'est pas obligatoire.
Elle permet d'automatiser la byte-compilation des modules elisp souhaitable pour les performances et la compilation des fichiers info.
Par contre l'installation «à la main» reste possible. Il faut alors se référer aux différents INSTALL des modules de cedet (speedbar, eieio, ...)
> > Les dernières versions de CEDET et ECB sont elles bien compatibles > > entre elles ? > > Moi je penche plus pour un problème de bibliothèque en double dont > l'ancienne version masque la nouvelle.
En effet, il y a une version antérieure de cedet.
> Est-ce que M-x locate-library sur cedet et les différents sous > modules correspond bien avec l'emplacement de l'installation ?
oui
> Pour installer un package custom, il vaut mieux toujours s'arranger > pour ajouter son emplacement au début du load-path. > > Un truc que j'ai appris dernièrement peut permettre d'aider : > M-x list-load-path-shadows
Effectivement : tous les nouveaux packages cachent les anciens.
Il semble donc qu'il n'y ai pas de problème de chemin.
Comment cedet est-il appelé ?
Chez moi j'ai ajouté ceci à .emacs (mais j'ai installé par make en spécifiant des répertoire différents de ceux par défaut) : ;; Load CEDET ;;(setq semantic-load-turn-useful-things-on t) (setq semantic-load-turn-everything-on t) (let ((cedet-f (concat sk:elisp-path "/cedet/common/cedet.el"))) (when (file-exists-p cedet-f) (load-library cedet-f) ;; Enabling SEMANTIC minor modes. See semantic/INSTALL for more ideas. ;;(semantic-load-enable-excessive-code-helpers) ))
Chez moi sk:elisp-path vaut ~/.elisp/ et cedet est installé dans ~/.elisp/cedet.
Je fais le test avant de charger cedet ça je partage le .emacs entre plusieurs machines et cedet n'est pas partout.
mais dans ce cas ce sont les packages ajouté dans load-path en dernier qui priment sur les autres ? Que vouliez vous dire avec "ajouter son emplacement au début du load-path" ?
Simplement que pour un load-library ou un require emacs cherche dans l'ordre du load-path.
Aussi il faut faire attention quand on installe par exemple une version beta d'un module qui est également fourni par emacs dans son arborescence lisp et site-lisp à ajouter l'emplacement de la nouvelle version (i.e. son répertoire) dans le load-path avant les répertoires standards.
Sinon on se retrouve parfois à chercher pourquoi la nouvelle version n'est pas prise en compte.
-- Sébastien Kirche
Le 14 June 2005 à 13:06, SL s'est exprimé ainsi :
> > J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de
> > problème de librairies à mette à jour. Avant de patauger
> > d'avantage, je voudrais m'assurer qu'il n'y a pas de versions qui
> > ne coexistent pas.
>
> Comment et où ECB a-t-il été installé ?
En décompressant l'archive et copiant son contenu dans un répertoire
de packages elisp. Il n'y avait pas d'anciennes version d'ECB
présente. C'est la distribution d'emacs faite pas la TEI, pour
Windows.
Dans le cas de CEDET je n'ai pas fait la byte-compilation décrite dans
le fichier install, n'ayant pas de make ; mises à part les
performances, ça n'a pas d'incidence ?
D'après le contenu du fichier INSTALL make n'est pas obligatoire.
Elle permet d'automatiser la byte-compilation des modules elisp
souhaitable pour les performances et la compilation des fichiers info.
Par contre l'installation «à la main» reste possible. Il faut alors se
référer aux différents INSTALL des modules de cedet (speedbar, eieio,
...)
> > Les dernières versions de CEDET et ECB sont elles bien compatibles
> > entre elles ?
>
> Moi je penche plus pour un problème de bibliothèque en double dont
> l'ancienne version masque la nouvelle.
En effet, il y a une version antérieure de cedet.
> Est-ce que M-x locate-library sur cedet et les différents sous
> modules correspond bien avec l'emplacement de l'installation ?
oui
> Pour installer un package custom, il vaut mieux toujours s'arranger
> pour ajouter son emplacement au début du load-path.
>
> Un truc que j'ai appris dernièrement peut permettre d'aider :
> M-x list-load-path-shadows
Effectivement : tous les nouveaux packages cachent les anciens.
Il semble donc qu'il n'y ai pas de problème de chemin.
Comment cedet est-il appelé ?
Chez moi j'ai ajouté ceci à .emacs (mais j'ai installé par make en
spécifiant des répertoire différents de ceux par défaut) :
;; Load CEDET
;;(setq semantic-load-turn-useful-things-on t)
(setq semantic-load-turn-everything-on t)
(let ((cedet-f (concat sk:elisp-path "/cedet/common/cedet.el")))
(when (file-exists-p cedet-f)
(load-library cedet-f)
;; Enabling SEMANTIC minor modes. See semantic/INSTALL for more ideas.
;;(semantic-load-enable-excessive-code-helpers)
))
Chez moi sk:elisp-path vaut ~/.elisp/ et cedet est installé dans
~/.elisp/cedet.
Je fais le test avant de charger cedet ça je partage le .emacs entre
plusieurs machines et cedet n'est pas partout.
mais dans ce cas ce sont les packages ajouté dans load-path en dernier
qui priment sur les autres ? Que vouliez vous dire avec "ajouter son
emplacement au début du load-path" ?
Simplement que pour un load-library ou un require emacs cherche dans
l'ordre du load-path.
Aussi il faut faire attention quand on installe par exemple une version
beta d'un module qui est également fourni par emacs dans son
arborescence lisp et site-lisp à ajouter l'emplacement de la nouvelle
version (i.e. son répertoire) dans le load-path avant les répertoires
standards.
Sinon on se retrouve parfois à chercher pourquoi la nouvelle version
n'est pas prise en compte.
> > J'ai essayé d'installer ECB, mais manifestement j'ai beaucoup de > > problème de librairies à mette à jour. Avant de patauger > > d'avantage, je voudrais m'assurer qu'il n'y a pas de versions qui > > ne coexistent pas. > > Comment et où ECB a-t-il été installé ?
En décompressant l'archive et copiant son contenu dans un répertoire de packages elisp. Il n'y avait pas d'anciennes version d'ECB présente. C'est la distribution d'emacs faite pas la TEI, pour Windows.
Dans le cas de CEDET je n'ai pas fait la byte-compilation décrite dans le fichier install, n'ayant pas de make ; mises à part les performances, ça n'a pas d'incidence ?
D'après le contenu du fichier INSTALL make n'est pas obligatoire.
Elle permet d'automatiser la byte-compilation des modules elisp souhaitable pour les performances et la compilation des fichiers info.
Par contre l'installation «à la main» reste possible. Il faut alors se référer aux différents INSTALL des modules de cedet (speedbar, eieio, ...)
> > Les dernières versions de CEDET et ECB sont elles bien compatibles > > entre elles ? > > Moi je penche plus pour un problème de bibliothèque en double dont > l'ancienne version masque la nouvelle.
En effet, il y a une version antérieure de cedet.
> Est-ce que M-x locate-library sur cedet et les différents sous > modules correspond bien avec l'emplacement de l'installation ?
oui
> Pour installer un package custom, il vaut mieux toujours s'arranger > pour ajouter son emplacement au début du load-path. > > Un truc que j'ai appris dernièrement peut permettre d'aider : > M-x list-load-path-shadows
Effectivement : tous les nouveaux packages cachent les anciens.
Il semble donc qu'il n'y ai pas de problème de chemin.
Comment cedet est-il appelé ?
Chez moi j'ai ajouté ceci à .emacs (mais j'ai installé par make en spécifiant des répertoire différents de ceux par défaut) : ;; Load CEDET ;;(setq semantic-load-turn-useful-things-on t) (setq semantic-load-turn-everything-on t) (let ((cedet-f (concat sk:elisp-path "/cedet/common/cedet.el"))) (when (file-exists-p cedet-f) (load-library cedet-f) ;; Enabling SEMANTIC minor modes. See semantic/INSTALL for more ideas. ;;(semantic-load-enable-excessive-code-helpers) ))
Chez moi sk:elisp-path vaut ~/.elisp/ et cedet est installé dans ~/.elisp/cedet.
Je fais le test avant de charger cedet ça je partage le .emacs entre plusieurs machines et cedet n'est pas partout.
mais dans ce cas ce sont les packages ajouté dans load-path en dernier qui priment sur les autres ? Que vouliez vous dire avec "ajouter son emplacement au début du load-path" ?
Simplement que pour un load-library ou un require emacs cherche dans l'ordre du load-path.
Aussi il faut faire attention quand on installe par exemple une version beta d'un module qui est également fourni par emacs dans son arborescence lisp et site-lisp à ajouter l'emplacement de la nouvelle version (i.e. son répertoire) dans le load-path avant les répertoires standards.
Sinon on se retrouve parfois à chercher pourquoi la nouvelle version n'est pas prise en compte.
-- Sébastien Kirche
SL
Simplement que pour un load-library ou un require emacs cherche dans l'ordre du load-path.
Cet ordre, c'est l'ordre dans lequel les éléments sont entrés dans load-path, ou c'est l'ordre inverse ? La sortie de list-load-path-shadows me donnait l'impression que c'était l'ordre inverse : la version récente de cedet, ajoutée à la fin de .emacs et après le site-start, cachait une version ajoutée dans le site-start.
Si c'est l'ordre dans lequel les éléments sont entrés, quelle est la bonne politique pour se mettre au début du load-path sans toucher au fichier site-start ?
Simplement que pour un load-library ou un require emacs cherche dans
l'ordre du load-path.
Cet ordre, c'est l'ordre dans lequel les éléments sont entrés dans
load-path, ou c'est l'ordre inverse ? La sortie de list-load-path-shadows
me donnait l'impression que c'était l'ordre inverse : la version récente
de cedet, ajoutée à la fin de .emacs et après le site-start, cachait une
version ajoutée dans le site-start.
Si c'est l'ordre dans lequel les éléments sont entrés, quelle est la bonne
politique pour se mettre au début du load-path sans toucher au fichier
site-start ?
Simplement que pour un load-library ou un require emacs cherche dans l'ordre du load-path.
Cet ordre, c'est l'ordre dans lequel les éléments sont entrés dans load-path, ou c'est l'ordre inverse ? La sortie de list-load-path-shadows me donnait l'impression que c'était l'ordre inverse : la version récente de cedet, ajoutée à la fin de .emacs et après le site-start, cachait une version ajoutée dans le site-start.
Si c'est l'ordre dans lequel les éléments sont entrés, quelle est la bonne politique pour se mettre au début du load-path sans toucher au fichier site-start ?
Sébastien Kirche
Le 14 June 2005 à 15:06, SL vraute :
> Simplement que pour un load-library ou un require emacs cherche dans > l'ordre du load-path.
Cet ordre, c'est l'ordre dans lequel les éléments sont entrés dans load-path, ou c'est l'ordre inverse ?
Je dirais que c'est l'ordre dans la variable load-path, visible par un C-h v load-path RET
La sortie de list-load-path-shadows me donnait l'impression que c'était l'ordre inverse : la version récente de cedet, ajoutée à la fin de .emacs et après le site-start, cachait une version ajoutée dans le site-start.
Ah je vois la question : ça peut être ajouté en fin du .emacs, si ça se retrouve au début de la variable load-path, ça sera considéré avant les paquetages standard lors d'un (require) ou d'un M-x load-library.
Pour être clair sur le cas de require : sauf si require est situé avant la modification du load-path dans le .emacs, auquel cas la recherche se fera avec l'ancienne valeur.
Tout dépend de comment load-path est modifié. Avec un (push "chemin/ajouté" load-path) ou un (setq load-path (cons "chemin/ajouté" load-path)) on ajoute explicitement au début du load-path.
Avec un (add-to-list load-path "path") également, mais il me semble que drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Si c'est l'ordre dans lequel les éléments sont entrés, quelle est la bonne politique pour se mettre au début du load-path sans toucher au fichier site-start ?
En plaçant la modif dans le .emacs comme je l'ai indiqué ci-dessus.
-- Sébastien Kirche
Le 14 June 2005 à 15:06, SL vraute :
> Simplement que pour un load-library ou un require emacs cherche dans
> l'ordre du load-path.
Cet ordre, c'est l'ordre dans lequel les éléments sont entrés dans
load-path, ou c'est l'ordre inverse ?
Je dirais que c'est l'ordre dans la variable load-path, visible par un
C-h v load-path RET
La sortie de
list-load-path-shadows me donnait l'impression que c'était l'ordre
inverse : la version récente de cedet, ajoutée à la fin de .emacs et
après le site-start, cachait une version ajoutée dans le site-start.
Ah je vois la question : ça peut être ajouté en fin du .emacs, si ça se
retrouve au début de la variable load-path, ça sera considéré avant les
paquetages standard lors d'un (require) ou d'un M-x load-library.
Pour être clair sur le cas de require : sauf si require est situé avant
la modification du load-path dans le .emacs, auquel cas la recherche se
fera avec l'ancienne valeur.
Tout dépend de comment load-path est modifié. Avec un
(push "chemin/ajouté" load-path) ou un
(setq load-path (cons "chemin/ajouté" load-path))
on ajoute explicitement au début du load-path.
Avec un (add-to-list load-path "path") également, mais il me semble que
drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Si c'est l'ordre dans lequel les éléments sont entrés, quelle est la
bonne politique pour se mettre au début du load-path sans toucher au
fichier site-start ?
En plaçant la modif dans le .emacs comme je l'ai indiqué ci-dessus.
> Simplement que pour un load-library ou un require emacs cherche dans > l'ordre du load-path.
Cet ordre, c'est l'ordre dans lequel les éléments sont entrés dans load-path, ou c'est l'ordre inverse ?
Je dirais que c'est l'ordre dans la variable load-path, visible par un C-h v load-path RET
La sortie de list-load-path-shadows me donnait l'impression que c'était l'ordre inverse : la version récente de cedet, ajoutée à la fin de .emacs et après le site-start, cachait une version ajoutée dans le site-start.
Ah je vois la question : ça peut être ajouté en fin du .emacs, si ça se retrouve au début de la variable load-path, ça sera considéré avant les paquetages standard lors d'un (require) ou d'un M-x load-library.
Pour être clair sur le cas de require : sauf si require est situé avant la modification du load-path dans le .emacs, auquel cas la recherche se fera avec l'ancienne valeur.
Tout dépend de comment load-path est modifié. Avec un (push "chemin/ajouté" load-path) ou un (setq load-path (cons "chemin/ajouté" load-path)) on ajoute explicitement au début du load-path.
Avec un (add-to-list load-path "path") également, mais il me semble que drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Si c'est l'ordre dans lequel les éléments sont entrés, quelle est la bonne politique pour se mettre au début du load-path sans toucher au fichier site-start ?
En plaçant la modif dans le .emacs comme je l'ai indiqué ci-dessus.
-- Sébastien Kirche
SL
Je dirais que c'est l'ordre dans la variable load-path, visible par un C-h v load-path RET
ok (les valeurs "cachantes" sont bien au début chez moi).
Tout dépend de comment load-path est modifié. Avec un (push "chemin/ajouté" load-path) ou un (setq load-path (cons "chemin/ajouté" load-path)) on ajoute explicitement au début du load-path.
ok.
Avec un (add-to-list load-path "path") également, mais il me semble que drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Ah ? C'est ce que j'utilise.
Je dirais que c'est l'ordre dans la variable load-path, visible par un
C-h v load-path RET
ok (les valeurs "cachantes" sont bien au début chez moi).
Tout dépend de comment load-path est modifié. Avec un
(push "chemin/ajouté" load-path) ou un
(setq load-path (cons "chemin/ajouté" load-path))
on ajoute explicitement au début du load-path.
ok.
Avec un (add-to-list load-path "path") également, mais il me semble que
drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Je dirais que c'est l'ordre dans la variable load-path, visible par un C-h v load-path RET
ok (les valeurs "cachantes" sont bien au début chez moi).
Tout dépend de comment load-path est modifié. Avec un (push "chemin/ajouté" load-path) ou un (setq load-path (cons "chemin/ajouté" load-path)) on ajoute explicitement au début du load-path.
ok.
Avec un (add-to-list load-path "path") également, mais il me semble que drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Ah ? C'est ce que j'utilise.
drkm
SL writes:
Avec un (add-to-list load-path "path") également, mais il me semble que drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Ah ? C'est ce que j'utilise.
'add-to-list' fait la même chose que 'push', mais va d'abord parcourir la liste pour voir si l'élément ne s'y trouve pas déjà. Comme l'ordre dans le 'load-path' est important, ça peut mener à des bugs plutôt vicieux.
Et dans 'push', il ne faut pas quoter le symbole de variable. Mais bien dans 'add-to-list'. D'ailleurs, tu t'y es fait prendre ci-dessus ;-)
--drkm
SL <spam@wanadoo.fr> writes:
Avec un (add-to-list load-path "path") également, mais il me semble que
drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Ah ? C'est ce que j'utilise.
'add-to-list' fait la même chose que 'push', mais va d'abord
parcourir la liste pour voir si l'élément ne s'y trouve pas déjà.
Comme l'ordre dans le 'load-path' est important, ça peut mener à
des bugs plutôt vicieux.
Et dans 'push', il ne faut pas quoter le symbole de variable.
Mais bien dans 'add-to-list'. D'ailleurs, tu t'y es fait prendre
ci-dessus ;-)
Avec un (add-to-list load-path "path") également, mais il me semble que drkm me l'a déconseillé, je ne retrouve plus pourquoi.
Ah ? C'est ce que j'utilise.
'add-to-list' fait la même chose que 'push', mais va d'abord parcourir la liste pour voir si l'élément ne s'y trouve pas déjà. Comme l'ordre dans le 'load-path' est important, ça peut mener à des bugs plutôt vicieux.
Et dans 'push', il ne faut pas quoter le symbole de variable. Mais bien dans 'add-to-list'. D'ailleurs, tu t'y es fait prendre ci-dessus ;-)
