Comparaison des modes Python pour Emacs

Question

J'ai donc Emacs 24.3 et, avec lui, une version assez récente d'Emacs. python.el qui fournit un mode Python pour l'édition.

Mais je continue à lire qu'il existe un python-mode.el sur Launchpad et en comparant les deux fichiers, je constate que le premier contient moins de 4000 lignes, alors que le second en contient près de 20000. Cela suggère que ce dernier est beaucoup plus riche en fonctionnalités.

Et je n'arrive pas à trouver en ligne de comparaison des fonctionnalités, de documentation, ou au moins une liste des fonctionnalités de chacun d'entre eux. Oui, il y a la coloration syntaxique et l'interpréteur intégré, mais qu'en est-il de la complétion dans le tampon du shell, de la complétion dans le tampon du fichier source, de l'auto-indentation, de la réindentation, etc.

Quelles sont donc les principales caractéristiques de ces modes ? (Ou tout autre mode Python pour Emacs que vous recommandez.) Merci de fournir des réponses détaillées.

Answer 1

J'ai été utilisateur de python-mode.el mais j'ai arrêté de l'utiliser il y a un an car je trouvais que la façon dont il était développé n'était pas bien organisée. Voici une liste tirée de la note que j'ai prise à l'époque. Mais je dois vous avertir que près d'un an s'est écoulé depuis lors et que la situation peut donc avoir changé.

1. Nombreuses fonctions de copier-coller.
2. Nombreux sont les codes qui fonctionnent accidentellement. Par exemple, le fait de ne pas transmettre de variables mais d'utiliser une liaison implicite. Cela produit de nombreuses erreurs de compilation (et ne fonctionnera pas si vous passez à une portée lexicale).
3. Granularité approximative de l'engagement. J'ai envoyé un correctif, et il a été validé avec des changements sans rapport.

Une chose que j'aime à propos de python-mode.el est qu'il est livré avec un ensemble de tests automatisés (bien que je ne l'ai jamais exécuté). python.el n'a pas encore d'ensemble de tests. Mais je sais que l'auteur de python.el est en train de l'écrire.

Si python.el est compact, cela ne veut pas dire que ses fonctionnalités sont médiocres. Il s'agit plutôt de garder un noyau restreint et de laisser les autres l'étendre en fournissant une API concise. Le même auteur de python.el a écrit python-django.el pour étendre python.el aux projets django. J'ai écrit un plugin d'auto-complétion pour Python appelé Jedi.el et un plugin IPython avancé appelé EIN . Tous deux supportent mieux python.el que python-mode.el (enfin, c'est parce que je n'utilise pas python-mode.el).

J'ai manqué quelques petites choses dans python-mode.el, mais elles ont été rapidement corrigées dans python.el (bien sûr, cela signifie probablement que je n'utilisais pas autant de fonctionnalités dans python-mode.el).

qu'en est-il de la complétion dans le tampon du shell, de la complétion dans le tampon du fichier source, de l'autoindentation, de la réindentation, etc.

• dans la mémoire tampon de l'interpréteur de commandes : Cela fonctionne en quelque sorte dans python.el et python-mode.el. Mais parfois cela ne fonctionne pas si vous avez une mauvaise combinaison de la version d'Emacs et de la version de python(-mode).el. Il est donc probable que python.el soit plus sûr de cette manière. Mais si vous voulez une meilleure solution, utilisez EIN :)

• dans la mémoire tampon du fichier source : Il suffit d'utiliser Jedi.el :)

• autoindent/reindent : Je ne sais pas lequel est le plus performant. Cependant, la combinaison de touches pour le retour diffère de l'une à l'autre. Dans python-mode.el, si vous tapez RET, vous obtenez l'autoindent. Dans python.el, RET ne donne pas d'indentation et vous devez utiliser C-j à la place. En fait, C-j pour newline+indentation est un comportement universel dans Emacs. Donc python.el est meilleur si vous programmez dans d'autres langages.

Answer 2

Etant fortement impliqué dans le développement de python-mode.el ces dernières années, mon commentaire est probablement biaisé : Je recommande aux débutants Emacs de rester avec python.el. L'auteur mérite également d'être félicité pour certaines approches utiles.

python-mode.el est conçu pour améliorer la productivité des éditeurs. Il facilite l'exécution en parallèle des shells python2 et python3 ou IPython.

Il réduit le nombre de frappes nécessaires en fournissant des commandes personnalisées. Il accélère les modifications, facilite la programmation vocale, la saisie par macro, etc.

Prend en charge les caractéristiques du langage Python qui ne sont pas encore connues de python.el :

py-up, py-down - déplacement de blocs imbriqués

Évitez les fautes de frappe en cherchant des formes au point, une clause par exemple :

py-backward-clause
py-copy-clause
py-down-clause

...

Il n'est pas nécessaire de procéder à des adaptations lorsque l'on teste différentes versions :

py-execute-clause-python2
py-execute-clause-python3
py-execute-clause-ipython

...

• notion de parties plus fines - py-expression , py-minor-expression
• exécutant des exécutables (I)Python versionnés et mis en parallèle, il n'est pas nécessaire de redéfinir l'exécutable Python par défaut.
• la suppression de la nécessité d'une région active marquée auparavant, voir py-execute-line et bien d'autres encore

Pour avoir une vue d'ensemble, jetez un coup d'œil au menu. Le répertoire "doc" répertorie les commandes.

La qualité du code étant améliorée, il est possible de comparer les deux modes en vérifiant la présence des bogues énumérés dans la section http://debbugs.gnu.org/ . Voir par exemple les bogues #15510, #16875 ; ou http://lists.gnu.org/archive/html/help-gnu-emacs/2014-04/msg00250.html

J'ai déjà commenté la "granularité approximative de l'engagement" : Bien que tkf ait fondamentalement raison de rechercher des morceaux plus petits, les conditions me poussent parfois à abandonner la règle. Des parties considérables ne sont pas écrites à la main, mais par des programmes résidant dans le répertoire "devel". Ils créent des fichiers utilisés en premier lieu dans la branche développement - par exemple components-python-mode. Lors du lancement d'une nouvelle fonctionnalité, il n'est souvent pas évident de savoir si le chemin choisi est fructueux. Après une centaine de tentatives de validation, il peut s'avérer impossible ou peu recommandable. Au lieu de poster tous les méandres, nous avions l'habitude de garder cette branche expérimentale pendant plusieurs jours dans ces cas-là et de vérifier que les tests étaient réussis.

BTW suppose que tkf ne se réfère pas aux erreurs de compilation --qui seraient recherchées instantanément-- mais aux avertissements de compilation. Malheureusement, Emacs mélange les avertissements concernant les préférences de style sauvegardées avec de vraies erreurs.