WikipediaのVimページの作為的に書かれた文章について

Wikipedia Vim

一昨日の夜WikipediaのVimページを見て腹が立ったのでこんなやり取りをしました。
WikipediaのVimページの作為性にキレて登場人物をうんこ呼ばわり

Shougo氏をうんこ呼ばわりしたことは謝罪します。申し訳ありませでした。
プラグインの部分の文章の偏り方が作為的過ぎてムカついたんですよ。
Shougo氏に関連する情報だけが書かれすぎ。バランスが悪い。そんなにShougo氏の事書きたきゃShougo Matsushitaページ作成してそっちでやればいい。


Vimページの以下の2ヶ所で最も作為性を感じました。
(1) プラグイン - 代表的なプラグイン

特に、Shougo作による、Unite、Vimshell、Neocomplcacheなどはその代表例である。

なんでShougo氏だけなの？高性能で多機能なプラグインを作成した人は外国人や他の日本人にもいるでしょう。他の人の名前を書かないならShougo氏も消すべき。

あと、列挙されているプラグインが順不同といいながら2番目から5番目がShougo氏のもの。「2番目」といえばこれですね。→http://anond.hatelabo.jp/20110617071227
順番はアルファベット順にした方がいいんじゃないかな。


(2) プラグイン - GitHub による管理

2010~2011年になると、その部分を自動化し改良したVimスクリプトが登場した。それが、Vundle（バンドル、gmarik氏作）とNeobundle.vim（ネオバンドル、Shougo氏作）である。

これは許せない！
なんでこの2つのプラグインを並べて書けるのか？
NeobundleはVundleのソースコードベースでスタートした。
しかもforkせずにソースコードをコピーした形でスタート。
並べて書くならその辺の情報は書くべき。


initial commitはVundleの方が1年程先です。
Vindleは2010/10/18、Neobundleは2011/09/17

(Neobundleは2013/05/21にREADME.mdのAboutの文章を "based on Vundle" から "inspired by Vundle" に変えちゃった)

Neobundleのライセンスおよびソースコードの出典の表記に関してはVundle作者が2014/02/04にキレました。
why I stopped contributing to vundle


この時の第1次対応がまぁ非道かった。この辺は下記リンクを参照下さい。
https://github.com/Shougo/neobundle.vim/commit/d595e6e6f6862de97a2fc93db36bcbf576dc71a6
https://twitter.com/ShougoMatsu/status/431374562136051712
https://github.com/Shougo/neobundle.vim/commit/912b4b2dcd4a01915b9acbf3c3af1a986d3eb76a


こんな感じだからShougo氏本人がこの記述を特に問題視していないのは仕方がないのかな。。


Wipipediaの話に戻ります。
(1), (2)ともEndo213というIDが2回に分けて2012年4月2日に追加しています。
http://ja.wikipedia.org/w/index.php?title=Vim&diff=41918945&oldid=41862971
http://ja.wikipedia.org/w/index.php?title=Vim&diff=41919311&oldid=41918945


以上で終わります。


私にはTEAM Shougoが闇で頑張っている感じにしか受けとれないですね。
自己顕示欲強いのは分かるけど、とにかくバランスよく頼むわ。
Vim本体側、Vimプラグイン側どっちにもSuperな人はいっぱい居るんだし。


PS
「お前がWikipediaを編集して直せよ！」と言われていますが多分直しません。
きっとEndo213さんがいい感じに直してくれるはずだと信じています。ね！Shougoさん！

H8SでNORTiのライブラリリンク時にL1502のwarningが出た時の対処方法

HEW H8 NORTi

H8S用のファームウェア(OSはNORTi)をHEWでビルドしたらリンカがwarning出した。解決にちょっと手間取ったので備忘録メモ。

ターゲットCPUはルネサスのH8Sファミリ。
OSはミスポのNORTiをライブラリリンクしています。

まずリンカの出力メッセージ。

Phase OptLinker starting
L1502 (W) Stack size in "os_core" conflicts with that in another file
Phase OptLinker finished

Build Finished
0 Errors, 1 Warning

スタックサイズが "os_core" と他のファイルで矛盾してる。。うーん、作成されたmapファイルを見たけど特に怪しいところはない。STACKセクションもちゃんと定義してるし。
os_coreなんて名前のファイル私は作っていないのでおそらくリンクしているライブラリの中か。


