🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: fj.editor.xemacs
Article #241

Re: スクロールの挙動

#241
From: IMAI Hidetoshi
Date: Tue, 12 Jun 2001 15:59
186 lines
10065 bytes
今井です。

At 12 Jun 2001 20:17:18 +0900,
Seiichi Namba wrote:
> 
> The following message is a courtesy copy of an article
> that has been posted to fj.editor.xemacs as well.
> 
> 難波です。
> 
> > 設定して使用したのですが、bufferの最終行で my-newline を
> > 実行すると、カーソルの位置が実行する度に一段ずつ上がっていきま
> > す。(Windowの中でのカーソルの位置のことで、bufferの行数は増え
> > ています)ずっと繰り返していくと最後には1行目と2行目のどちらか
> > を行ったりきたりします。(top-edge 1のため起きていると思います。
> > )
> 
> 過激に表示範囲がジャンプする、というのが抑制できているのであれば、
> それ以上はあきらめていただくしかないのかもしれません。
> 

あまりにもこれは使いにくいので、今はmy-newlineの使用を
やめています。

> > しかし、できればxemacs本体でこのバグを直してほしいとも思ってい
> > ます。(他のアプリケーションで問題が発生するかも知れないから)
> 
> emacs-19/20/21 でも同じ問題があり、明らかにバグのように思えますね。
> 
> > 今は、チョット忙しくてできそうもないですが、時間をつくって
> > 英語でメールを書いてみようと思います。そのときには相談すると
> > 思います。よろしくお願いします。
> 
> 私など頼りにしなくても、誠意ある交渉であれば必ず相手に伝わるはずです。
> elisp の事をどれだけ知っているか、とか、英語が上手か下手か、などとは一
> 切関係がないと思いますよ。交渉の過程など知らせていただければ嬉しいですが。
> 


実は、難波さんが以前おっしゃった、xemacsの場合は

(interactive "p") → (interactive "_p")

にしないと、リージョンがうまく指定できないという
問題解決方法のことを思い出して、c-quick の中身を書き換えて使用
してみました。
すると、画面のスクロールはスムーズで、(一番最後の行までカーソ
ルはちゃんと移動する)今の所、中央に飛ぶことはないです。

これにも、気になる問題点があります。

●"newline"がないため、bufferの最終行で改行すると、画面の中央にカーソルが飛んでしまう。

●bufferの最終行で C-n (c-quick-move-down)を実行すると、カーソ
ルのWindowでの位置が一段ずつ上がっていき最終的には一番上にきて
しまう。

この二つの問題点があるのですが、これが今のところ快適に
使えることがわかりましたのでこれでしばらく過ごしてみようと
思います。

私は、c-quickのソースが結構長く、使用しない関数が多いような気
がするのでできるだけ削ろうとおもいます。
理由は、

●メモリを無駄な関数の分も使用してしまってもったいない

●起動時間が多くかかってしまう。

と思っているからです。
実際は、これらの問題は考える必要はあるのでしょうか
アドバイスお願いします。


> 
> 
> その後、
> emacs-21 で、変数設定のみで解決できないか、と少し試してみましたが(
> xemacs に同じ変数があるかどうかは確認してません)、
> 
> (progn (setq scroll-margin 0)
>        (setq scroll-step 1)
>        (setq scroll-down-aggressively 0.01)
>        (setq scroll-up-aggressively 0.01)
>        ;; (setq scroll-conservatively 8)
>        (setq scroll-conservatively 1)
>        )
> 
> などとすると半画面スクロールの起きる確率はかなり少なくなるように思いま
> した(emacs-20 などよりは良いようです)。しかし、やはり100%確実に動
> 作しているとは思えません。
> 
> また、info を見ても、これら各変数の意味や相互関係は非常に理解しがたい
> です(こんなに沢山変数がある必要があるのか? 行きあたりばったりに増設さ
> れてきたような感じがする。うまく動いてなくても不思議じゃない、かもしれ
> ませんね)。
> 


自分でこれらの関数について調べてみました。
"scroll-margin"についてですが、これは、windowの上端、下端から
何行離れていたら画面をスクロールするか設定する関数だと思います。

