タグ付けされた質問 「comint」

まず、免責事項。私はこれを何度も研究しました、そして、私はすでに何らかの方法で答えをすでに見つけたと確信していますが、私はそれを理解しません。 私の問題は次のとおりです。 comintを実行しているプロセスがあります 入力行を送信し、出力をキャプチャして、それが終了したとき（出力の最後の行がプロンプトの正規表現に一致したとき）を確認したい プロセスが出力の送信を完了したときにのみ、別の入力行を送信したい（たとえば）。 少しの背景として、プログラムとの対話を実装するメジャーモードを考えてください。プログラムは、任意の時間で任意の量の出力を返す可能性があります。これは異常な状況ではありませんよね？さて、 入力間で待機する必要がある部分は珍しいかもしれませんが、入力全体を送信するよりもいくつかの利点があります。 出力バッファはきれいにフォーマットされています：入力出力入力出力... さらに重要なことは、プロセスに大量のテキストを送信する場合、テキストは断片に分割され、その断片はプロセスによって貼り付けられます。切断ポイントは任意であり、これにより無効な入力が行われることがあります（たとえば、プロセスは識別子の途中で入力カットを正しく貼り付けません） とにかく、珍しいかどうかにかかわらず、それは複雑であることがわかります。今、私はの線に沿って何かを使用しています (defun mymode--wait-for-output () (let ((buffer (mymode-get-buffer))) (with-current-buffer buffer (goto-char (point-max)) (forward-line 0) (while (not (mymode-looking-at-prompt)) (accept-process-output nil 0.001) (redisplay) (goto-char (point-max)) (forward-line 0)) (end-of-line)))) 入力ラインを送信した後、次のラインを送信する前に毎回これを呼び出します。まあ...それは動作します、それはすでに何かです。 ただし、出力を待機しているときにemacsがハングすることもあります。その理由は明らかでありsleep-for、ループに何らかの非同期（たとえば1）を含めると、出力は1秒遅延しますが、ハングは抑制されると考えました。この種の非同期sleep-for は存在しないように見えることを除いて 。 それともそうですか？より一般的には、emacsでこれを達成する慣用的な方法はありますか？言い換えると： プロセスに入力を送信し、出力を待ってから、さらに入力を非同期に送信する方法は？ 周りを検索するとき（関連する質問を参照）、主にセンチネル（プロセスが終了しないため、私の場合には当てはまらないと思います）といくつかのcomintフック（しかし、何をすべきですか？フックをバッファローカルにし、「残りの行を評価する」を関数に変え、この関数をフックに追加し、その後フックをきれいにしますか？それは本当に汚いですね？） 自分自身を明確にしない場合、またはどこかで利用可能な明らかな答えがある場合、プロセスの相互作用のすべての複雑さに本当に混乱しています。 必要に応じて、これをすべて実用的な例にすることができますが、以前に見つけて助けにならなかったすべてのような「特定のプロセスの答えを持つ特定のプロセスの質問」をもう1つ作成するだけです。 SOに関するいくつかの関連する質問： /programming//q/16815598/1083706 /programming//q/3572532/1083706 /programming//q/6578373/1083706

12 subprocess  comint  async 

ソースブロックをもつれさせながらSTDINからユーザー入力を読み取ることはできますorg-babel-tangleか？ 私はこれを知っています：Org Mode Babel-インタラクティブコードブロックの評価。 それは助けには、それはまだシェルから適切なSTDIN入力を許可しないように、この特定のユースケースを解決しますが、限られた入力をシミュレートしていない内部のEmacsに。 バックグラウンド OrgのBabelを使用して、1つのorgファイルからいくつかのチュートリアルを実行することにより、新しいプログラミング言語（PerlとBash）を学びたいと思います。 問題は、多くのチュートリアルがSTDINに依存していることです。たとえば、次のperl tidbitを実行するとします。 #+BEGIN_SRC perl :tangle hello-name.pl :results output :export code use 5.010; use strict; use warnings; say "What is your name?"; my $name=<STDIN>; say "Hello $name, how are you?"; #+END_SRC EmacsはユーザーのインタラクションがSTDINに名前を正しく入力するのを待たず、すぐに出力します： #+RESULTS: : What is your name? : Hello , how are you? …

10 org-mode  org-babel  shell  interactive  comint 

