🚀 go-pugleaf

難波です。

IMAI Hidetoshi <hidepin@infonets.hiroshima-u.ac.jp> さん writes:

> これにも、気になる問題点があります。
> 
> ●"newline"がないため、bufferの最終行で改行すると、画面の中央にカーソルが飛んでしまう。

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

ええと、my-newline でも何でも材料は沢山ある訳ですから、後は
ご自分で研究して使いやすいものをお作りになるのがよろしいでしょう。

scroll-step の問題が長年にわたって放置されていることからみると、おそら
く、ユーザの大半はデフォルトのままの挙動で満足しているか、ごくたまに 
scroll-step の設定が無視される程度のことは大して問題にしていないのだ
と思います。

いわば、この問題は多くのユーザにとってはとるに足らないものであって、
本当にこの問題にこだわるのであれば、ご自分で研鑽を積んで満足のいくもの
を書くしかないように思います。

本当にコンピュータを使って幸福に暮らそうと思うのであれば、結局は満足の
行くものを自分で書く以外に方法はありません。

> 私は、c-quickのソースが結構長く、使用しない関数が多いような気
> がするのでできるだけ削ろうとおもいます。
> 理由は、
> 
> ●メモリを無駄な関数の分も使用してしまってもったいない
> 
> ●起動時間が多くかかってしまう。
> 
> と思っているからです。
> 実際は、これらの問題は考える必要はあるのでしょうか
> アドバイスお願いします。

考え方しだいですね。私は今は dired-dd と MonK、自分用の FEP である
lkk 以外はバイトコンパイルすらしていません。一方で、数１００行程度の
 ~/.emacs すらバイトコンパイルしないと気が済まない、という人も居る訳で…。

参考までに私の考え方を少し書けば…。

たとえば、１０年も使ってれば ~/elisp/ の下の *.el の総行数／ワード／文
字数は

  22033   85251  770585 total

この位になります。全部をロードしてはいないと思いますが。.emacs だけでも
2500 行くらいはあります。

それでも、昨年あたりから、~/elisp の下では、上記のもの以外はバイトコン
パイルは止めました。コンピュータが充分速くなったのと、emacs の種類が多
くて面倒なこと、elisp ではバイトコンパイルしないと使いものにならない、
というものは全体の数％もないように思われること、などが理由です。使う 
emacs を１個か２個に絞れるようになったらまたバイトコンパイルしようかな、
とは思いますが。

起動時間は確かに emacs -q の時と違います。計ったことは無いですが３０秒
から１分くらいです。それでも、どうせ emacs は朝１回立ち上げるだけだし、
トイレでも行ってれば良い訳で。

basic.el や c-quick.el (ただしこれは改行多いです)はそれ程短かいもので
はありませんが、かといって巨大なものでもありません。バイトコンパイルす
れば 30k くらいのものでしょう。

USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
sn       32749  0.3 15.3 22272 19632 tty1    S    Jun12   1:28 /usr/local/emacs-21.0/bin/emacs

全体が使うメモリの量からすると大したもんではないような気がする。emacs -q
で起動したって 10M 位は喰う訳ですし、今のコンピュータなら大した事ないし、
今や X や netscape などに比べれば行儀良くて可愛いもんです。

「無駄な関数」といっても、M-x command-apropos RET して表示される
関数のうち、ご自分がお使いになっているコマンドはどの位ありますか。
もちろん、この表示には実際にロードされていないものも含まれますが。


…そんな訳で、私の場合は、c-quick に余計なものが入っている、というのは
大して気にするべき問題ではないように思っていますが、もちろん考え方しだ
いな訳ですね。

また、私の場合、人様から戴いた物件は、余程の事が無い限り直接いじりませ
ん。それは失礼だと思っているとかそういう問題では全くなくて、emacs の
場合は hook だの eval-after-load だのといったしくみがあるので殆どその
必要がないからです。いじってしまうと差分やパッチを作るのが面倒、という
のもありますが。まして使わない関数／変数が入っている程度では改造しませ
ん。同じように動く保証もないし。

> "scroll-up-aggressively"も同様にありませんでした。

aggressively の方は、emacs-21 特有かもしれません。で、まだどうもちゃんと
機能してないような気がする。

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

お使いの xemacs では元々そういう変数がないのかもしれませんね。そういう
場合でも setq はできる訳で。

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

どうもこの差が気になりますが、行間を空けているかどうかとかその
あたりの問題も関係あるのかもしれません。

> もう一つ気になった点は、スクロールの動作が遅いという点です。

basic-get-real-window-height() が遅いんでしょうね。キー押しっぱなしの
時は、１行スクロールするごとに別のバッファを見にいってる訳ですから、速
く動く訳がない。window-height の値を変数にキャッシュしておくような方法
を考えれば多少は改善できるかもしれませんが（これは途中まで書いたが、ユー
ザがウィンドウをリサイズする場合も考えると労力ほどの効果はないような気
もした）。

それでも…

> なぜかはわからないのですが、スクロールの途中でたびたび止ります。
> 止っている時間は1秒にも満たないと思いますが、結構気になりまし
> た。

emacs-21 で celeron 500A というのだったかな、そういう CPU ですが、うち
ではあれでキー押しっぱなしにしても体感速度は大して変りません（もちろん
バイトコンパイルなし）。あるいは、遅いのは xemacs 特有の問題かもしれま
せんね（何か別の設定を行なう必要があるのかもしれない）。

バイトコンパイルすれば多少は改善されるかもしれませんが、本件のように細
かい問題に血道を上げるのであれば、ビルトインの関数が無い以上、ある程度
は仕方のない問題かもしれません。

C ソースや window.el などを研究して、C プリミティブの関数を書くなり、
pixel 単位の計算をする方法にすれば良くなるかもしれませんが、本件に関し
ては私はそこまでする価値がないと思っているので、期待しないで下さい。

よく考えてみると、今井さんにとっては結局は、scroll-step に関するバグを
修正してもらうのが一番簡単ではないでしょうかね。筋としても一番通ってる
ように思えます。

本件に関しては、そろそろ失礼しようと思います。
ご健闘を祈ります。