ウィンドウがスクロールしたときに `window-end`を得る方法は？

Question

ウィンドウがスクロールしたときに `window-end`を得る方法は？

window-end 関数のドキュメントから：

updateがnilでなくても、ポイントがスクリーンから外れた場合、実際の再表示のやり方は変わりません。ウィンドウ開始値は変更されません。実際には、スクロールが不要な場合に、表示されるテキストがどこで終了するかを報告します。

window-end は、スクロールが必要ない場合に表示されるテキストがどこで終了するかを報告するだけなので、正しい window-end >現在のウィンドウの最後に next-line を呼び出した後、ウィンドウが1行スクロールされますか？ window-end 関数を呼び出す前にウィンドウを強制的に再表示する必要がありますか？

3

追加された 27 2月 2016 〜で 01:19 著者 cutejumper 編集された 13 3月 2016 〜で 11:57

ビュー: 8

源

ro ru fr es pt de zh hi bn ar uz tr

IIUCではできません（ただし、再表示を強制的に（例えば（再表示）などで強制することを除いては）ことはできません。より良い答え。

追加された 27 2月 2016 〜で 04:39, 著者 sds, 源

私は "何らかの機能"が何であるか分からず、また、なぜウィンドウ開始/終了を知る必要があるのかわからず、次の行の実行中になぜそれが必要なのかも分かりません。

追加された 27 2月 2016 〜で 10:45, 著者 sds, 源

その後、ウィンドウの開始と終了を知る必要はありません。代わりに、表示されるバッファのすべての部分で呼び出される fontification-functions を使用します。通常、これは直接使用されるのではなく、代わりに jit-lock-register によって行われます。

追加された 29 2月 2016 〜で 01:41, 著者 sds, 源

例については、nlinum-mode（GNU ELPA）を参照してください。

追加された 01 3月 2016 〜で 03:44, 著者 sds, 源

@Stefan私はいくつかの機能を実装しようとしていますその包み。問題は、すべての表示行を取得するには最新の window-start と window-end を知る必要がありますが、 next-line はウィンドウをスクロールさせますが、これらのウィンドウの境界は正しくありません。

追加された 27 2月 2016 〜で 09:06, 著者 Mahesh, 源

@Stefan私は jit-lock-register を使ってみることはできません。パラメータを出力するだけのシンプルな関数を登録した後は、 next-line を使ってウィンドウをスクロールするときに呼び出されないようです。あなたはそれを利用するいくつかのコードを指摘できますか？ EDIT：バッファに最初にアクセスしたときに、さまざまなパラメータで複数回呼び出されます。

追加された 01 3月 2016 〜で 03:06, 著者 Mahesh, 源

視覚的な線にラベルを付けるので、 window-start と window-end を知る必要があります。 次の行でウィンドウがスクロールすると、視線が変更されるため、オーバーレイを適宜変更する必要があります。

追加された 27 2月 2016 〜で 11:07, 著者 Mahesh, 源

1 答え

著者 lawlist · Answer 1 · 2016-02-27T07:08Z

window-end 関数を使用すると、再表示を強制することなく または Cソースコードを変更せずに window-scroll-functions フックは https://www.gnu.org/software/emacs /manual/html_node/elisp/Window-Hooks.html#Window-Hooks [注記：再表示を強制すると、目に見えない（2番目の分割のために）未完成の商品が表示されることがあります。たとえば、新しいオーバーレイにはまだ削除/配置されていません。]

