Emacs的Python模式比较
所以我有Emacs 24.3，并提供了一个相当新的python.el文件，提供了Python模式进行编辑。
但是我一直在读， Launchpad上有一个python-mode.el ，比较它向我跳出的两个文件，前者在4000行以下，而后者几乎是20000.这表明后者更多function-丰富。
而且我无法find关于它们的任何在线function比较，文档或者至less有关每个function的列表。 是的，有语法高亮和embedded式解释器，但在shell缓冲区中完成，在源文件缓冲区中完成，autoindent，reindent等等。
那么这些模式的重要特点是什么？ （或者您推荐的Emacs其他Python模式。）请提供详细的答案。
我曾经是python-mode.el用户，但是一年前就放弃了使用它，因为我觉得它的开发方式组织得不好。 以下是我当时所做的说明。 但是我需要提醒你，自那以后将近一年时间，情况可能会改变。
- 许多复制和粘贴function。
- 许多意外工作的代码。 例如，不要传递variables，而是使用隐式绑定。 这会产生许多编译错误（如果将其更改为词法作用域，将不起作用）。
- 粗略的提交粒度。 我发送了一个补丁，并且发生了无关的修改。
我喜欢关于python-mode.el的一件事是自动testing集（尽pipe我从来没有运行它）。 python.el还没有testing集。 但是我知道python.el的作者现在正在写它。
虽然python.el是紧凑的，但并不意味着你得到的function差。 这更像是保持核心小，让其他人通过提供简洁的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中使用这么多的function）。
shell缓冲区的完成情况，源文件缓冲区的完成情况，autoindent，reindent等
-
在shell缓冲区中完成：它在python.el和python-mode.el中都有效。 但是有时候，如果Emacs版本和python（-mode）.el版本的组合不好，那么这种方法就不起作用。 所以可能python.el是这样安全的。 但是如果你想要更好的解决scheme，请使用EIN 🙂
-
在源文件缓冲区完成：只需使用Jedi.el 🙂
-
autoindent / reindent：我不知道哪一个在性能方面更好。 但是，返回的keybind不同于另一个。 在python-mode.el中，如果你inputRET，你会得到autoindent。 在python.el中，RET不给你缩进，你应该使用Cj来代替。 实际上Cj换行+缩进是Emacs中的通用行为。 所以如果你用其他语言编程，python.el会更好。
去年大量参与开发python-mode.el，我的评论可能是有偏见的：build议留在python.el for Emacs初学者。 另外它的作者也值得称赞一些有用的方法。
python-mode.el旨在提高编辑效率。 它可以很容易地通过并行的python2和python3或IPython shell来运行或执行。
它减less了提供定制命令所需的按键次数。 它使编辑速度更快，通过语音辅助编程，macros观驱动input等。
支持python.el目前不知道的Python语言特性：
py-up，py-down – 旅行嵌套块
避免input拼写错误，例如：
py-backward-clause py-copy-clause py-down-clause
…
testing不同版本时无需自定义：
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”目录中的程序来完成的。 他们创build用于开发分支frist的文件 – 即components-python-mode。 开始一项新function时，如果select的path富有成效，通常并不明显。 经过一百次即将发生的事情，仍然可能变得不可能或不那么可取。 而不是张贴所有的曲折，用于在这些情况下保持这个实验分支几天，并在testing通过时检查。
顺便说一下，假设tkf不是指编译错误，而是编译器警告。 不幸的是，Emacs将关于支持的样式偏好的警告与真实错误混合在一起
