🚀 go-pugleaf

今井です。
もう一通メールをいただきましたので
ニュースに流します。

On Fri, 08 Jun 2001 15:36:00 +0900,
Seiichi Namba <sn@asahi-net.email.ne.jp> wrote:

> --------
> 難波です。
> 
> In message <20010608132708A.hidepin@infonets.hiroshima-u.ac.jp>,
>    IMAI Hidetoshi writes:
> > 今井です。
> > いろいろ考えて下さってありがとうございます。
> > この内容のニュースはまだ、私のところに届いていませんでした。
> > この返信と同じものをニュースにも流しておきます。
> 
> ニュースの方はまだ到着していないようなので直接返信しておきます。
> 


この内容もニュースに流しておきます。
他にも悩んでいる人がいれば僕みたいに大変役に立つと思います。


> > ためしてみましたが、スクロールさせるとかなりの確率で
> > windowの中央までジャンプしてしまいます。
> 
> 「かなりの確率で」というと、うまくいくことの方が多い、ということですか。


ごくたまにうまく行くだけで、ほとんどの場合はwindowの中央にカー
ソルが移動します。


> 
> その後調べてみたところ、
> 
> (move-to-window-line -1)
> 
> などと呼ぶと、この関数は実際にそのウィンドウが表示している正味の行数
> (emacs-21 の場合は画面端で半行表示されている行数は含まない)を返している
> ことに気が付きました。そこで、次のようにしたらどうですか
> (goddamn-emacs-get-window-height を使うのと同趣ですが少し簡単にしただけ)。
> 
> (defun smooth-scroll-up (arg) ;; もうこのコマンド名は適当ではありませんね。
>   "Moves cursor down keeping cursor within 1/3 to 2/3 area of current window.
> Scroll the window in need.
> It's convenient to bind this command to down arrow key."
>   (interactive "p")  ;; xemacs では (interactive "_p") とする。
>   (let* ((height (save-excursion (move-to-window-line -1)))
>          (parity (% height 2))
>          (top-edge 0)
>          (btm-edge height)
>          (c-line (current-line-in-window))
>          (bob-not-shown                         ;; var. to duck ding.
>           (not (pos-visible-in-window-p (point-min)))))
>     (if
>         ;; Case cursor is within central area:
>         (or (and (> arg 0)
>                  (<= c-line btm-edge)
>                  (< (- btm-edge c-line) arg))
>             (and (< arg 0)
>                  (>= c-line top-edge)
>                  ;;(< (- c-line top-edge) (- arg)) ;; old code for next line.
>                  (> (- top-edge c-line)  arg)
>                  bob-not-shown))
>         (scroll-up arg)
>       ;; else if cursor is in peripheral area:
>       ;; re-calibrating cursor to central area.
>       (progn
>         (if (and (> arg 0)
>                  (> c-line btm-edge))
>             (scroll-up (+ arg (- c-line btm-edge))))
>         (if (and (< arg 0)
>                  (< c-line top-edge)
>                  bob-not-shown)
>             (scroll-up (+ arg (- c-line top-edge))))))
>     (line-move arg)
>     (setq this-command 'next-line)))
> 
> これだと、emacs-21 の場合は、行間の設定によっては画面下に１行余して
> スクロールする時がありますが、半画面スクロールは起きません。
> 
> なお、あらかじめ (move-to-window-line -1) を評価して、ウィンドウの表示
> 行数の数字としてそれらしい値が返っているかどうかは確認してください。
> xemacs でも同じかどうかよく判らないので（もしそうでなければ、
> 先のメール、本メールで書いている方法は使えません）。
> 


(move-to-window-line -1)
これは xemacs でも使えました。


> で、「確率」の話ですが、
> このやり方では、 (btm-edge (- height 1)) のように、もっと余裕を
> 持たせておく位しか対処の方法がありません。つまり、
> 
> > 動きを目で見る限り、一番上もしくは下の行が半行しか表示されて
> > いないときにカーソルが中央までジャンプするみたいです。
> > もしかしたら、簡単な解決方法は、windowの大きさ、もしくは文字の
> > 大きさ行間を pixel単位で変更して半行表示されないようにすればい
> > いのかもしれません。
> 
> 今のアルゴリズムでは（たとえば）端が半行表示かどうかを見ていないので。
> ここまで計算に入れるのであれば、pixel 単位で事を運ぶしか方法がないでしょ
> う。また、お話の様子ではemacs-21 と xemacs では、C-n (デフォルトの 
> next-line)で画面端の半行表示に入った時の挙動が違うような感じがしますね。
> emacs-21 では半行だけスクロールアップしてその行が全部表示され、そこで
> もう１度 C-n した時初めて半画面スクロールが起きます。
> 
> 今の smooth-scroll-up の枠組みを利用するのであれば、また「かなりの確率で」
> 起きる、というか、たまにしか起きない半画面スクロールを防止するのであれば、
> 
> (btm-edge (- height 1))
> 
> のように小さめにとっておくしか無いでしょう。半画面スクロールで眼が追い
> つかなくなる、という事は少なくともなくなるので、この位で我慢しておいた
> らどうですか。


いろいろためした結果
------------------------------------------------------------
(top-edge 0)
(btm-edge height)
------------------------------------------------------------
では、かなりの確率で(下にスクロールする場合はほとんど)
windowの中央にカーソルが飛んでしまいます。

------------------------------------------------------------
(top-edge 1)
(btm-edge (- height 2))
------------------------------------------------------------

私の環境では、今のところ上のように変更することで
中央に飛ばずにスクロールしてくれます。

＃ いろいろためして見たのですが newline を行ったときも
＃ カーソルが中央に飛んでしまいます。
＃ 少し気持ち悪いですが、なにかを書き加えるときはこの方が
＃ 便利かも知れません。


> 
> あるいはカーソルが画面の端まで行きませんが、私の smooth-scroll-up をそ
> のままお使いいただくのでも、半画面スクロールは絶対に起きないはずです
> (行間を極端に大きくしない限り)。
>


実は、この smooth-scroll-up/down でも結構快適に使えています。
しかし、今回の変更で希望にかなり近づいたので
変更後の smooth-scroll-up/down を使用しようと思います。 


> もっと手を抜くのであれば、(scroll-step 1) だけで、たまに起きてしまう
> 半画面スクロールは我慢する、というのでもいいかもしれない。
> 


実際使ってみるとたまに違う動きをされると
かなり気になると思います。


> もし、これでは我慢がならん、ということであれば、pixel 単位の計算をし、
> ということはフォントの高さなども計算し、さらに半行表示を検出し、それを
> 補正し、pixel 単位で scroll させるコマンドを書くしかありませんが、そこ
> まで血道をあげる価値があるかどうか、という気がします。
> 
> ただし、scroll-step を 1 にしても(あるいは scroll-conservatively を t 
> にしても)半画面スクロールが（たまに）起きるというのは *明らかにバグ* だと
> 思うので、xemacs/emacs の開発チームと闘争して直させる、というのはもち
> ろん解決方法としては正道だと思います。
> 


正道はどのような手順を踏めばいいものでしょうか？
この話ですと、解決方法を持っていかないと相手にされないような
気がします。
xemacs/emacs の開発チームに報告という形でれんらくをとることはできないものなのでしょうか？
(できれば、日本語で。)


> また、半画面スクロールも慣れればそうおかしなものでもありませんよ。
> （考え方を変えて）画面の真中を見てればいいのですから。
> 
> > edebugについて調べてみましたが、これは mule の関数の様でした。
> > おそらく、xemacs は debug を使うみたいです。
> 
> あれ？ xemacs のソースには edebug も付いてきているようでしたが、標準で
> は推奨されていないんでしょうかね。
> 


FreeBSD 4.3 の ports でとってきた xemacs-21.1.14.tar.gz
を調べましたが edebug はないようでした。
grep で検索すると 幾らか引っ掛かりましたが
プログラムではないようでした。

> PS1.
> (move-to-window-line -1) はバッファの終りがウィンドウの表示範囲内にある時は
> ウィンドウの行数単位の高さとは違う値を出してきます。この補正をやるべきですが
> 上の改造版 smooth-scroll-up ではそれがありません。この部分はおまかせします。
> たとえば症状としては、バッファの終りで呼ぶと、scroll-up が起きてしまう、という
> のがこの問題に該当するものと思われます。

確かに そのような動作を確認しました。
ただscroll-upより移動する行数が多いようです。
(3行くらいです。)

> 
> PS2.
> 本件に少し関連すると思いますが、C-x 3 M-x follow-mode RET というのは xemacs
> でも使えますか。C-p,C-n,C-v,M-v などの際のバッファの見せ方を調節する
> ものですが、もしかしたらご不便のうちのある部分は解消できるのかもしれません。
> 
> ともあれ、ご健闘を祈ります。

C-x 3 で window を縦に二つに分割できました。
ただ、follow-mode はないようでした。
この、モードをよぶためになにか .emacs に記述する必要は
ありますか？

今回の変更で、かなり満足できるものになりました。
普段の使用には、問題ないように思えます。
ありがとうございました。

幾らか残った問題を解決する方法があれば
またよろしくお願いします。