これは、難波さん作成された関数の"top-edge"、"btm-edge"にあたる
ものだと私は解釈しています。これと、"scroll-step"を組み合わせ
れば "smooth-scroll-up/down"と同じ動作ができると思ったのですが
"C-h a scroll-margin" を実行したところ xemacsにはこの関数が
ないようでした。"scroll-down-aggressively"
"scroll-up-aggressively"も同様にありませんでした。

"scroll-conservatively"に関しては、いくら引数を変えてもスクロー
ルの動作が変化しませんでした 。


> また emacs-21.0.103 には window-text-height という関数があり、これが実
> 際の表示行数を返すのかな、と思ったのですが、行間を変えても 
> (window-text-height) はいつも同じ行数を返しているようです
> ((1-(window-height)) の値のようだ)。
> info や apropos で捜してみても、他にはそれらしい関数はみつかりませんでした。
> 
> なお、バッファの終りが見えている時の補正を行なうために、次のようなやり
> 方も試してみました。scroll-step == 1 相当の動作としてはこれが今のとこ
> ろ最も動作の信頼性があるようですが、コメントにあるように 
> special-display-frame-alist (これも xemacs にあるかどうか知らない)に登
> 録されている frame の場合は信頼性が落ちます。また、行間が 0 以外の時は
> 多少誤動作が増えるようです。
> 
> (defsubst basic-get-real-window-height ()
>   "Get `real' window height. Mainly for emacs-21 \(or xemacs maybe\)."
>   (let ((bn " *window-height*"))
>     (save-window-excursion
>       ;; Must be `switch-to-buffer' (`set-buffer' is not reliable),
>       ;; but "Cannot switch buffers in a dedicated window" occurs for
>       ;; some buffer.  So sometimes weird value returned for buffers
>       ;; eg. listed in `special-display-frame-alist'.
>       (or
>        (condition-case nil (switch-to-buffer bn) (error nil))
>        (set-buffer bn))
>       (if (= 500 (buffer-size)) ()
>         (erase-buffer) (insert (make-string 500 ?\n)))
>       (goto-char 1)
>       (move-to-window-line -2)))) ;; -2 で少し余裕を取っている
> 
> (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")
>   (let* (;;(height (1- (window-height)))
>          (height (basic-get-real-window-height))
>          ;; (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)))))
>   ;; 以下同様
> 
> 
> 本件に関しては、emacs-21 でも オリジナルの smooth-scroll-up/down の動作が
> 完全ではないので良い方法が見付かれば直したいと思っています。
> 
> しかし、emacs-21 でも、オリジナルの smooth-scroll-up/down の仕様では極
> 端に行間を大きくしないかぎり カーソルの移動範囲が正確にウィンドウ中央の 
> 1/4 ~ 3/4 の範囲に収まらない、という程度の問題にすぎないので、上のような
> basic-get-real-window-height() を使うくらいなら、もう少し放っておこうか、
> と思っています。もともとの目的が半画面ジャンプをなくそう、というものでは
> ないので…。

ありがとうございます。これも使用してみましたが
------------------------------------------------------------
(top-edge 0)
(btm-edge height)
------------------------------------------------------------
を
------------------------------------------------------------
(top-edge 1)
(btm-edge (- height 2)
------------------------------------------------------------
のようにしないとほとんどの場合、カーソルが画面の中央に飛んでし
まいます。

もう一つ気になった点は、スクロールの動作が遅いという点です。
なぜかはわからないのですが、スクロールの途中でたびたび止ります。
止っている時間は1秒にも満たないと思いますが、結構気になりまし
た。
Technical Details
Message-ID: <xl9wv6hit9t.wl@cal.infonets.hiroshima-u.ac.jp>
Path: arc1-ca.pugleaf.net!archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeed.mesh.ad.jp!newsfeed.media.kyoto-u.ac.jp!onodera-news!news.heimat.gr.jp!news.tutrp.tut.ac.jp!server.tut.ac.jp!nfeed.gw.nagoya-u.ac.jp!news-sv.sinet!east-news.csi.ad.jp!hiroshima-u!not-for-mail
References: <xl9d78jgki9.wl@cal.infonets.hiroshima-u.ac.jp> <9fj2mh$8o1$1@sn.asahi-net.email.ne.jp> <xl94rtuomm1.wl@cal.infonets.hiroshima-u.ac.jp> <9fk0do$48j$1@sn.asahi-net.email.ne.jp> <xl9snhehw1z.wl@cal.infonets.hiroshima-u.ac.jp> <9fkvf1$fu9$1@sn.asahi-net.email.ne.jp> <xl9puchj0a5.wl@cal.infonets.hiroshima-u.ac.jp> <9fler4$sia$1@sn.asahi-net.email.ne.jp> <9flg0i$sia$2@sn.asahi-net.email.ne.jp> <xl9k82ptqrw.wl@cal.infonets.hiroshima-u.ac.jp> <xl9vgm7sib2.wl@cal.infonets.hiroshima-u.ac.jp> <xl9u21rs9d8.wl@cal.infonets.hiroshima-u.ac.jp> <86zobjgds2.fsf@thelonious.smoke.or.jp> <xl98ziyg87z.wl@cal.infonets.hiroshima-u.ac.jp> <861yoqdk1t.fsf@thelonious.smoke.or.jp>

Show Full Headers
Complete Article Headers
X-Google-Language: Japanese,JIS
X-Google-Thread: 1107f7,bc01201f0ce88c8c
X-Google-Attributes: gid1107f7,public
X-Google-ArrivalTime: 2001-06-12 09:07:26 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeed.mesh.ad.jp!newsfeed.media.kyoto-u.ac.jp!onodera-news!news.heimat.gr.jp!news.tutrp.tut.ac.jp!server.tut.ac.jp!nfeed.gw.nagoya-u.ac.jp!news-sv.sinet!east-news.csi.ad.jp!hiroshima-u!not-for-mail
From: IMAI Hidetoshi <hidepin@infonets.hiroshima-u.ac.jp>
Newsgroups: fj.editor.xemacs
Subject: Re: スクロールの挙動
Date: Wed, 13 Jun 2001 00:59:10 +0900
Organization: Hiroshima University
Lines: 189
Message-ID: <xl9wv6hit9t.wl@cal.infonets.hiroshima-u.ac.jp>
References: <xl9d78jgki9.wl@cal.infonets.hiroshima-u.ac.jp>
 <9fj2mh$8o1$1@sn.asahi-net.email.ne.jp>
 <xl94rtuomm1.wl@cal.infonets.hiroshima-u.ac.jp>
 <9fk0do$48j$1@sn.asahi-net.email.ne.jp>
 <xl9snhehw1z.wl@cal.infonets.hiroshima-u.ac.jp>
 <9fkvf1$fu9$1@sn.asahi-net.email.ne.jp>
 <xl9puchj0a5.wl@cal.infonets.hiroshima-u.ac.jp>
 <9fler4$sia$1@sn.asahi-net.email.ne.jp>
 <9flg0i$sia$2@sn.asahi-net.email.ne.jp>
 <xl9k82ptqrw.wl@cal.infonets.hiroshima-u.ac.jp>
 <xl9vgm7sib2.wl@cal.infonets.hiroshima-u.ac.jp>
 <xl9u21rs9d8.wl@cal.infonets.hiroshima-u.ac.jp>
 <86zobjgds2.fsf@thelonious.smoke.or.jp>
 <xl98ziyg87z.wl@cal.infonets.hiroshima-u.ac.jp>
 <861yoqdk1t.fsf@thelonious.smoke.or.jp>
NNTP-Posting-Host: cal.infonets.hiroshima-u.ac.jp
Mime-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu")
Content-Type: text/plain; charset=ISO-2022-JP
X-Trace: news.hiroshima-u.ac.jp 992361552 10847 133.41.33.61 (12 Jun 2001 15:59:12 GMT)
X-Complaints-To: news-admin@hiroshima-u.ac.jp
NNTP-Posting-Date: 12 Jun 2001 15:59:12 GMT
To: Seiichi Namba <sn@asahi-net.email.ne.jp>
In-Reply-To: <861yoqdk1t.fsf@thelonious.smoke.or.jp>
User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd)