Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

question de débutant: major mode python

6 réponses
Avatar
simon bergot
je viens de me mettre à emacs (21.3 pour windows) et le mode python ne
semble pas être installé par défaut. J'ai chargé le mode mais je n'ai
pas trouvé dans la doc comment l'installer et le lancer.

merci d'avance.
--
manger un castor, c'est sauver un arbre

6 réponses

Avatar
Sébastien Kirche
Le 22 September 2005 à 16:09, simon bergot a formulé :

je viens de me mettre à emacs (21.3 pour windows) et le mode python ne
semble pas être installé par défaut. J'ai chargé le mode mais je n'ai
pas trouvé dans la doc comment l'installer et le lancer.

merci d'avance.



Quand tu dis «chargé le mode» tu veux dire téléchargé ou chargé dans
Emacs ?

Si c'est seulement téléchargé, il faut placer le fichier .el dans un
répertoire accessible au load-path de gnus.

Typiquement :
- les répertoires lisp et site-lisp fournis avec Emacs, mais je te
déconseille d'y mettre le mode que tu as récupéré
- le répertoire équivalent au home de l'utilisateur sous Unix (voir
ci-dessous)
- et n'importe quel autre répertoire que tu indiqueras à Emacs de
charger

Histoire de définir l'environnement pour indiquer à Emacs où il peut
créer ses fichiers (si ce n'est pas déjà fait) histoire qu'il n'aille
pas polluer ton disque n'importe comment, je te conseille de jeter un
oeil à ce fil :

http://groups.google.com/group/fr.comp.applications.emacs/browse_frm/thread/469db5895f7ea4cb/3122f8ad45e246d8

Ensuite pour te servir du mode python, tu peux tester interactivement
par un M-x load-library python.el (à remplacer par le bon nom).

Il devrait mettre en place les mécanismes nécessaire à activer le mode
lors de l'ouverture d'un fichier python. Si tu es déjà dans un tel
fichier au moment de charger le mode, un M-x puthon-mode devrait
t'activer le font-locking (coloration des mots clés) et les automatismes
fournis par le mode.

Si c'est concluant, tu peux ajouter un (require 'python-mode) dans ton
fichier ~/.emacs (à créer s'il n'existe pas) pour que ça soit
automatiquement chargé et activé à la prochaine utilisation d'Emacs.

Si tu ne comprends pas quelque chose dans mes explications (comme tu
indiques commencer à utiliser emacs) ou si quelque chose ne fonctionne
pas comme prévu, n'hésite pas à revenir te faire expliquer le point.

HTH.
--
Sébastien Kirche
Avatar
drkm
Sébastien Kirche writes:

- les répertoires lisp et site-lisp fournis avec Emacs, mais je te
déconseille d'y mettre le mode que tu as récupéré



Tiens. Pourquoi ? J'installe souvent des bibliothèques dans
'site-lisp'. On n'est jamais le seul utilisateur de sa machine.
Il y a au moins un compte utilisateur et un compte root. Et dans
ce cas, les deux peuvent vouloir utiliser ce mode.

Il y a bien des cas où l'on veut réellement installer une
bibliothèque pour son usage strictement personnel, mais je dirais
qu'il s'agit alors plus de fichiers de configuration que de
bibliothèques. Ou que l'on ne dispose pas des droits nécessaires
(au sens droits Unix ou contrat d'utilisation de la machine).

Pourquoi déconseilles-tu l'utilisation de 'site-lisp' ici ?

Un point que je n'ai jamais tranché (car je n'ai jamais
vraiment cherché), c'est s'il est nécessaire d'utiliser le
'site-lisp' « versionné » ou non, lorsque l'on byte-compile la
bibliothèque. Par « versionné », j'entends le répertoire
'.../emacs/22.0.50/site-lisp' par opposition au répertoire
'.../emacs/site-lisp', par exemple.

En effet, je sais qu'il y a des incompatibilités entre le
byte-code produit par différentes versions d'Emacs, mais je ne
sais pas en quelle mesure, ni entre quelles versions.

Pour résumer, je pense qu'il y a trois répertoires intéressants
en standard où trouver/placer des bibliothèques :

.../emacs/22.0.50/lisp
.../emacs/22.0.50/site-lisp
.../emacs/site-lisp