ということで、リンクしているNORTiのライブラリ(C:\NORTi\LIB\H8\CH386\n4eh8s2.lib)を生成するMakefile(C:\NORTi\LIB\H8\CH386\n4eh8s2.mak)を覗いてビルドオプションを確認してみる。
(Tool Chainのバージョンが7_0_0の場合は CH386 を CH387 に読み替えて下さい)

〜
CC       = ch38
CFLAGS   = -cp=2000a -nol -nologo -op=1 -sp=r,sh,l=2,sw,st,e -sta=l -i=$(INC)
〜

cp はCPU指定のオプション
nol はリストファイル出力しない指定
nologo はコピーライトの出力抑止指定
op と sp は最適化関連のオプション
sta はスタック計算サイズを指定するオプション。。あやしい！
ライブラリはlarge(4byte)の指定という事をφ(..)メモメモ。それを踏まえて自分のプロジェクト(HEW)の設定を確認します。
HEWの「ビルド」メニュー → 「H8S,H8/300 Standard Toolchain...」で表示されるダイアログの「CPU」タブにあります。

あっ、ライブラリ側の指定と違う！！
ここを「ラージ(4byte)」にしたらwarning消えました。めでたしめでたし。



PS
今回のターゲットCPUのRAMサイズは 32kbyte (kbyteですよ奥さん!!)で2バイトで収まるのでwarning出たままでも特に問題は発生しないと思います。でも気持ち悪いのでwarning消したいですよね。

fedora17 で +lua/dyn なvimをビルドする

Vim linux lua

[2013/04/16 追記あり]
fedora17は64bit版です。

vimのソース取得

Vim from Mercurial : vim online を参考に引っ張って来ます。
私は ~/okome/vim に取得しました。

lua関連のパッケージのインストール

$ sudo yum install lua lua-devel

luaは既にインストールされているかも。

static linkさせたい場合は lua-static もインストールします。

$ sudo yum install lua-static

Vimのconfigure

毎回configureのオプションを指定するのは面倒くさいので以下のようなファイル(copt_lua.txt)を作成しときます。
luaに関係するのは最後の --enable-luainterp=dynamic ですね。dynamicをyesにするとstatic linkになります。

$ cd ~/okome
$ cat copt_lua.txt
--enable-multibyte --with-gnome --with-features=huge --enable-fail-if-missing --enable-luainterp=dynamic

$ cd vim
$ ./configure `cat ../copt_lua.txt`

エラーが出たらエラーメッセージに従ってください。( rm src/auto/config.cache する等 )

$ make

動作確認

$ src/vim

:ver の表示に +lua/dyn が含まれていることを確認してください。

luaでHello world出力。

:lua print("Hello world.")

E370: Could not load library liblua.so.5.1
Lua library cannot be loaded.

およ！ライブラリがロード出来ないと怒られました。

[2013/04/16 追記]
Vim 7.3.897で正しいライブラリ名(liblua-5.1.so)を参照するようになったので以降の記事は古い情報です。

ライブラリの確認

$ cd /usr/lib64
$ ls -l liblua*
-rwxr-xr-x. 1 root root 186176  1月 14  2012 liblua-5.1.so*
lrwxrwxrwx. 1 root root     13  4月  9 23:18 liblua.so -> liblua-5.1.so*

あれ？微妙にライブラリ名が違う。。
Vimは liblua.so.5.1 をロードしようとしてるけど
実在するのは liblua-5.1.so ですねぇ。Vimのconfigure時に指定出来るのかな？
ええぃ！自分でシンボリックリンク作っちゃいましょう。

$ sudo ln -s liblua-5.1.so liblua.so.5.1
$ ls -l liblua*
-rwxr-xr-x. 1 root root 186176  1月 14  2012 liblua-5.1.so*
lrwxrwxrwx. 1 root root     13  4月  9 23:18 liblua.so -> liblua-5.1.so*
lrwxrwxrwx. 1 root root     13  4月 10 00:47 liblua.so.5.1 -> liblua-5.1.so*

これでライブラリのロードは大丈夫。

動作確認 (2)

$ cd ~/okome/vim
$ src/vim

:lua print("Hello world.")

Vimのコマンドラインのところに Hello world. と表示されたら成功です。
後は楽しくluaりましょう。

HEWのイケてないところ

HEW C言語

昨日ツイッターでルネサスさんおよびHEWを盛大にdisってしまいました。
関係者の皆様申し訳ありませんでした。
ここにdis理由を書きます。


検証Ver.
High-performance Embedded Workshop Upgrade 4.09.00
C/C++ compiler package for SuperH RISC engine family V.9.04 Release 01