明確にするために、私はemacsをマルチスレッド化する必要のあることについては何も話していません（おそらくこれも解決されるでしょう）。再現するには： emacs -Q＃24.4.1を実行しています 2番目のフレームを作成する 最初のフレームに戻る MXシェル Mx rename-uniquely（後で2番目のシェルを作成します） 実行を開始： while true; do echo "hello world"; done 2番目のフレームでは、Mxシェル 2番目のシェルが表示されることはほとんどありません（まれに繰り返し試行しても機能します）。どうやらemacsは、最初のシェルの出力を読み取って他のプロセスからの出力をリッスンすることを決して中断しません。保留中の出力を持つ複数のプロセスがある場合、ラウンドロビンの方がはるかに良い動作になります。より良い行動をとる方法はありますか？ 私が知っている唯一のトリックは、シェルバッファーを独自のプロセスにすることですが、残念ながらそれは私にはうまくいきません。それを行ったとしても、音声認識ソフトウェアが機能するようにソケットをリッスンするサブプロセスを実行する必要があります。そうすれば、シェルを最初に実際に制御できるようになります。これが、私がこれを発見した方法です。上記のような無限ループを実行すると、データがソケットから取り出されなくなります。

10 shell  comint  subprocess 

*ielm*セッション間のバッファーの履歴をEmacsに記憶させることができません。私の知る限り、そのような履歴はバッファローカル変数に記録されますcomint-input-ring。したがって、私は私のinitファイルに次の式を追加しました： (setq desktop-locals-to-save (append desktop-locals-to-save '((comint-input-ring . 50)))) 動作しません。desktopEmacsがdesktop-globals-to-saveinitファイルに追加したグローバル変数を記憶しているため、パッケージが機能していることがわかります。 - 編集：savehistどちらも機能しません。それはcomint-input-ringバッファローカル変数だからだと思います。

9 comint  desktop  history-variables 

私はファイル内のいくつかのプログラム、特にこの例ではdirenvを取得shell-commandしasync-shell-commandてシームレスに統合しようとしてい.bashrcます。 をカスタマイズした場合shell-command-switch、通常のインタラクティブログインシェルであるかのように、シェルプロセスでプロファイルをロードできることがわかりました。 （setq shell-command-switch（purecopy "-ic"）） （setq explicit-bash-args '（ "-ic" "export EMACS =; stty echo; bash"）） 私はexec-path-from-shellも使用しています。 次のような~/.bashrcファイルがあるとします。 ... eval "$（direnv hook $ 0）" 「foo」をエコー 内部~/code/fooには次の.envrcファイルがあります： エクスポートPATH = $ PWD / bin：$ PATH 「バー」をエコー set to で実行するM-x shellと、bashシェルはプロファイルを正しくロードし、direnvフックを実行してパスに追加します。default-directory~/code/foo direnv：.envrcの読み込み バー direnv：エクスポート〜PATH 〜/ code / foo $ echo $ PATH / Users …

9 shell  process  comint  environment 

いくつかのカスタムcomint派生モードを記述した後、バッファーとプロセスを追跡する方法を決定するのは難しい場合があります。たとえば、異なるソースバッファーを異なるインタープリターに関連付ける場合などです。バッファまたはプロセスへの参照を保持する方が良いですか？ バッファを指定すると、関連するプロセスをを使用して見つけることができますget-buffer-process。逆に、プロセスが指定されると、process-bufferそれに関連付けられたバッファーを返します。バッファとプロセスのどちらも、一意の名前でそれらを検索することにより、間接的な追加の層を許可しますが、オブジェクト自体への参照を保持するだけに比べると、これは脆弱に見えます。 データを1回だけ格納するという原則に違反しているため、1つの可能性は明らかに悪いように見えます。つまり、バッファとプロセスの両方への参照を保持しています。 comint-入力を送信するためのほとんどの関数は、引数としてバッファではなくプロセスを受け取ります。これは、バッファではなくプロセスオブジェクトに依存することを主張します。一方、バッファはプロセスよりも長く留まる傾向があります。プロセスが終了するか強制終了され、以前使用していたバッファで新しいプロセスが開始される場合があります。 プロセスまたはそのバッファを参照するための他の説得力のある引数はありますか？

8 elisp  programming  comint