Patch 7.4.651 のテストが無い

[mattn]

See #704

[deris]

本件、テストを追加してみようと思ったのですが、現在の挙動および期待する挙動がわからなかったため相談させてください。

OS:Linux
ver:7.4.683

手順:
いくつか検索パターンを作り、下記表にまとめました。

vim -u NONEで起動して確認簡略化のために、以下を設定してからテストを実施しています。

set hlsearch
set history=10000

確認内容

#	検索方法	文字列	パターン	結果
1	/	あいうえお	^.*%5v	あい
2	/	あいうえお	.*%5v	あいう
3	/	あいうえお	%<5v	あい
4	/	あいうえお	^.*%<5v	あ
5	/	あいうえお	.*%<5v	あい
6	/	あいうえお	%>5v	えお
7	/	あいうえお	%>5v.*	えお
8	matchstr	あいうえお	^.*%5v	あい
9	matchstr	あいうえお	.*%5v	あい
10	matchstr	あいうえお	%<5v	(空文字列)
11	matchstr	あいうえお	^.*%<5v	あ
12	matchstr	あいうえお	.*%<5v	あ
13	matchstr	あいうえお	%>5v	(空文字列)
14	matchstr	あいうえお	%>5v.*	えお

• 検索パターンが/のケースは、文字列欄の文字列をバッファに記載した上で、search commandで検索したケースです。検索文字列は、パターン欄の文字列を指定します。
  結果は、set hlsearchでハイライトされた部分です。
• 検索パターンがmatchstrのケースは、matchstr()関数で検索した結果です。引数に文字列欄の文字列、パターン欄の文字列を指定します。結果はechoで出力した値です。
• set regexpengine=1にした場合も同様の結果でした。

上記表の、以下の点がよくわかりませんでした。

• 1.と2.の結果が異なる。(1.は2.と同じ結果になるべき？)
• 3.、5.と、4.の結果が異なる(4.は3.、5.と同じ結果になるべき？)
• 10.と13.が空文字列になる理由がわからない(10.は3.、13.は6.と同じ結果になるべき？)
• 11.と12.の結果の理由がわからない(5.と同じ結果になるべき？)

[h-east]

@deris Vim contribute authorアタックチャンスを受けていただきありがとうございます。

ご指摘の通り、なんか全然整合取れていないですね。ASCII文字でも確認しましたが同様の結果になりました。
ただ、/の方は法則性がよく分からんですが、matchstrの方は一貫して\%～vをゼロ幅マッチ(/zero-width)として扱っているので整合が取れている気がします。
ですので、テストは最新Ver(7.4.683)のmatchstrの挙動を正とした結果を期待値として作成して頂ければと思います。

All＞
どうでしょうか？

特に反対意見が無ければ「/の検索パターンに\%～vを使用した場合の挙動が微妙な件」は別途Issueを立てます。

ちなみに上記挙動はVim 7.4.576でも同じですので以下のmattnさんのpatchによるdegradeではないです。
(逆に、\%>80vが7.4.577から7.4.581まではsingle byte/multi byte両方微妙になっていて、7.4.582から7.4.650まではmulti byteが微妙になっていたのが7.4.651で修正された形)

[h-east]

あー、ダメだ前言撤回。

matchstrも整合取れてない。
:help \%vの最後に/.*\%17v.と/.*\%<18vが同じ結果になると書いてあるけど、/では確かに同じだけどmatchstrでは結果が違う。

:echo matchstr('12345678901234567890','.*\%17v.')
12345678901234567

:echo matchstr('12345678901234567890','.*\%<18v')
1234567890123456

[h-east]

「matchstrは一貫して\%～vをゼロ幅マッチ(/zero-width)として扱っている」っていうのはあってそう。ただ:helpの記述と違う。わー

[ynkdir]

:echo matchstr('12345678901234567890','.*\%<18v')
1234567890123456

"¥%<18v." (最後ドット) ですね。誤植です。

[h-east]

@ynkdir あっホントだ。enもjpも両方確認してたけど気付かなかったです:sweat_smile: Thanks!

...ということはmatchstrの挙動はOKってことですよね。

[ynkdir]

"%<5v" とかの / の結果は n してみればわかりますが empty match のため 1 文字ずつマッチしてます。

[ynkdir]

たぶん / も matchstr も期待通りの挙動だと思います。

[deris]

@h-east @ynkdir お二人とも丁寧なご説明ありがとうございます。

ゼロ幅マッチがポイントということですね。(ちゃんとhelpを確認できていませんでした:sweat_smile:

確かにゼロ幅マッチだということを意識して考えると現状動作を理解することができました。

理解した内容をまとめたので、何か誤りがあればコメントいただけますでしょうか？

• /とmatchstrの差異が出るのは、/の場合はhighlightの関係上、ゼロ幅マッチだけどマッチ箇所(の右隣)にハイライトされているため、そこまでマッチしているように見えている。
• /のケースで、^.%5vと.%5vで差異が出たのは、.*%5vの場合、行頭からそれぞれ1個ずつマッチしたハイライトが表示されており、.*が0文字マッチの場合に、上記記載のゼロ幅マッチだけどマッチ箇所(の右隣)にハイライトされているのケースに当てはまり5文字目までマッチしているように見えている。
• matchstrで%>5vの検索結果が空文字列だったのはゼロ幅マッチの最短マッチ？だったから

[h-east]

@ynkdir

たぶん / も matchstr も期待通りの挙動だと思います。

確かにそうですね。highlightに惑わされました。失礼しました。

@deris

• /とmatchstrの差異が出るのは、/の場合はhighlightの関係上、ゼロ幅マッチだけどマッチ箇所(の右隣)にハイライトされているため、そこまでマッチしているように見えている。

Yes.

• /のケースで、^.%5vと.%5vで差異が出たのは、.*%5vの場合、行頭からそれぞれ1個ずつマッチしたハイライトが表示されており、.*が0文字マッチの場合に、上記記載のゼロ幅マッチだけどマッチ箇所(の右隣)にハイライトされているのケースに当てはまり5文字目までマッチしているように見えている。

Yes.

• matchstrで%>5vの検索結果が空文字列だったのはゼロ幅マッチの最短マッチ？だったから

ほぼYes.
「\%>5vそのものがゼロ幅マッチなのでそれだけではマッチしようがない」って感じですかね。
だから:h \%vのsampleでは前か後ろに .* が付いてるんですね。

以下のバッファに :%s/\%4v/_/g したら

12345
abcde

こうなるのを見て全貌が理解出来ました。

123_45
abc_de

ということでお時間のある時に是非test作成に再チャレンジ下さい。

[deris]

@h-east コメントありがとうございます。

helpには以下の様に記載があったので、表示列以降にマッチ(%5vだけで%5v.*の意となる)と誤解釈していましたが、表示列以降のいずれかの位置にゼロ幅にマッチということですね。腑に落ちました。

\%>23v  指定した表示列より後にマッチします。

test作成、再度挑戦したいと思います！

[mattn]

patches welcome タグたな卸しping