HEWのイケてないところ

  • プロジェクトの設定を他の開発で流用しにくい。(プロジェクトのエクスポート機能がない？)(プロジェクトファイル *.hwp を直接編集するとHEWで開けなくなることが多い)
  • コンパイラのマクロ定義設定の適用範囲をプロジェクト内全体またはCファイル個別に指定出来るが内部管理上は全体/個別を区別していないようで、プロジェクトにCファイルの追加/削除を繰り返すと設定がおかしくなったりHEWが落ちたりする。
  • ファイル個別の設定の確認方法が貧弱。せめて設定の有無が一望できるようなUIが欲しい。
  • プロジェクトビューにて見えている範囲でしかファイルの移動がおこなえない。(プロジェクトファイル *.hwpを直接編集すれば出来るかもしれないが、最初の理由の絡みでちょっと怖い)
  • コンパイラのインフォメーションレベルメッセージがデフォルトでOFFになっている。（プロトタイプ宣言のない関数呼び出しや、値を設定せずにローカル変数を使用してもコンパイラは教えてくれない）
  • 以下のコードを含むファイルで依存関係の更新をするとエラーになる。
#if 0
#include "moge.h"
#endif

Scanning Dependencies...
Phase: SH C/C++ Compiler, File: SH C/C++ Compiler, dependency scan error
C:\temp\product\POKOPOKO\pokopoko.c(2) :  DC201 (E) A header file does not exist 'moge.h'

以下のようにすると回避できる。。。

#if 0
#	include "moge.h"
#endif


エディタ部分に関しては使用していないのでノーコメントです。


disる理由付けとしては弱いですね。ほんとすいませんでした。
お酒怖いですｗ

iOS版Vimのヘルプを日本語にする

Vim iOS

iOSにVimがやって来ました。

「ctrlキーが...」「ctrlキーが...」という声が聞こえてきますが、「Vimのヘルプがどこでも見れる＆ちょこっと動作を試せる環境」と割り切るととっても最高なアプリです。
せっかくなのでヘルプを日本語で表示されるように設定してみましょう。

iPhone/iPod touch/iPadにVimをインストールする

今回はiPhoneにインストールします。
http://itunes.apple.com/jp/app/vim/id492668168?mt=8

Vim日本語ヘルプを用意する

http://vim-jp.org/のWindows版(+kaoriya)をインストールしている場合は

(Vimインストールフォルダ)\plugins\vimdoc-ja

にすでにあります。
そうじゃない場合は https://github.com/vim-jp/vimdoc-ja 等から引っ張ってきます。

iTunesでファイル共有

iPhoneをPCに接続してiTunesのファイル共有画面に遷移します。


そして、Vim日本語ヘルプ配下のファイルをドラッグアンドドロップします。*1
(全部で132(1+131)ファイル(maybe))

(Vimインストールフォルダ)\plugins\vimdoc-ja\syntax\help_ja.vim
(Vimインストールフォルダ)\plugins\vimdoc-ja\doc\*



あと https://gist.github.com/1687306 をダウンロードします。(ファイル名:fmv.vim)
改行コードが unix になっていない場合は変更ください。

:w ++ff=unix fmv.vim[Enter]

これも同様にドラッグアンドドロップします。
ちなみにこのファイルはWindows上のVimで次の手順で作成しました。

" カレントディレクトリをdocへ (:help :cd)
:cd (Vimインストールフォルダ)/plugins/vimdoc-ja/doc[Enter]
" 現在行を外部プログラム(dir/B)の出力結果で置き換え (:help Q_co)
" (実際に !! と入力するとコマンドラインに :.! と表示されるが構わず続ける)
!!dir/B[Enter]
" 全行を置換(ｷｬｰ) (:help :s)
:%s@.*@call rename("&","vimdoc-ja/doc/&")@[Enter]
" 先頭の3行はそれなりに編集
ggO
call mkdir("vimdoc-ja/doc", "p")
call mkdir("vimdoc-ja/syntax", "p")
call rename("help_ja.vim","vimdoc-ja/syntax/help_ja.vim")<Esc>

Vimスクリプト実行

ここからはiPhoneのVimでの操作になります。
Vimを起動してfmv.vimを実行します。

:so fmv.vim[Enter]

成功するとiTunesのファイル共有画面が以下のようになります。

.vimrcの編集

iPhoneのVimで .vimrcを編集します。

:e .vimrc[Enter]

以下を追加します。

set enc=utf-8
set helplang=ja,en
set rtp+=~/vimdoc-ja
syntax on

終わったら保存します。

