30

私は最近、emacs で python ファイルを編集python-mode.elするpython.elために から に切り替えようとしましたが、その経験は少し異質で非生産的であることがわかり、急いで戻ってきました。python-mode.el10年くらい使っているので、少し慣れてきたのかもしれません。2 つのモードを注意深く評価した人、特にそれぞれの長所と短所、およびpython.el.

私にとっての2つの大きな問題python.elは

  1. Python ファイルにアクセスする各バッファは、独自の下位の対話型 Python シェルを取得します。私は、1 つの対話型シェルで開発を行い、Python ファイル間でデータを共有することに慣れています。(ソフトウェア エンジニアリングの観点からは悪い習慣のように思えるかもしれませんが、私は通常、メモリにロードするのに時間がかかる巨大なデータセットを扱っています。)

  2. python.el でのスケルトン モードのサポートは、まったく無意味 (python の構文ではそのような自動化は不要) であり、設計が不適切 (たとえば、" for" ループ ジェネレーター式または " <expr 1> if <cond> else <expr 2>" 式の知識がないため、元に戻す必要がある) のように見えました。そして、ミニバッファーに式句を入力するように要求した後に挿入されたコロンを削除します。) これをオフにする方法がわかりませんでした。これを制御すると主張する変数がありましたが、python.el機能していないようです。私が使用していた のバージョンpython.elが壊れていた可能性があります (debian emacs-snapshot パッケージに由来する) ので、誰かが最新バージョンを知っている場合は、それについて聞きたいです。(約 2 週間前の CVS emacs のバージョンでも同じ問題がありました。

4

6 に答える 6

4

価値があるのは、問題＃1で見られる動作が見られないことです。「Pythonファイルにアクセスする各バッファは、独自の劣ったインタラクティブなPythonシェルを取得します。」

これは、Emacs 22.2 の python.el を使用して行ったことです。

Cx Cf foo.py [挿入: print "foo"]

Cx Cf bar.py [挿入: print "bar"]

Cc Cz [*Python* バッファが表示されます]

Cxo

Cc Cl RET ["バー" は *Python* で出力されます]

Cx b foo.py RET

Cc Cl RET ["foo" は同じ *Python* バッファーに出力されます]

したがって、2 つのファイルは同じ下位の python シェルを共有しています。おそらく、python-mode の個人的なカスタマイズと python.el のデフォルトの動作との間に予期しない相互作用が発生する可能性があります。.emacs のカスタマイズなしで python.el を使用して、同じように動作するかどうかを確認しましたか?

python-mode に対する python.el の主な機能追加は、シンボル補完関数 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 ファイル バッファでも動作します。

于 2008-12-15T15:34:00.567 に答える
3

  1. Emacs v23.1 でこの動作を再現することはできません。これはその後変更されたに違いありません。

  2. どのモードのスケルトン サポートも忘れて、代わりに非常に高度で拡張可能なyasnippetを使用してください。試してみる価値があります。

于 2010-03-31T15:24:02.107 に答える
2

物事が変化するにつれて、ここで述べられているほとんどすべてが時代遅れになっていることに注意してください。

python-mode.el コマンドには基本的に「py-」というプレフィックスが付いています。どちらが最初にロードされたかに関係なく、両方のコマンドを使用できるはずです。

python-mode.el は python.el をアンロードしません。再定義された python-mode-map の横にあります。

差分は表示されるメニューとキー設定にありますが、最後にロードされたものが決定されます。

于 2012-11-07T10:21:47.263 に答える
1

python-mode.elはPythonコミュニティによって書かれています。python.elはemacsコミュニティによって書かれています。私は覚えている限りpython-mode.elを使用してきましたが、python.elはpython-mode.elの標準にさえ近づいていません。私はPythonコミュニティがEmacsコミュニティよりもまともなモードファイルを考え出すことを信頼しています。python-mode.elに固執するだけですが、本当にそうしない理由はありますか？

于 2008-12-12T12:20:43.240 に答える
1

python-mode.el は三重引用符で囲まれた文字列をサポートしていないため、プログラムに長いドキュメント文字列が含まれていると、すべての構文の色付け (および関連する構文機能) が機能しなくなる傾向があります。

私の.02

于 2009-06-17T07:08:48.227 に答える
0

残念ながら、Debian は python-mode パッケージを削除してしまったので、python.el を試すしかないと感じました。それを読み込んで「describe-bindings」を実行しました。c-X ;これは、Python コードの行にコメントを付けるための直感的なバインドであると考える elisp コーダー向けに設計されているようです。(うわー。) また、コードの領域にコメントを付ける方法がまったく見つかりませんでした。むしろ、文字列「領域」と「コメント」とのバインディングがありませんでした。

古き良き python-mode は、git clone https://gitlab.com/python-mode-devs/python-mode.git. この記事を書いている時点で最後に編集されたのは 1 週間前なので、放棄されていないと考えて間違いありません。

于 2022-03-03T20:53:26.747 に答える