CAVEAT: Beware that the window-scroll-functions hook fires sometimes more than once during each command loop (while redisplay performs its job), and the first values for window-start and window-end win t are not always correct, and the last values are not always correct either -- e.g., when inserting/yanking, or when using goto. [Fn 1.] When the window-scroll-functions hook runs multiple times, the function attached to the hook can cause significant performance issues depending upon the complexity of said function. And, as mentioned, sometimes the user is simply out of luck -- i.e., correct values can never be obtained. Using pos-visible-in-window-p can be helpful as a workaround to set up some checks to prevent the function attached to the hook from fully running its course if point is not yet fully visible; and, a variable can be set up to test for whether the function has already fully run one time during that command loop (so that it doesn't keep running).

私は自分の個人設定で正しい window-start と window-end を得るために使っているCソースコードに、 em>中を再表示します。しかし、私はプログラマーではなく、本当に動機づけられている唯一の人なので、それは決して主流に進まないかもしれません。 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22404 これは window-start-end-hook と呼ばれます。しかし、それはユーザがパッチのドラフトを試してソースからEmacsをビルドしたい場合にのみ利用可能です。私のドラフトパッチは、ウインドウのスクロールにかかわらず動作します。例えば、可視ウィンドウ内でポイントを動かすと動作します。 goto を使用するときに機能します。それは挿入/ヤンクするときに機能します。スクロールするときに機能します。そのコンセプトを開発することに興味がある人は、機能要求22404への投稿を自由にお寄せください。

関連するスレッドも参照してください。

再表示を呼び出さずにウィンドウ開始を更新する方法

https://stackoverflow.com/questions/23923371/ emacs-calculated-new-window-start-end-without-redisplay/24216247＃24216247

NOTE: Debugging functions that run during redisplay may require using a feature called trace-redisplay (after launching Emacs from the command line) that is available when building Emacs from source with options such as: ./configure --enable-checking='glyphs'.

[Fn. 1.]: When working with Bug #22637, Eli Z. on the Emacs development team explained that the reason the window-scroll-functions hook does not yield correct results for inserting/yanking or goto is because it was never designed for those scenarios: "The reason window-scroll-functions aren't run in both of these test cases is that what happens there is not considered 'scrolling'. Scrolling is informally defined as either an explicit call to a function that scrolls the window, or a pseudo-scroll done by the display engine when it detects that some part of the window's previous display is still present, but in a different vertical position. Moving point to an arbitrary location is neither." https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22637#35

3

追加された 27 2月 2016 〜で 07:08 著者 lawlist

源

正直言って、これを解決するには簡単で簡単な方法があるはずですが、Emacsはそれを提供するべきです。私は、この問題がどれほど複雑であるかを見て驚いています。だから私はまたそれを開いたままにします。あなたの答えとこの問題を解決するあなたの努力に感謝します。

追加された 27 2月 2016 〜で 10:34, 著者 Mahesh, 源

ありがとう！私はEmacsの再表示コードが本当に複雑であると聞いてきました。とにかく、あなたの記事と@ abo-aboのコメントは、関連するスレッドでは一時的な回避策のヒントを与えてくれます。私はそれをそのまま残すか、それとも解決しなければならないのでしょうか？他の誰かが同様の問題を抱えているかもしれません。

追加された 27 2月 2016 〜で 10:25, 著者 Mahesh, 源

redisplay の前に window-start と window-end を実行する理由を聞かせてもよろしいですか？ window-start と window-end は、 redisplay によって決定される現在の視覚領域に依存するはずです。視覚的な領域が決まる前に彼らが実際に戻ってくるのはなぜですか？（私はEmacs内部の魔法を知らない...）

追加された 27 2月 2016 〜で 10:06, 著者 Mahesh, 源

開発者の視点からは、この問題を阻止しようとしているものが何であるかはわかりません。 window-start と window-end は、常に正しい値を返すことが期待できます。あなたが言及した方法と@ abo-aboのアプローチを試してみましょう。

追加された 27 2月 2016 〜で 09:53, 著者 Mahesh, 源

私は@ abo-aboがすでに似たような質問をしていることに気づいていません！基本的に私は彼と同じ質問があります。私はそのスレッドであなたのポストを読んできましたが、それはまだエレガントな解決策がないようです。 window-start-end-hook は良いですが、機能リクエストをどのように進めることができますか？

追加された 27 2月 2016 〜で 09:15, 著者 Mahesh, 源

同時にEli Zに電子メールを送信する以外に、あなたの意見を表明する22404という機能もありますが、その機能を実現するために他に何ができるのか分かりません。ジョンはバグの電子メールをすべて読むので直接カーボンコピーする必要はないと言った。 [最新の出来事を定期的に熟読していないので気にしないなら、22404の関連する電子メールのカーボンコピーを受け取っていただければ幸いです。]

追加された 27 2月 2016 〜で 09:37, 著者 lawlist, 源

ポイントが完全に見えるときに window-start-end-hook が完全に起動します（つまり、すべてのコードが実行されます）が、ポイントがあるときに完全に起動できるように部分的に見える。いくつかのユーザは、部分的に可視の能力を望むかもしれません。 nil に設定できる組み込み変数 make-cursor-line-fully-visible デフォルト値は t です。言い換えれば、私の草案の概念は最終的な製品ではありません（まだTLCを使用することができます）。しかし、私は自分のセットアップで数週間それを使用しており、とても満足しています。

追加された 27 2月 2016 〜で 09:49, 著者 lawlist, 源

Eli Z.は、ユーザーがLispを再表示に導入することでEmacsがハングしたりクラッシュする可能性があることを懸念しています。しかし、私は、再表示中にエラーがあった場合にLisp関数がキャンセルされるため、私が心配していると思う safe_call を使用するように私に指示しました。 Eli Z.は提案された post-redisplay-hook と呼ばれる最終的なフックを好むだろう。しかし、私は、レイアウトを変更する（例えば、ポイントを移動する、またはフォントサイズを大きくする）Lispを導入することを許可し、再表示して暫定結果を再確認し、必要に応じてより多くの作業を行うことができるため、

追加された 27 2月 2016 〜で 09:34, 著者 lawlist, 源

問題は、 window-start と window-end の新しい値が最終的にどのようなものになるかを再表示することです。 redisplay の前に実行される window-start や window-end などの関数は、それでもまだ不明であるか不明な点があります）、再表示の最後に解決策が必要です。 [再表示中にLispエラーメッセージが表示されないので、デバッグに trace-redisplay のようなものが必要です。

追加された 27 2月 2016 〜で 09:58, 著者 lawlist, 源

例えば、 window-scroll-functions フックと pre-redisplay-function には、ディスプレイを変更する機能、 /フォントサイズを小さくする。したがって、再表示は新しい window-start と window-end が最終的にどのようなものになるかを理解するために追加作業を行う必要があります。新しいドラフトの概念 window-start-end-hook には、ポイントを移動したり、フォントのサイズを増減させる関数を含めることができ、 window-start および window-end 通常のLisp関数はすべて、再表示が始まる前に実行されます。

追加された 27 2月 2016 〜で 10:11, 著者 lawlist, 源

Emacsが何をしているのか理由に関して、私は自分の新しいEmacsの機能を実装する主な目的のためにCの言語を学び始めたプログラミング趣味者（トレードではない）です。 Emacs開発チームの新機能や変更点を提案しました。しかし、明らかに、 window-start-end-hook や post-redisplay-hook のようなものが必要です。

追加された 27 2月 2016 〜で 10:14, 著者 lawlist, 源

私はこの問題に注目しています。これは私の情熱です。あなたがそれを解決した印を付けると、人々は興味を失うでしょう。 abo-aboは、彼が答えに満足していないか、新しい機能を望んでいたか、またはこの問題にもっと注意を欲しがっていたかのいずれかの理由から、おそらく質問を開いたままにしました。私の個人的な好みは、この質問を受け入れられた答えを持たないものとして残し、注意を引くことです。しかし、その決定はあなたのものです。それはあなたの質問です。あなたは、満足のいく解決策があるかどうかに関して究極の発言をしています。私はチェックマークを受け取ることを急いでいない:)

追加された 27 2月 2016 〜で 10:28, 著者 lawlist, 源