Сравнение режимов Python для Emacs

Question

Итак, у меня есть Emacs 24.3, и с ним появляется довольно недавний файл python.el, предоставляющий режим Python для редактирования.

Но я продолжаю читать, что есть python-mode.el на Launchpad, и сравнивая два файла, которые он выскакивает мне, что первый из них имеет не более 4000 строк, а последний - почти 20000. Это говорит о том, что последнее намного больше -богатые.

И я не могу найти какое-либо сравнение функций в сети, документацию или, по крайней мере, список возможностей для каждого из них. Да, есть подсветка синтаксиса и встроенный интерпретатор, но как насчет завершения в буфере оболочки, завершения в буфере исходного файла, аутоиндента, повтора и т. Д.

Итак, каковы важные особенности этих режимов? (Или любой другой режим Python для Emacs, который вы рекомендуете.) Просьба предоставить подробные ответы.

Answer 1

Я был пользователем python-mode.el один раз, но прекратил использовать его год назад, потому что я чувствовал, что он был разработан, был плохо организован. Вот список из записки, которую я взял в то время. Но я должен предупредить вас, что с тех пор прошло почти год, поэтому ситуация может быть изменена.

1. Многие копии & функции пасты.
2. Много случайно работающего кода. Например, не обход переменных, а использование неявного привязки. Это вызывает много ошибок компиляции (и не будет работать, если вы измените его на лексическую область).
3. Грубая гранулярность фиксации. Я отправляю патч, и он был совершен с несвязанными изменениями.

Одна вещь, которая мне нравится в python-mode.el, поставляется с автоматическим набором тестов (хотя я никогда не запускал его). У python.el пока нет тестового набора. Но я знаю, что автор python.el пишет это сейчас.

Хотя python.el компактен, это не означает, что вы получаете плохую функциональность. Это больше похоже на то, чтобы держать ядро ​​маленьким и позволить другим расширять его, предоставляя сжатый API. Тот же автор python.el написал python-django.el, чтобы расширить python.el для проектов django. Я написал автозаполнение плагина для Python под названием Jedi.el и расширенный плагин IPython под названием EIN. Оба они имеют лучшую поддержку python.el, чем python-mode.el (ну, это потому, что я не использую python-mode.el, хотя).

У меня было несколько вещей, которые я пропустил сначала из python-mode.el, но они быстро исправлены в python.el (Конечно, это, вероятно, означает, что я не использовал столько функций в python-mode.el) ,

что о завершении в буфере оболочки, завершение в буфере исходного файла, автоотступы, создание отступа и т.д.

• завершения в буфере оболочки: Это вроде работает как python.el и питон -mode.el. Но иногда это не работает, если у вас плохая комбинация версии Emacs и версии python (-mode) .el. Таким образом, вероятно, python.el безопаснее. Но если вы хотите, лучшее решение, использовать EIN :)

• завершение в буфере исходного файла: Просто используйте Jedi.el :)

• автоотступа/отступ: Я не знаю, какой из них лучше в производительности -wise. Однако keybind для возврата отличается друг от друга. В python-mode.el, если вы набираете RET, вы получаете autoindent. В python.el RET не дает вам отступов, и вместо этого вы должны использовать C-j. На самом деле C-j для newline + indentation является универсальным поведением в Emacs. Так что python.el лучше, если вы программируете на других языках.

Answer 2

Будучи активно участвует в разработке питон-mode.el последних лет, мой комментарий, вероятно, смещен: Рекомендует, чтобы остаться с python.el для Emacs начинающиха. Также его автор заслуживает признания за некоторые полезные подходы.

python-mode.el предназначен для повышения производительности редактирования. Это упрощает запуск или выполнение через оболочки python2 и python3 или IPython параллельно.

Он уменьшает количество необходимых нажатий клавиш, предоставляя индивидуальные команды. Это делает редактирование быстрее, помогает программировать с помощью речи, макро-управляемого входа и т.д.

Поддержки Python функции язык не известен из python.el в настоящее время:

PY-вверх, вниз-р - путешествия вложенных блоков

Избегайте опечатки выборки формы в точке, клаузулы, например:

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

...

Нет необходимости настраивать при тестировании различных Versio нс:

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

...

• Понятия тонкоуровневого частей - py-expression, py-minor-expression
• команда, работающая версировано и параллельно (I) Python-исполняемые файлы, не нужно заново определить по умолчанию Python
• в значительной степени устраняя необходимость использования активной области, отмеченной ранее, см. py-execute-line и целая группа больше

Чтобы получить обзор, просмотрите меню. Справочник "doc" перечисляет команды.

С повышением качества кода: способ сравнения обоих режимов, вероятно, проверяет ошибки, перечисленные в http://debbugs.gnu.org/. См. Например, ошибка № 15510, № 16875; или http://lists.gnu.org/archive/html/help-gnu-emacs/2014-04/msg00250.html

Прокомментировано в разделе «Грубая детализация фиксации»: в то время как tkf в основном правильно ищет мелкие кусочки, иногда условия заставляют меня оставить правило. Значительные части написаны не вручную, а программами, находящимися в каталоге «devel». Они создают файлы, используемые в ветке разработки frist - т. Е. Компоненты-python-mode. При запуске новой функции часто не очевидно, если выбранный путь является плодотворным. После того, как сотня будет совершена, или она может по-прежнему оказаться невозможной или не рекомендуется.Вместо того, чтобы публиковать все меандры, они использовали эту экспериментальную ветку в течение нескольких дней в этих случаях и проверяли, когда тесты прошли.

BTW Предполагается, что tkf относится не к ошибкам компиляции - которые будут искать мгновенно, но предупреждениям компилятора. К сожалению, Emacs смешивает предупреждение о предпочтениях подкрепленного стиля с реальными ошибками.