Переключение с python-mode.el на python.el

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

Два основных вопроса для меня с python.el были

  • Каждый буфер, посещающий файл python, получает свою собственную уступающую интерактивную оболочку python. Я привык делать разработку в одной интерактивной оболочке и обмениваться данными между файлами python. (Может показаться, что это плохая практика с точки зрения программного обеспечения, но я обычно работаю с огромными наборами данных, которые требуют времени для загрузки в память.)

  • Поддержка скелетного режима в python.el, которая казалась абсолютно безвозмездной (синтаксис python делает такую ​​автоматизацию ненужной) и плохо спроектирован (например, он не знает выражений генератора цикла "for" или "<expr 1> if <cond> else <expr 2>", поэтому вам нужно вернуться и удалить двоеточия, которые он вставляет, после того, как вы настаиваете на том, что вы вводите предложения выражения в минибуфере.) Я не мог понять, как отключить его. Была переменная python.el, которая утверждала, что контролирует это, но она, похоже, не работает. Возможно, что версия python.el, которую я использовал, была сломана (она появилась из пакета debian emacs-snapshot), поэтому, если кто-нибудь знает о ее обновленной версии, я хотел бы услышать об этом. (У меня была такая же проблема с версией в CVS emacs примерно две недели назад.)

Ответы

Ответ 1

За что стоит, я не вижу поведения, которое вы видите в проблеме №1: "Каждый буфер, посещающий файл python, получает свою собственную уступающую интерактивную оболочку python".

Это то, что я использовал, используя python.el из Emacs 22.2.

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

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

C-c C-z [* Появляется буфер Python *]

C-x o

C-c C-l RET [ "bar" напечатан в * Python *]

C-x b foo.py RET

C-c C-l RET [ "foo" печатается в том же * буфере * Python *

Поэтому два файла используют одну и ту же нижнюю оболочку python. Возможно, есть некоторые непредвиденные взаимодействия между вашими индивидуальными настройками python-mode и поведениями python.el по умолчанию. Вы пытались использовать python.el без настроек .emacs и проверяли, ведет ли он себя таким же образом?

Основная особенность добавления python.el в python-режиме - это функция завершения символа python-complete-symbol. Вы можете добавить что-то вроде этого

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

Тогда набрав

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

вы получите буфер * Completions *, содержащий

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

Он также будет работать в буферах .py.

Ответ 2

  • Я не могу воспроизвести это поведение на Emacs v23.1, это, должно быть, было изменено с тех пор.

  • Забудьте о поддержке любого режима скелета и используйте гипер-расширенный и расширяемый yasnippet, это действительно стоит попробовать

Ответ 3

Обратите внимание, что почти все сказанное здесь устарело, так как все изменилось.

Команды python-mode.el имеют префикс "py-" в основном, вы должны иметь возможность использовать команды от обоих, независимо от того, какой из них был загружен первым.

python-mode.el не выгружает python.el; рядом с картой python-mode, которая переопределяется.

Разница находится в отображаемом меню и в режиме набора, однако последний из них будет определен.

Ответ 4

python-mode.el написан сообществом Python. python.el написано сообществом emacs. Я использовал python-mode.el до тех пор, пока я помню, и python.el даже не приближается к стандартам python-mode.el. Я доверяю сообществу Python лучше, чем сообщество Emacs, чтобы придумать достойный файл режима. Просто придерживайтесь python-mode.el, действительно ли есть причина не для?

Ответ 5

python-mode.el не поддерживает строки с тройным кавычком, поэтому, если ваша программа содержит длинные docstrings, вся синтаксическая раскраска (и связанные с ней синтаксические функции) имеет тенденцию разрушаться.

my.02