En plus de ceux-là, il peut être intéressant de se créer un
répertoire personnel, par exemple '~/.emacs.d/home-lisp', qu'il
est simple de gérer en commençant son '~/.emacs.el' par :

;; La « variabilisation » et la « listification » du
;; 'home-lisp' sont laissées en exercice (utilisation d'une
;; variable pour renseigner le répertoire, et permettre
;; d'avoir une liste de répertoire, pour s'approcher d'un
;; 'load-path' personnel).
;;
(let ((default-directory "~/.emacs.d/home-lisp"))
(load-file "subdirs.el"))

le fichier '~/.emacs.d/home-lisp/subdirs.el' contenant, tout
comme les 'subdirs.el' des répertoires standards :

(if (fboundp 'normal-top-level-add-subdirs-to-load-path)
(normal-top-level-add-subdirs-to-load-path))

L'utilisation de cette fonction permet de gérer ce répertoire
personnel comme les répertoires standards en regard du
'load-path' (utilisation d'un fichier '.nosearch', par exemple,
ou ajout simple d'un répertoire, sans devoir modifier son
'~/.emacs.el').

L'étape suivante étant de garder cette architecture
décentralisée, et d'y ajouter le support automatique des fichiers
'loaddefs.el', qui sont gérés de manière spéciale pour le
répertoire '.../emacs/22.0.50/lisp', au moyen d'un petit ensemble
de routines additionnelles. C'est d'ailleurs selon moins des
routines qui font défaut dans la distribution standard.

Ensuite pour te servir du mode python, tu peux tester interactivement
par un M-x load-library python.el (à remplacer par le bon nom).



Si je ne me trompe pas, cela va dans tous les cas charger la
version source de la bibliothèque, plutôt que la version
byte-compilée. Je dirais plutôt : 'M-x load-library python' (à
remarquer que charger explicitement une bibliothèque terminant
par '.el' est justement intéressant pour obtenir un backtrace
plus clair, puisqu'Emacs charge alors le source et non le
byte-code).

Si c'est concluant, tu peux ajouter un (require 'python-mode) dans ton
fichier ~/.emacs (à créer s'il n'existe pas) pour que ça soit
automatiquement chargé et activé à la prochaine utilisation d'Emacs.



Je déconseillerais cela. Ça voudrait dire que la bibliothèque
serait chargée à chaque lancement normal d'Emacs. On en arrive
vite à un chargement très lent, ce temps étant gaspillé à charger
des bibliothèques dont on ne se servira pas dans cette session,
ou qui de toute façon serait chargées les unes après les autres
lors de leur première utilisation (ce qui se fait beaucoup moins
sentir).

En général, pour installer un mode d'édition, il suffit de
renseigner quelques valeurs à Emacs. Si la bibliothèque est bien
faite, cela est fait dans le code source au moyen de cookies
d'autoload, et il suffit de générer le 'loaddefs.el' associé, et
de s'assurer de l'évaluer au chargement d'Emacs. Sinon, il
suffit en général de s'assurer que tout est ok en regard du
'load-path', et d'ajouter ce qu'il faut à 'auto-mode-alist',
'interpreter-mode-alist' et 'magic-mode-alist', et de renseigner
l'autoload qui va bien (éventuellement les autoloads, selon les
points d'entrée principaux, par exemple si le mode pour Python
inclus une interface vers l'interpréteur).

Donc, si la bibliothèque est bien faite, on génère le
'loaddefs.el' qui est chargé automatiquement par son
'subdirs.el', sinon on le crée à la main ou on ajoute
l'équivalent à son '~/.emacs.el' :

