44

所以我有 Emacs 24.3，它附带了一个相当新的python.el文件，提供了 Python 模式进行编辑。

但我一直读到Launchpadpython-mode.el上有一个，比较两个文件，我发现前者不到 4000 行，而后者几乎 20000 行。这表明后者的功能要丰富得多。

而且我找不到任何关于它们的在线特性比较、文档，或者至少是关于它们每个特性的列表。是的，有语法高亮和嵌入式解释器，但是 shell 缓冲区中的完成、源文件缓冲区中的完成、自动缩进、重新缩进等呢？

那么这些模式的重要特点是什么？（或您推荐的 Emacs 的任何其他 Python 模式。）请提供详细答案。

4

2 回答 2

22

我曾经是 python-mode.el 的用户，但一年前就停止使用它，因为我觉得它的开发方式组织得不好。这是我当时记下的一份清单。但我需要警告你，从那时起已经过去了将近一年，所以情况可能会改变。

  1. 许多复制和粘贴功能。
  2. 许多意外工作的代码。例如，不传递变量而是使用隐式绑定。这会产生许多编译错误（如果将其更改为词法范围，则将不起作用）。
  3. 粗略的提交粒度。我发送了一个补丁，并提交了不相关的更改。

我喜欢 python-mode.el 的一件事是它带有自动化测试集（尽管我从未运行过它）。python.el 还没有测试集。但我知道 python.el 的作者现在正在编写它。

虽然 python.el 很紧凑，但这并不意味着你的功能很差。它更像是保持核心小，并通过提供简洁的 API 让其他人扩展它。python.el 的同一作者编写了python-django.el来为 django 项目扩展 python.el。我为 Python 编写了名为Jedi.el的自动完成插件和名为EIN的高级 IPython 插件。与 python-mode.el 相比，它们对 python.el 的支持都更好（好吧，那是因为我不使用 python-mode.el）。

我首先从 python-mode.el 中遗漏了一些东西，但它们很快在 python.el 中得到了修复（当然，这可能意味着我没有在 python-mode.el 中使用这么多的功能）。

shell 缓冲区中的完成、源文件缓冲区中的完成、自动缩进、重新缩进等呢？

  • 在 shell 缓冲区中完成：它在 python.el 和 python-mode.el 中都有效。但有时如果 Emacs 版本和 python(-mode).el 版本的组合不好，它就不起作用。所以可能 python.el 以这种方式更安全。但是，如果您想要更好的解决方案，请使用EIN :)

  • 在源文件缓冲区中完成：只需使用Jedi.el :)

  • autoindent/reindent：我不知道哪一个在性能方面更好。但是，用于返回的键绑定彼此不同。在 python-mode.el 中，如果你输入 RET 你会得到自动缩进。在 python.el 中，RET 不给你缩进，你应该使用 Cj 代替。实际上，换行+缩进的 Cj 是 Emacs 中的通用行为。因此，如果您使用其他语言进行编程，python.el 会更好。

于 2013-03-28T01:01:02.247 回答
6

去年大量参与开发 python-mode.el，我的评论可能有偏见：建议 Emacs 初学者继续使用 python.el。它的作者也因为一些有用的方法而值得称赞。

python-mode.el 旨在提高编辑效率。它使通过 python2 和 python3 或 IPython shell 并行运行或执行变得容易。

它减少了提供定制命令所需的击键次数。它使编辑更快，通过语音、宏驱动输入等辅助编程。

目前支持 python.el 中未知的 Python 语言功能：

py-up, py-down - 移动嵌套块

避免在获取表单时出现拼写错误，例如一个子句：

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

...

测试不同版本时无需自定义：

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”目录中的程序编写的。他们创建了在开发分支中使用的文件——即 components-python-mode。当开始一个新功能时，如果选择的路径是富有成效的，通常并不明显。经过一百次左右的可能提交后，它仍然可能变得不可能或不那么值得推荐。不是发布所有的曲折，而是在这些情况下将该实验分支保留几天，并在测试通过时签入。

顺便说一句，假设 tkf 不是指编译错误——它会立即被查找——而是编译器警告。不幸的是，Emacs 将有关支持样式偏好的警告与实际错误混合在一起。

于 2013-04-02T10:01:09.183 回答