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

Emacsで編集しているテキストは、バッファーと呼ばれるオブジェクトにあります。ファイルにアクセスするたびに、ファイルのテキストを保持するためにバッファが使用されます。Diredを呼び出すたびに、ディレクトリリストを保持するためにバッファが使用されます。

3
開いている(表示されている)バッファー/ウィンドウのテキストを強調表示—あるバッファーから別のバッファーのテキストを検索
現在、Emacsフレームを垂直方向に分割し、2つのウィンドウで2つの異なるバッファーを表示しています。 1つのバッファ内の単語に移動し、いくつかのキーを押して、その単語(ある場合)の出現を他のバッファで強調表示し、必要に応じてその単語までスクロールします。 それを行う方法はありますか? 上のスクリーンショットでは、カーソルが左側のバッファの「bar」の直前にあるので、<何か>を実行して、右側のバッファの「bar」がどこにあるかをすばやく確認できます。 注:これは、複数の開いているバッファからテキストを検索する方法に関連していますか?その意味で、もし私が「他の」バッファを横切ってisearchを実行できたなら、それは私が望むことをするでしょう。しかし、私が望んでいる答えはまったくありません。 occur私は維持したいと思いながら、ベースのソリューションでは、ショーは行に一致することを新しいウィンドウを開いて、私の2つのウィンドウがまだ表示された-私は実際にコンテキストの他のバッファに探してするつもりだ周りにこれだけマッチラインを示し、一致あまり役に立ちません。 multi-isearch-buffersこの検索を実行するたびに(何度も)バッファのリストを指定する必要がありますが、表示された2つのバッファとして自動的に取得するのではありません。さらに重要なことは、一方のウィンドウから開始してisearchを実行すると、もう一方のバッファーで一致が見つかると、そのバッファーがこのウィンドウに表示され、両方のウィンドウに同じ(他の)バッファーが表示されます。その後、Cgはすべてを元に戻し、もう一方のバッファーで強調表示された単語が見えなくなります。 icicle-search には非常に多くの機能があり、そのうちの1つでこれを実行できる可能性がありますが、ドキュメントをざっと見てみても何も見つかりませんでした。
8 buffers  search 

2
ファイルをすばやくプレビュー
この質問と同様に、カーソルをファイルの上に置くだけでツール/マイナーモードでファイルをすばやくプレビューできます(たとえば、現在選択されているファイルがアクティブなバッファーウィンドウに表示されます)。憂鬱な出来事は気にせず、オーバーレイもしたくない。選択されている場合は、アクティブウィンドウに表示します。Enterキーを押してバッファに切り替えるのが遅すぎるため、生データファイルの束をざっと見ることができません。どうすればこれができますか?



