🚀 go-pugleaf

The following message is a courtesy copy of an article
that has been posted to fj.editor.xemacs as well.

難波です。

もう失礼する、と書いたのですが、前の記事は言葉が足りないところがあるの
で最後に多少補足しておきます。

Seiichi Namba <sn@asahi-net.email.ne.jp> writes:

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

こだわるところ、というのは人によって大きく違うと思うので、人様から戴い
たり買ってきたりしたもので満足できないという事は往々にしてある訳で、そ
うした場合、最終的には問題の個所を解決する方策は自分自身で作るしかない、
と思っています。私の web ページに置いてあるものは殆どそのようにして出来
た産物です。

たとえば、大多数の方々は skk なら skk で満足されているのだろうが、私の
場合は幸福に暮らすためには自分で代替物を書くより他になかった訳。

> たとえば、１０年も使ってれば ~/elisp/ の下の *.el の総行数／ワード／文
> 字数は
> 
>   22033   85251  770585 total
> 
> この位になります。全部をロードしてはいないと思いますが。.emacs だけでも
> 2500 行くらいはあります。

 .emacs は実際には数個のファイルに分かれていて、新しい設定を書き足すた
めのファイルを勘定し忘れていました。数え直したら .emacs 相当の部分は 
4000 行位ありました。

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

basic.el は 12k くらいしかありませんね。c-quick と２つを混ぜて書いてしま
いました。

> 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 などに比べれば行儀良くて可愛いもんです。

demacs と 386 のＣＰＵを使っていた時は、skk と .emacs をダンプしたバイナリ
を作ったりしていた事もありますが、その頃に比べれば数 10kb くらいの elisp 
ファイルなど屁でもない、という感じでしょうか。

> せんね（何か別の設定を行なう必要があるのかもしれない）。

たとえば、再表示などに関して xemacs 特有の設定があるのかもしれない、
という事を考えていました。


PS.
なお、ウィンドウ外へのカーソル移動の時１行だけスクロールさせるという目
的に関して smooth-scroll-up/down の基本的な枠組を（改造して）利用す
るのはあまり適していないのではないか、と思います。というのは
smooth-scroll-up/down は「行」を対象とした処理だからです。

「ウィンドウ外へのカーソル移動の時１行だけスクロールさせる」には、「そ
の移動でウィンドウ外へカーソル(point)が出るかどうか」を調べ、「出るな
らスクロールする」、というようなアルゴリズムを使えば良いですね。
今頃になって申しわけないですが、そういうシンプルな作りであれば、

(defsubst before-the-window-p (point)
  "Test if POINT is off the window, being smaller than window top."
  (< point (save-excursion (move-to-window-line 0) (point))))

(defsubst after-the-window-p (point)
  "Test if POINT is off the window, being larger than window bottom."
  (> point (save-excursion (move-to-window-line -1) (end-of-line) (point))))

(defun sane-next-line (arg)
  (interactive "p")
  (let ((newpt (save-excursion (line-move arg) (point))))
    (while (after-the-window-p newpt) (scroll-up 1))
    (goto-char newpt)
    (setq this-command 'next-line)
    ()))

(defun sane-previous-line (arg)
  (interactive "p")
  (let ((newpt (save-excursion (line-move (- arg)) (point))))
    (while (before-the-window-p newpt) (scroll-down 1))
    (goto-char newpt)
    (setq this-command 'previous-line)
    ()))

(defun sane-newline (arg)
  (interactive "p")
  (let ((newpt (save-excursion (newline arg) (point))))
    (while (after-the-window-p newpt) (scroll-up 1))
    (goto-char newpt)
    (setq this-command 'newline)
    ()))

(byte-compile 'sane-previous-line)
(byte-compile 'sane-next-line)
(byte-compile 'sane-newline)

(global-set-key [up] 'sane-previous-line)
(global-set-key [down] 'sane-next-line)
(global-set-key [return] 'sane-newline)

こんな感じでご希望には沿うような気がします（結局書いちゃった）。

c-quick 全体よりは短かいですから使えればいいかもしれませんね。

境界条件などは大してチェックしていないので、実地テスト(<, > などのテス
トで良いかどうか)はお任せします。(interactive "_p") は直してください。

また、関数に分けてあるところをマージすれば多少は最適化はできると思いま
す。そのへんもご希望があれば試してみてください。

c-quick.el は昔にダウンロードしただけで、あまり研究していないのですが、
たぶん、同じような考えを使っていると思います。

-- 
難波清一＠東京西東京市 (http://www.asahi-net.or.jp/~pi9s-nnb/)
NAMBA Seiichi <sn@asahi-net.email.ne.jp>