从python-mode.el切换到python.el

31

我最近尝试使用python.el编辑emacs中的Python文件,但我发现体验有点陌生和低效,于是又换回了python-mode.el。我已经使用python-mode.el大约十年了,所以我可能有点固执己见。我很想听听那些仔细评估过这两种模式的人的意见,特别是他们看到的优缺点以及他们的工作如何与python.el的特定功能互动。

对我来说,python.el存在两个主要问题:

  1. 每个包含Python文件的缓冲区都有自己的交互式Python shell。我习惯于在一个交互式shell中进行开发,并在Python文件之间共享数据。(从软件工程的角度来看,这可能看起来不太好,但我通常处理的是需要花费一些时间将其加载到内存中的大型数据集。)

  2. python.el中的skeleton-mode支持似乎绝对是多余的(Python的语法使得这样的自动化工具是不必要的),而且设计得很糟糕(例如,它没有关于“for”循环生成器表达式或“<expr 1> if <cond> else <expr 2>”表达式的知识,所以你必须回去删除它在强制要求你在minibuffer中输入表达式子句后插入的冒号。)我无法弄清楚如何关闭它。有一个python.el变量声称可以控制这一点,但它似乎不起作用。可能是我使用的python.el版本有问题(它来自Debian emacs-snapshot软件包),因此如果有人知道最新版本的python.el,我想听听他们的意见。(大约两周前,在CVS emacs中我遇到了同样的问题。)


6
你没有说明为什么尝试切换到python.el。它有哪些优点? - ShreevatsaR
6个回答

4

就我所知,我没有看到你在问题#1中看到的行为,“每个访问python文件的缓冲区都有自己的下位交互式python shell。”

这是我使用Emacs 22.2中的python.el所做的。

C-x C-f foo.py [插入:print“foo”]

C-x C-f bar.py [插入:print“bar”]

C-c C-z [*Python*缓冲区出现]

C-x o

C-c C-l RET [在*Python*中打印了“bar”]

C-x b foo.py RET

C-c C-l RET [在同一个*Python*缓冲区中打印了“foo”]

因此,这两个文件共享相同的下位python shell。也许你的python-mode个性化定制与python.el的默认行为之间存在一些意想不到的交互作用。您是否尝试过使用没有您的.emacs自定义并检查其是否以相同的方式运行的python.el?

python.el相对于python-mode的主要功能增强是符号完成函数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文件缓冲区中工作。

3
在Ubuntu 8.04(Emacs 23)中使用emacs-snapshot软件包中的python.el时,我似乎没有python-complete-symbol函数。 - Carl Meyer
1
这个答案中的信息已经过时了,现在适用于Emacs 24.1.50版本。上面的defun已被移除,并由python-completion-complete-at-point和其他几种补全机制取而代之。我对这些工作原理不太清楚,否则我会编辑这个答案的。 - suvayu

3
  1. 我无法在Emacs v23.1上重现这种行为,这一定是自那时以来发生了变化。

  2. 忘记任何模式的骨架支持,使用超级先进和可扩展的yasnippet代替,它真的值得一试!


2

请注意,这里几乎所有的内容都已过时,因为事情发生了变化。

python-mode.el命令基本上以"py-"为前缀,你应该能够使用两个命令,不论哪一个先加载。

python-mode.el不会卸载python.el;除了重新定义的python-mode-map之外。

区别在于菜单显示和按键设置,但是最后加载的将确定。


1

python-mode.el是由Python社区编写的,而python.el则是由Emacs社区编写的。我使用python-mode.el已经很长时间了,而python.el甚至无法达到python-mode.el的标准。我相信Python社区比Emacs社区更能够提供一个体面的模式文件。只需坚持使用python-mode.el,真的有理由不这样做吗?


19
谢谢您的意见,但它比较独断。我正在寻找有关软件包功能的实际比较,不在乎作者所认为的资格。 - Alex Coventry

1

python-mode.el 不支持三引号字符串,所以如果您的程序包含长文档字符串,则所有语法着色(以及相关的语法特性)往往会崩溃。

我的观点


我刚刚尝试了一下python-mode.el版本5.1.0,但无法复现此问题:文档字符串与字体锁定完全正常。我不认为像这样的错误会长时间存在于Emacs中*主要的Python模式中,因为文档字符串随处可见,某人很快就会发现其不良行为。 - paprika
啊!现在我知道你的意思了……我刚刚在一个文档字符串中发现了这个错误:在文档字符串内部引用确实会破坏语法高亮。 - paprika
1
@paprika,@Gyom:就是这个问题,三引号字符串在5.2.0得到解决。 - Ian Tegebo

0

很遗憾,Debian已经删除了python-mode包,因此我不得不尝试python.el。我加载它并运行“describe-bindings”。它似乎是为elisp编码人员设计的,他们认为c-X;是注释Python代码行的直观绑定。(哇)。此外,我发现没有任何方法可以注释代码区域,或者说,没有带有字符串“region”和“comment”的绑定。

通过git clone https://gitlab.com/python-mode-devs/python-mode.git仍然可以克隆好老的python-mode。在撰写本文时,它上次编辑是一周前,因此可以安全地假设它没有被放弃。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接