44

だから私はEmacs 24.3を持っていてpython.el、編集用のPythonモードを提供する最新のファイルが付属しています。

python-mode.elしかし、私はLaunchpadに があることを読み続けており、2 つのファイルを比較すると、前者は 4000 行未満で、後者はほぼ 20000 行であることがわかります。これは、後者がはるかに機能が豊富であることを示唆しています。

そして、それらについてのオンライン機能比較、ドキュメント、または少なくともそれぞれの機能に関するリストを見つけることができません。はい、構文の強調表示と組み込みのインタープリターがありますが、シェル バッファーでの補完、ソース ファイル バッファーでの補完、自動インデント、再インデントなどについてはどうでしょうか。

では、これらのモードの重要な機能は何ですか? (または、お勧めの Emacs 用のその他の Python モード。) 詳細な回答を提供してください。

4

2 に答える 2

22

私はかつて python-mode.el のユーザーでしたが、開発方法がうまく整理されていないと感じたため、1 年前に使用をやめました。その時のメモの一覧です。ただ、あれから1年近く経っていますので、状況が変わる可能性があることをご承知おきください。

  1. 多くのコピー＆ペースト機能。
  2. 多くの誤って動作するコード。たとえば、変数を渡すのではなく、暗黙のバインディングを使用します。これにより、多くのコンパイル エラーが発生します (また、レキシカル スコープに変更すると機能しなくなります)。
  3. コミットの大まかな粒度。パッチを送ったところ、無関係な変更がコミットされていました。

python-mode.el で気に入っていることの 1 つは、自動化されたテスト セットが付属していることです (実行したことはありませんが)。python.el にはまだテスト セットがありません。しかし、python.el の作成者が現在それを書いていることは知っています。

python.el はコンパクトですが、機能が低下するわけではありません。それは、コアを小さく保ち、簡潔な API を提供することで他の人がそれを拡張できるようにするようなものです。python.el の同じ作成者が、django プロジェクト用に python.el を拡張するためにpython-django.elを作成しました。Jedi.elと呼ばれる Python 用のオートコンプリート プラグインとEINと呼ばれる高度な IPython プラグインを作成しました。どちらも python-mode.el よりも python.el のサポートが優れています (まあ、それは私が python-mode.el を使用していないからです)。

最初に python-mode.el で見逃していたことがいくつかありましたが、それらは python.el ですぐに修正されました (もちろん、これはおそらく python-mode.el であまり機能を使用していなかったことを意味します)。

シェル バッファでの補完、ソース ファイル バッファでの補完、自動インデント、再インデントなどについてはどうですか。

  • シェル バッファでの補完: python.el と python-mode.el の両方で動作します。ただし、Emacs のバージョンと python(-mode).el のバージョンの組み合わせが悪いとうまくいかないことがあります。したがって、おそらく python.el はこの方法でより安全です。しかし、より良い解決策が必要な場合は、EINを使用してください:)

  • ソース ファイル バッファでの補完: Jedi.elを使用するだけです:)

  • autoindent/reindent: どちらがパフォーマンス的に優れているかわかりません。ただし、return のキーバインドはそれぞれ異なります。python-mode.el で RET を入力すると autoindent になります。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 シェルを介して並列に実行または実行することが容易になります。

必要なキーストロークの数を減らし、調整されたコマンドを提供します。編集を高速化し、音声によるプログラミングを支援し、マクロ主導の入力などを行います。

現在 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. 新しい機能を開始するとき、選択したパスが実りあるものかどうかは明らかではありません。100回ほどコミットしようとした後でも、それは不可能であるか、あまりお勧めできないことが判明する可能性があります. すべての蛇行を投稿する代わりに、これらの場合にその実験的なブランチを数日間保持し、テストが合格したときにチェックインするために使用されます。

ところで、tkf はコンパイル エラー (すぐに検索される) ではなく、コンパイラの警告を参照していると仮定します。残念ながら、Emacs は、サポートされたスタイル設定に関する警告と実際のエラーを混在させます。

于 2013-04-02T10:01:09.183 に答える