2
現在のカーソル以外のバッファーでカーソルを永続的に移動するにはどうすればよいですか?
注意:`with-current-buffer`と` goto-char`を使用して、ポイントを別のバッファーの末尾に移動する方法は?おそらくこれと同じ質問をしますが、それに与えられた答えは、ここでの私のケースにはすぐには当てはまりません。たとえば、他のバッファにテキストを挿入するなどの答えがあります。ここで私が尋ねる質問はかなり単純で、それに対応する答えも単純であるべきだと思います。 仮定 Emacsフレームは2つのウィンドウに分割され、一方のウィンドウは呼び出されたバッファーを保持し*whatever*、もう一方のウィンドウは標準*scratch*バッファーを保持します。 *whatever*バッファは、数行のテキストが含まれています。 *whatever*バッファ内のカーソルは、そのバッファの先頭(つまり、その(point-min))にあります。 *scratch*バッファが現在のものです。 *scratch*バッファーで次のいずれかを評価した場合、*whatever*バッファー内のカーソルの位置は変更されません。 (with-current-buffer "*whatever*" (goto-char (point-max))) (with-current-buffer "*whatever*" (end-of-buffer)) (save-excursion (set-buffer "*whatever*") (goto-char (point-max))) (save-excursion (set-buffer "*whatever*") (end-of-buffer)) 私は何でも、それを理解(goto-char (point-max))たり(end-of-buffer)しない*whatever*のカーソルの位置が、その後破棄されます。 上記のスニペットを変更して、*whatever*バッファーのカーソルがそのバッファーの末尾に(永続的に)配置されるようにする方法を教えてください。 Emacsのドキュメントを使用してこの質問に自分で回答するにはどうすればよいですか?思いつく限りのことを試しました。 ジュール・タマグナンの明快な答えを読んだ後、私はさらに明確に規定する必要があることに気づきました: 問題のバッファがウィンドウに表示されているかどうかに関係なく機能する解決策を探しています。 I緩衝表示する場合、すべての後、BをウィンドウにW、特定の位置にカーソルを移動Lは、いくつかの他の緩衝視聴C同じウィンドウにWを、そして最終的に指し示すWバッファへ戻るBを、Iは、でカーソルを見ることを期待します私が去ったのと同じ場所L IOW、バッファがウィンドウに関連付けられているかどうかに関係なく、バッファのポイントがどこにあるかを覚えておく方法が必要です。 ターゲットバッファーが現在2つ以上のウィンドウ(W1、W2、W3、...)に表示されている場合はどうですか?このケースには多くの合理的な可能性があります。提案された解決策は、たとえば、カーソルの位置を変更することができます W1、W2、W3、...の間で最近アクティブなウィンドウ 内のすべてのウィンドウW1、W2、W3、...; または などなど (実際には非常にまれであることを期待しているので、私はこのコーナーケースについて強い意見はありません。)

3
内容の異なる複数の* Help *バッファーを使用するにはどうすればよいですか?
を使用してC-h f、C-h v役立つヘルプを表示します。情報を比較したいときがあります。そのため*Help*、内容が異なる複数のバッファを同時に表示できると便利です。 ただし、ショートカットを使用すると、常に*Help*バッファの内容が上書きされます。 複数のヘルプ(*Help*)バッファーを同時に開く方法は?
7 buffers  help 

2
フォルダを削除するときに常にdiredバッファを殺す方法は?
diredで、サブフォルダーに別のdiredバッファー(ディレクトリを上下に移動するときの一般的な状況)があり、フォルダーを削除したい場合は、を押して削除のDxマークを付けてから実行します。 次に、Emacsがフォルダーをゴミ箱に移動するかどうかを尋ねます。確認すると、フォルダのdiredバッファも削除するかどうかを尋ねられます。 フォルダーを破棄してバッファーを保持したい状況は考えられません。フォルダを破棄するときに常にバッファを破棄する方法はありますか?
7 buffers  dired 

1
ポイントの最後の場所をバッファに保存する方法は?
私が訪問しているバッファのポイントの最後の位置を保存したいので、そのファイルに戻ったときにポイントがまだそこにあります。 私saveplaceはこれに使用できることを理解しているので、このスニペットを構成に追加しました: (use-package saveplace ; Save point position in files :init (progn (setq-default save-place t) (toggle-save-place-globally))) それでも、望ましい動作が得られません。ポイントはまだバッファの先頭にあります。 Emacs 25.0.50.1(45c92dd)を使用していますが、でも同じことが起こりemacs -Qます。
7 buffers  point 

2
セッション間で開いているファイルリストとバッファコマンド履歴を保存する
私が発見したdesktop-save-modeEmacsが閉じることができ、それが再オープンしたときに、それは前に開いていた同じファイルが表示されています。 これをもう少し詳しく説明したいのですが、次のこともできるかどうか考えていました。 で開いたファイルの履歴を保存しますC-x C-f。私はしばしば同じファイルを開くことになるので、それらを簡単に見つけるのは素晴らしいことです。これを保存できない場合は、ブックマークが役立つでしょう。 M-xまたはを介して実行されたバッファコマンドの履歴を保存しますM-:。これは可能ですか?できない場合は、これを行うためにいくつかのスニペットを保持できますか? 前もって感謝します!
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.