ZZ

ヘルプの表示

再度Vimを起動しててきとうに何かヘルプを表示させましょう。

:h tj[Enter]

ヘルプが日本語で表示されました。


tips

  • ピンチアウトでソフトキーボード消去
  • ダブルスライド(2本指で画面をなぞる)でスクロール
  • 水色の文字をダブルタップすると、それのヘルプへジャンプ
  • ヘルプウィンドウで :on すると他のウィンドウが閉じられる



これでどこでもVimの勉強が出来るようになりました。ウハウハです。
よろしくどうぞ。

*1:フォルダはドラッグアンドドロップできないみたいです。

VimのソースコードをVimで解析しよう(Part1-4)

vim C言語 gdb

(Part1-1)、(Part1-2)、(Part1-3)


さぁ、デバッガで動かして関連性を見てみましょう。デバッガは昔ながらのGDBを使います。GDBのフロントエンドはいくつか存在しますが、「昔ながら」でいきましょう。
man gdb
GDBマニュアル
ファイヤープロジェクト GDB ←わかりやすい!!

デバッグ用バイナリの作成

GDBでCソースコードデバッグするにはデバッグ情報入りのバイナリを生成する必要があります。
bash

$ cd vimソースをゲットしたディレクトリ
# 再生成可能なファイルを削除
$ make distclean
# デバッグ情報あり(-g)でconfigure (configureオプションはお好みで)
$ ./configure CFLAGS="-g" --enable-multibyte --with-gnome --with-features=big
$ make

デバッグ準備

実行中のvimプロセスのデバッグをするので端末(ターミナルエミュレータ)が2つ必要です。*1

  • 端末V … Vim実行用 (ウィンドウタイトルは Vim)
  • 端末G … gdb実行用 (ウィンドウタイトルは GDB)

端末Vで先ほど生成したVimを起動しましょう。

$ cd vimソースをゲットしたディレクトリ/src
$ ./vim

j でちゃんとカーソル下移動になるように下準備しましょう。

" 相対行番号表示on
:set relativenumber[Enter]
" インサートモードへ移行→ a改行b を入力→ノーマルモードへ移行
ia<CR>b<Esc>
" カーソルを1行目へ移動
k


端末Vは準備OK。
次は端末Gです。

# 現在実行中のvimプロセスのIDを表示
$ pgrep vim
22063
# GDBでプロセスID 22063の ./vim に接続
gdb ./vim 22063


「分離されたデバッグ情報がないよ」とか言われてますが、ライブラリのデバッグをする訳じゃないのでスルーして、これまで調べた3つの処理にbreakをセットしましょう。

(gdb) b screen.c:3482
Breakpoint 1 at 0x53a26b: file screen.c, line 3482.
(gdb) b screen.c:8644
Breakpoint 2 at 0x543b6e: file screen.c, line 8644.
(gdb) b edit.c:7116
Breakpoint 3 at 0x42caa2: file edit.c, line 7116.
(gdb)
breakpoint # 関数名 ファイル名 行番号 処理内容
1 win_line() screen.c 3482 相対行番号の描画データ設定処理
2 setcursor() screen.c 8644 カーソル描画処理
3 cursor_down() edit.c 7116 カーソル移動処理

デバッグ開始

Vimの実行を継続させます。

(gdb) c
Continuing.

端末VのVimに j を入力すると、端末GのGDBがbreakしました。変数の値を表示したりした後、バックトレース表示させ継続(c)を繰り返すと以下のような流れになりました。

