Passage de python-mode.el à python.el

Question

J'ai récemment essayé de passer de l'utilisation python-mode.el à python.el pour éditer des fichiers python dans emacs, j'ai trouvé l'expérience un peu étrangère et improductive, et j'ai filé en arrière. J'ai utilisé python-mode.el depuis une dizaine d'années, je suis donc peut-être un peu figé dans mes habitudes. J'aimerais connaître l'avis de quiconque a soigneusement évalué les deux modes, en particulier les avantages et les inconvénients qu'il perçoit pour chacun d'entre eux et la manière dont son travail interagit généralement avec les caractéristiques spécifiques de l'outil de gestion de l'information. python.el .

Les deux principaux problèmes pour moi avec python.el étaient

1. Chaque tampon visitant un fichier python obtient son propre shell python interactif inférieur. J'ai l'habitude de faire le développement dans un seul shell interactif et de partager les données entre les fichiers python. (Cela peut sembler une mauvaise pratique du point de vue de l'ingénierie logicielle, mais je travaille généralement avec d'énormes ensembles de données qui prennent du temps à charger en mémoire).

2. Le support du mode squelette dans python.el, qui semblait absolument gratuit (la syntaxe de python rend cette automatisation inutile) et mal conçu (par exemple, il n'a aucune connaissance de " for "des expressions de générateur de boucle ou " <expr 1> if <cond> else <expr 2> ", vous devez donc revenir en arrière et supprimer les deux-points qu'il insère utilement après avoir insisté pour que vous entriez les clauses de l'expression dans le minibuffer). Je n'ai pas réussi à trouver comment le désactiver. Il y avait un python.el qui prétendait contrôler cela, mais cela ne semblait pas fonctionner. Il se pourrait que la version de python.el que j'utilisais était cassé (il provenait du paquet debian emacs-snapshot) donc si quelqu'un connaît une version à jour, j'aimerais l'entendre. (J'ai eu le même problème avec la version dans CVS emacs d'il y a environ deux semaines).

Answer 1

Pour ce que cela vaut, je ne vois pas le comportement que vous observez dans le problème n°1, "Chaque tampon visitant un fichier python obtient son propre shell python interactif inférieur".

C'est ce que j'ai fait en utilisant python.el depuis Emacs 22.2.

C-x C-f foo.py [insert : print "foo"]

C-x C-f bar.py [insérer : print "bar"]

C-c C-z [le tampon *Python* apparaît].

C-x o

C-c C-l RET ["bar" est imprimé en *Python*]

C-x b foo.py RET

C-c C-l RET ["foo" est imprimé dans le même tampon *Python*].

Les deux fichiers partagent donc le même shell inférieur python. Peut-être y a-t-il une interaction imprévue entre vos personnalisations de python-mode et les comportements par défaut de python.el. Avez-vous essayé d'utiliser python.el sans vos personnalisations .emacs et de vérifier s'il se comporte de la même manière ?

La principale fonctionnalité ajoutée de python.el par rapport à python-mode est la fonction de complétion de symboles python-complete-symbol. Vous pouvez ajouter quelque chose comme ceci

(define-key inferior-python-mode-map "\C-c\t" 'python-complete-symbol)

Puis en tapant

>>> import os
>>> os.f[C-c TAB]

vous obtiendrez un tampon *Completions* contenant

Click <mouse-2> on a completion to select it.
In this buffer, type RET to select the completion near point.

Possible completions are:
os.fchdir                          os.fdatasync
os.fdopen                          os.fork
os.forkpty                         os.fpathconf
os.fstat                           os.fstatvfs
os.fsync                           os.ftruncate

Cela fonctionnera aussi dans les tampons de fichiers .py.

Answer 2

1. Je ne peux pas reproduire ce comportement sur Emacs v23.1, cela a dû être modifié depuis.

2. Oubliez le support squelettique de n'importe quel mode et utilisez l'outil hyper avancé et extensible yasnippet au lieu de cela, ça vaut vraiment le coup d'essayer !

Answer 3

Notez que presque tout ce qui est dit ici est obsolète entre-temps, car les choses ont changé.

Les commandes de python-mode.el sont préfixées "py-". En principe, vous devriez pouvoir utiliser les commandes des deux, indépendamment de celle qui a été chargée en premier.

python-mode.el ne décharge pas python.el ; à part python-mode-map, qui est redéfini.

La différence se situe au niveau du menu affiché et du réglage des touches, mais c'est le dernier chargé qui est déterminant.

Answer 4

Python-mode.el est écrit par la communauté Python. python.el est écrit par la communauté emacs. J'ai utilisé python-mode.el aussi longtemps que je me souvienne et python.el ne s'approche même pas des standards de python-mode.el. Je fais plus confiance à la communauté Python qu'à la communauté Emacs pour proposer un fichier mode décent. Il suffit de s'en tenir à python-mode.el, y a-t-il vraiment une raison de ne pas le faire ?

Answer 5

Python-mode.el ne prend pas en charge les chaînes de caractères triplement citées. Par conséquent, si votre programme contient de longues docstrings, toutes les colorations syntaxiques (et les caractéristiques syntaxiques associées) ont tendance à s'effondrer.

mon point de vue