(autoload 'python-mode "python-mode"
"Major mode for editing Python files." t)
(push '(".py$" . python-mode) auto-mode-alist)
(push '("python" . python-mode) interpreter-mode-alist)

Je pense qu'il s'agit des grands points de l'installation d'une
bibliothèque. Je ne sais pas si j'ai oublié quelque chose
d'important ni si j'ai dit des bêtises. Cela est valable pour
GNU Emacs, je sais que XEmacs possède un système de gestion de
packages que je ne connais pas (et dont je n'ai pas entendu que
du bien). Enfin, le code ci-dessus n'est pas testé : à vos
risques et périls.

Pour terminer, je sais que Matthieu a écrit une page sur le
sujet : <URL:http://www-verimag.imag.fr/~moy/emacs/>. Je n'ai
pas pris le temps de la lire en détail, mais il propose une
automatisation de la procédure. Cela peut intéresser Simon. Au
fait, si tu as des remarques sur ce que je viens de dire,
Matthieu, n'hésite pas.

--drkm
Avatar
Pascal Bourguignon
drkm writes:
Pourquoi déconseilles-tu l'utilisation de 'site-lisp' ici ?



Moi, je l'utilise depuis plusieurs versions d'emacs et plusieurs
machines sans problème.

Un point que je n'ai jamais tranché (car je n'ai jamais
vraiment cherché), c'est s'il est nécessaire d'utiliser le
'site-lisp' « versionné » ou non, lorsque l'on byte-compile la
bibliothèque. Par « versionné », j'entends le répertoire
'.../emacs/22.0.50/site-lisp' par opposition au répertoire
'.../emacs/site-lisp', par exemple.



Pour un .el qui serait spécifique à une version?

Mais pour les .elc, même pas: soit d'un version d'emacs à l'autre ils
sont compatible, soit on recompile quand on installe une nouvelle
version d'emacs. Si on devait travailler avec plusieurs versions
d'emacs en même temps, peut être. Mais en général, quand une nouvelle
version d'emacs apparait, elle est tellement mieux, que je m'empresse
de l'installer sur tous mes ordinateurs.

--
__Pascal Bourguignon__ http://www.informatimago.com/

Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
Avatar
Sébastien Kirche
Le 23 septembre 2005 à 19:09, drkm s'est exprimé ainsi :

Sébastien Kirche writes:

> - les répertoires lisp et site-lisp fournis avec Emacs, mais je te
> déconseille d'y mettre le mode que tu as récupéré

Tiens. Pourquoi ? J'installe souvent des bibliothèques dans
'site-lisp'. On n'est jamais le seul utilisateur de sa machine.
Il y a au moins un compte utilisateur et un compte root. Et dans
ce cas, les deux peuvent vouloir utiliser ce mode.

Il y a bien des cas où l'on veut réellement installer une
bibliothèque pour son usage strictement personnel, mais je dirais
qu'il s'agit alors plus de fichiers de configuration que de
bibliothèques. Ou que l'on ne dispose pas des droits nécessaires
(au sens droits Unix ou contrat d'utilisation de la machine).

Pourquoi déconseilles-tu l'utilisation de 'site-lisp' ici ?



Je suis d'accord que site-lisp est prévu pour mettre des modules à
disposition de tout le système (typiquement quand on est dans un cas
multi-utilisateurs).

Mais dans le cas qui nous intéresse ici, on est àma plus dans une
utilisation mono utilisateur où l'utilisateur installe lui-même emacs.
Et c'est un coup à ce que les modules rajoutés en plus de ceux fournis
de série disparaissent à l'occasion d'une prochaine mise à jour, étant
donné que dans la version windows d'Emacs, toute l'arborescence utilisée
par Emacs (etc, lisp, site-lisp, lib...) est contenue dans le répertoire
d'Emacs et non dispersée dans le filesystem.

Si l'OP remplace sa version actuelle par une plus récente, il risque de
chercher pourquoi ses modes ne fonctionnent plus.

Je préfère autant ne rien modifier de ce qui a été fourni avec l'install
de base et rajouter les suppléments dans un répertoire personnel comme
tu l'as décrit plus bas.


[...]

En plus de ceux-là, il peut être intéressant de se créer un
répertoire personnel, par exemple '~/.emacs.d/home-lisp', qu'il
est simple de gérer en commençant son '~/.emacs.el' par :

;; La « variabilisation » et la « listification » du
;; 'home-lisp' sont laissées en exercice (utilisation d'une
;; variable pour renseigner le répertoire, et permettre
;; d'avoir une liste de répertoire, pour s'approcher d'un
;; 'load-path' personnel).
;;
(let ((default-directory "~/.emacs.d/home-lisp"))
(load-file "subdirs.el"))

le fichier '~/.emacs.d/home-lisp/subdirs.el' contenant, tout
comme les 'subdirs.el' des répertoires standards :

(if (fboundp 'normal-top-level-add-subdirs-to-load-path)
(normal-top-level-add-subdirs-to-load-path))

L'utilisation de cette fonction permet de gérer ce répertoire
personnel comme les répertoires standards en regard du
'load-path' (utilisation d'un fichier '.nosearch', par exemple,
ou ajout simple d'un répertoire, sans devoir modifier son
'~/.emacs.el').



Voilà.


L'étape suivante étant de garder cette architecture
décentralisée, et d'y ajouter le support automatique des fichiers
'loaddefs.el', qui sont gérés de manière spéciale pour le
répertoire '.../emacs/22.0.50/lisp', au moyen d'un petit ensemble
de routines additionnelles. C'est d'ailleurs selon moins des
routines qui font défaut dans la distribution standard.



Ça c'est une technique que je ne connais pas et que je devrais étudier
plus en détail.
Pour le moment, je me contente de la méthode subdirs.el.

> Ensuite pour te servir du mode python, tu peux tester
> interactivement par un M-x load-library python.el (à remplacer par
> le bon nom).

Si je ne me trompe pas, cela va dans tous les cas charger la
version source de la bibliothèque, plutôt que la version
byte-compilée. Je dirais plutôt : 'M-x load-library python' (à
remarquer que charger explicitement une bibliothèque terminant
par '.el' est justement intéressant pour obtenir un backtrace
plus clair, puisqu'Emacs charge alors le source et non le
byte-code).


> Si c'est concluant, tu peux ajouter un (require 'python-mode) dans
> ton fichier ~/.emacs (à créer s'il n'existe pas) pour que ça soit
> automatiquement chargé et activé à la prochaine utilisation d'Emacs.

Je déconseillerais cela. Ça voudrait dire que la bibliothèque
serait chargée à chaque lancement normal d'Emacs. On en arrive
vite à un chargement très lent, ce temps étant gaspillé à charger
des bibliothèques dont on ne se servira pas dans cette session,
ou qui de toute façon serait chargées les unes après les autres
lors de leur première utilisation (ce qui se fait beaucoup moins
sentir).



Effectivement, le chargement systématique au démarrage n'est pas
optimal. L'idéal étant plutôt de passer par un autoload.

Mais le require est àma plus facile à comprendre et plus simple à mettre
en oeuvre par un débutant qui découvre tout en même temps.


En général, pour installer un mode d'édition, il suffit de
renseigner quelques valeurs à Emacs. Si la bibliothèque est bien
faite, cela est fait dans le code source au moyen de cookies
d'autoload, et il suffit de générer le 'loaddefs.el' associé,



Justement, comment tu procèdes pour cette génération ?

et de s'assurer de l'évaluer au chargement d'Emacs. Sinon, il suffit
en général de s'assurer que tout est ok en regard du 'load-path', et
d'ajouter ce qu'il faut à 'auto-mode-alist', 'interpreter-mode-alist'
et 'magic-mode-alist', et de renseigner l'autoload qui va bien
(éventuellement les autoloads, selon les points d'entrée principaux,
par exemple si le mode pour Python inclus une interface vers
l'interpréteur).

Donc, si la bibliothèque est bien faite, on génère le
'loaddefs.el' qui est chargé automatiquement par son
'subdirs.el', sinon on le crée à la main ou on ajoute
l'équivalent à son '~/.emacs.el' :

(autoload 'python-mode "python-mode"
"Major mode for editing Python files." t)
(push '(".py$" . python-mode) auto-mode-alist)
(push '("python" . python-mode) interpreter-mode-alist)



Tiens, je ne connaissais pas interpreter-mode-alist.

Je pense qu'il s'agit des grands points de l'installation d'une
bibliothèque. Je ne sais pas si j'ai oublié quelque chose
d'important ni si j'ai dit des bêtises. Cela est valable pour
GNU Emacs, je sais que XEmacs possède un système de gestion de
packages que je ne connais pas (et dont je n'ai pas entendu que
du bien). Enfin, le code ci-dessus n'est pas testé : à vos
risques et périls.

Pour terminer, je sais que Matthieu a écrit une page sur le
sujet : <URL:http://www-verimag.imag.fr/~moy/emacs/>. Je n'ai
pas pris le temps de la lire en détail, mais il propose une
automatisation de la procédure. Cela peut intéresser Simon. Au
fait, si tu as des remarques sur ce que je viens de dire,
Matthieu, n'hésite pas.

--drkm



--
Sébastien Kirche
Avatar
drkm
Pascal Bourguignon writes:

Mais pour les .elc, même pas: soit d'un version d'emacs à l'autre ils
sont compatible, soit on recompile quand on installe une nouvelle
version d'emacs. Si on devait travailler avec plusieurs versions
d'emacs en même temps, peut être. Mais en général, quand une nouvelle
version d'emacs apparait, elle est tellement mieux, que je m'empresse
de l'installer sur tous mes ordinateurs.



Vi. Je suis d'accord. Mais comme je dispose de deux
répertoires, l'un pour une version particulière et l'autre
partagé, j'aime autant utiliser le « versionné » (celui de la
version précédente sera supprimé en même temps que la dite
version), afin d'éviter des bugs subtils dûs à des différences
dans le byte-compilateur.

--drkm
Avatar
drkm
Sébastien Kirche writes:

Le 23 septembre 2005 à 19:09, drkm s'est exprimé ainsi :

L'étape suivante étant de garder cette architecture
décentralisée, et d'y ajouter le support automatique des fichiers
'loaddefs.el', qui sont gérés de manière spéciale pour le
répertoire '.../emacs/22.0.50/lisp', au moyen d'un petit ensemble
de routines additionnelles. C'est d'ailleurs selon moins des
routines qui font défaut dans la distribution standard.



Ça c'est une technique que je ne connais pas et que je devrais étudier
plus en détail.
Pour le moment, je me contente de la méthode subdirs.el.



Justement, ce fichier est l'endroit idéal pour charger les
fichiers 'loaddefs.el'. Il faut définir une fonction dans le
même goût que 'normal-top-level-add-subdirs-to-load-path', mais
qui de plus va vérifier la présence d'un tel fichier et le
charger le cas échéant.

En général, pour installer un mode d'édition, il suffit de
renseigner quelques valeurs à Emacs. Si la bibliothèque est bien
faite, cela est fait dans le code source au moyen de cookies
d'autoload, et il suffit de générer le 'loaddefs.el' associé,



Justement, comment tu procèdes pour cette génération ?



~> cat bin/drkm-emacs-loaddefs
#!/bin/sh

EMACS_dir="c:/Program Files/emacs/22.0.50"
EMACS="${EMACS_dir}/bin/emacs.exe"
AUTOGEN="${EMACS_dir}/site-lisp/cedet-1.0pre3/common/cedet-autogen.el"

"${EMACS}" -batch -l "${AUTOGEN}"
-f cedet-batch-update-autoloads loaddefs.el

~> ls draft/fcae
loaddefs-src.el

~> cat draft/fcae/loaddefs-src.el
(defvar no nil
"Doc no var.")
(defun no ()
"Doc no fun."
nil)
;;;###autoload
(defvar yes nil
"Doc yes var.")
;;;###autoload
(defun yes ()
"Doc yes fun."
t)

~> (cd draft/fcae; drkm-emacs-loaddefs)
Wrote ~/draft/fcae/loaddefs.el
Generating autoloads for loaddefs-src.el...
Generating autoloads for loaddefs-src.el...done
Updating header...
Updating header...done
Wrote ~/draft/fcae/loaddefs.el

~> ls draft/fcae
loaddefs-src.el loaddefs.el

~> cat draft/fcae/loaddefs.el
;;; loaddefs.el --- Auto-generated CEDET autoloads
;;
;;; Code:


;;;### (autoloads (yes) "loaddefs-src" "loaddefs-src.el" (17206 54945))
;;; Generated autoloads from loaddefs-src.el

(defvar yes nil "
Doc yes var.")

(autoload (quote yes) "loaddefs-src" "
Doc yes fun.

(fn)" nil nil)

;;;***

;; Local Variables:
;; version-control: never
;; no-byte-compile: t
;; no-update-autoloads: t
;; End:
;;; loaddefs.el ends here

Le fichier 'cedet-autogen.el' est indépendant du reste de
CEDET, et peut être récupéré directement sur le CVS du projet,
par exemple via l'interface web : <URL:http://cedet.sf.net/>. Il
y a moyen de s'en passer, et d'utiliser les commandes et
fonctions d'Emacs directement : 'C-h a update.*auto <RET>'. À
vrai dire, je ne me souviens plus exactement pourquoi j'utilise
les fonctions de CEDET.

--drkm