Breakpoint 2, setcursor () at screen.c:8644
8644            windgoto(W_WINROW(curwin) + curwin->w_wrow,
(gdb) p curwin->w_wrow
$2 = 0
(gdb) bt
#0  setcursor () at screen.c:8644
#1  0x00000000004f1377 in display_showcmd () at normal.c:4038
#2  0x00000000004f1210 in add_to_showcmd (c=106) at normal.c:3960
#3  0x00000000004eb78a in normal_cmd (oap=0x7fff51cd2a90, toplevel=1) at normal.c:707
#4  0x00000000005c6169 in main_loop (cmdwin=0, noexmode=0) at main.c:1263
#5  0x00000000005c5b44 in main (argc=1, argv=0x7fff51cd2db8) at main.c:964
(gdb) c
Continuing.

Breakpoint 3, cursor_down (n=1, upd_topline=1) at edit.c:7116
7116            curwin->w_cursor.lnum = lnum;
(gdb) p lnum
$4 = 2
(gdb) bt
#0  cursor_down (n=1, upd_topline=1) at edit.c:7116
#1  0x00000000004f5231 in nv_down (cap=0x7fff51cd29d0) at normal.c:6191
#2  0x00000000004ec65f in normal_cmd (oap=0x7fff51cd2a90, toplevel=1) at normal.c:1193
#3  0x00000000005c6169 in main_loop (cmdwin=0, noexmode=0) at main.c:1263
#4  0x00000000005c5b44 in main (argc=1, argv=0x7fff51cd2db8) at main.c:964
(gdb) c
Continuing.

Breakpoint 2, setcursor () at screen.c:8644
8644            windgoto(W_WINROW(curwin) + curwin->w_wrow,
(gdb) p curwin->w_wrow
$5 = 1
(gdb) bt
#0  setcursor () at screen.c:8644
#1  0x00000000004f1377 in display_showcmd () at normal.c:4038
#2  0x00000000004f10e8 in clear_showcmd () at normal.c:3897
#3  0x00000000004ec99c in normal_cmd (oap=0x7fff51cd2a90, toplevel=1) at normal.c:1333
#4  0x00000000005c6169 in main_loop (cmdwin=0, noexmode=0) at main.c:1263
#5  0x00000000005c5b44 in main (argc=1, argv=0x7fff51cd2db8) at main.c:964
(gdb) c
Continuing.

Breakpoint 1, win_line (wp=0x20a97d0, lnum=1, startrow=0, endrow=21, nochange=1) at screen.c:3482
3482                            sprintf((char *)extra, "%*ld ",
(gdb) bt
#0  win_line (wp=0x20a97d0, lnum=1, startrow=0, endrow=21, nochange=1) at screen.c:3482
#1  0x0000000000536c14 in win_update (wp=0x20a97d0) at screen.c:1850
#2  0x00000000005342fb in update_screen (type=35) at screen.c:531
#3  0x00000000005c5f28 in main_loop (cmdwin=0, noexmode=0) at main.c:1166
#4  0x00000000005c5b44 in main (argc=1, argv=0x7fff51cd2db8) at main.c:964
(gdb) c
Continuing.

Breakpoint 1, win_line (wp=0x20a97d0, lnum=2, startrow=1, endrow=21, nochange=1) at screen.c:3482
3482                            sprintf((char *)extra, "%*ld ",
(gdb) bt
#0  win_line (wp=0x20a97d0, lnum=2, startrow=1, endrow=21, nochange=1)
    at screen.c:3482
#1  0x0000000000536c14 in win_update (wp=0x20a97d0) at screen.c:1850
#2  0x00000000005342fb in update_screen (type=35) at screen.c:531
#3  0x00000000005c5f28 in main_loop (cmdwin=0, noexmode=0) at main.c:1166
#4  0x00000000005c5b44 in main (argc=1, argv=0x7fff51cd2db8) at main.c:964
(gdb) c
Continuing.

Breakpoint 2, setcursor () at screen.c:8644
8644            windgoto(W_WINROW(curwin) + curwin->w_wrow,
(gdb) p curwin->w_wrow
$9 = 1
(gdb) p curwin->w_wcol
$10 = 4
(gdb) bt
#0  setcursor () at screen.c:8644
#1  0x00000000005c6087 in main_loop (cmdwin=0, noexmode=0) at main.c:1214
#2  0x00000000005c5b44 in main (argc=1, argv=0x7fff51cd2db8) at main.c:964
(gdb) c
Continuing.


デバッグ終了

端末Gのgdbはctrl-Cして止めた後、qで終了します。

^C
Program received signal SIGINT, Interrupt.
0x0000003a35ad9073 in __select_nocancel () from /lib64/libc.so.6
(gdb) q
A debugging session is active.

        Inferior 1 [process 26051] will be detached.

Quit anyway? (y or n) y
Detaching from program: /home/h_east/samba/Mercurial/vim_new/src/vim, process 26051

端末VのVimはGDBから切り離されたので通常通り :q! で終了できます。

考察

No. bp# 解説
1 2 私の環境ではset showcmdしてるのでその描画処理内で呼ばれている
(今回の件とはたぶん関係ないのでスルー)
2 3 カーソル下移動
3 2 showcmdの消去処理内で呼ばれている
(今回の件とはたぶん関係ないのでスルー)
4 1 ウィンドウの1行目の描画
5 1 ウィンドウの2行目の描画
6 2 2行目5カラム目にカーソル描画(相対行番号表示エリアも込みの位置)

今回の表示位置がずれる件に関係ありそうなのは No.2, 5, 6 ですね。
現象が起こせないのがもどかしいですが、ずれが発生する要因としては以下のようなパターンが考えられます。

  • No.2, No.5は処理されたが No.6が処理されなかった。

ソースコード的には setcursor()内すぐの redrawing() の判定がFALSEの場合に上記パターンになります。
redrawing()を見てみましょう。

/*
 * Return TRUE if redrawing should currently be done.
 */
    int
redrawing()
{
    return (!RedrawingDisabled
                       && !(p_lz && char_avail() && !KeyTyped && !do_redraw));
}

コメントには「再描画が必要な場合は TRUE を返す」って書いてます。
NOT(!)とAND(&&)で分かりずらい。。えーと、TRUEになる条件は

  • RedrawingDisabled が FALSE である
  • かつ (
    • 'lazyredraw'オプション がoff または
    • char_avail() が FALSE または
    • KeyTyped が TRUE または
    • do_redraw が TRUE )

'lazyredraw'オプションはよっぽどのことがない限り off のはずなので(要確認)、結局 RedrawingDisabled の状態に依存していると思われます。
再現手順を確立させてGDBのwatchコマンドで追いかければ原因がわかるかも！？

終わり

原因解明出来ていないですがPart1を終わります。
選んだ題材がいきなりハードル高すぎましたｗ
ですが、Vimを使用してのコードリーディングの一連の手順、GDBでのデバッグ方法は書きましたので参考になれば幸いです。
リクエストや質問や指摘ありましたら twitterやコメントでお気軽にどうぞ。

Part2はゴールデンウィークか！？

*1:Vimの起動直後からキー入力待ちまでの部分のデバッグをおこなう場合は1つじゃないと無理です。

VimのソースコードをVimで解析しよう(Part1-3)

vim C言語

(Part1-1)、(Part1-2)


前回までのソースコード解析で「カーソル位置による相対行番号の描画データ設定処理」と「カーソル描画処理」をやっている部分が特定できました。
が、一つ忘れてましたorz。
「カーソル移動処理」。
Vimでカーソルを移動させる方法はいっぱいあるんですが、今回は j 押下時の処理を探しましょう。

" 「'j'」をgrep (:help :grep)
:grep "'j'" .[Enter]
" (grepが終わってから)
" カレントウィンドウを次ウィンドウ(==Quickfixウィンドウ)に移動。 (:help ctrl-w_ctrl-w)
<C-W><C-W>
" Quickfixウィンドウの高さを可能な限り最大化 (:help ctrl-w__)
<C-W>_
" 〜しばしgrep結果と戯れる(時おり <C-F> 押しながら)〜

Quickfixウィンドウの52行目にノーマルモードのコマンドテーブルのデータっぽいものが！

./normal.c|350| {'j',   nv_down,    0,          FALSE},
" カーソルを52行目に移動 (:help G)
52G
" カーソル行のQuickFix情報にジャンプ (:help ctrl-w_<cr> して {)
<CR>
" カレントウィンドウ以外を閉じる (:help ctrl-w_o)
<C-W>o
" 1桁目が '{' で始まる所へ後方(↑)ジャンプ （== 後方の構造体の定義冒頭部へジャンプ） (:help [[)
[[
" カーソル行をウィンドウの最下行にして再描画 (:help zb)
zb


変数名等のプレフィックス nv_ はおそらくNormal or Visual の略でしょうね。
メンバは１つめがコマンド文字、2つめが処理関数のポインタです。

" ジャンプリストの1つ前の位置へ移動する (:help ctrl-o)
" (「    {'j',〜」の行へ)
<C-O>
" 前方(→)にWORD移動
W
" カーソル下のキーワード(nv_down)でタグジャンプ。
<C-]>

最初のifはシフトキー押してるかの判定なのでスルー。
次のelse ifはQuickfixウィンドウ判定なのでスルー。
elseの中のifはコマンドラインウィンドウの話なのでスルー。
ということはcursor_down()が呼ばれます。cursor_down()の定義をみると、、おぉ！ちゃんと curwin->w_cursor.lnum を増加させてます。(edit.c : 7115〜7116)

調査結果まとめ(再)

カーソル位置による相対行番号の描画データ設定処理は win_line() [screen.c : 3482]
カーソル描画処理は setcursor() [screen.c : 8644]
カーソル移動処理は cursor_down() [edit.c : 7116]


次回こそはデバッガで追いかけます。よろしくどうぞ。
(Part1-4)へ