> この問題、ご紹介いただくまで、私も全く知りませんでした。一部ではかなり古く
> から有名だったようで、６年前とかの記事が検索でヒットしたりもしました。

私も別窓ジャンプがやりたくて検索して、初めて知ったのです。
としきさんは知っているものだとばかり思っていました。(^^;

> で、まぁ、対処するのは悪いことではないというか、ぜひやるべきだと思うところ
> ではありますが、ここwforum.cgiでもこのコードはいくつも使われているはず。
> ま、スクリプトを検索していちいち書き換えれば済むことではありますが。

あう、気が付きませんでした。(^^;
検索すると、自動リンクのルーチンで一か所
 target='_blank'
	  ↓
 target='_blank' rel='noopener noreferrer'

 target=\"_blank\"　が、5箇所
	↓
 target=\"_blank\" rel=\"noopener noreferrer\" 

直してみました。夜中にテストしてみようかな。

> でも、以前、たった５ヶ所ばかり検索して書き換えるだけで導入可能なスパム対応
> のプレビュー反転をにも二の足をふまれていたkonnoさんのことですから、

うう、そ、それは、そのうち・・・・;;;

V_csr.def　Ver07 を VZマクロの部屋に置きました。

2018に V_cursor.def Ver06 としてUPした縦カーソルマクロです。
 #8583： V_cursor.def Ver06 投稿者： konno 　 2018/11/11(日) 

今回は、今までよりも常駐レベルのアップが出来ました。
今までは、ファイルオープンなどの操作のたびに常駐解除されて使い勝手が悪いと感じていました。
常駐終了時に変数 gv の初期化もしてなかったので、それも直しました。

数日前、目が覚めたら、目からうろこが落ちたのです。
「&c 常駐って、編集モード以外でも動くんじゃね？
　そうだ、V_cursor マクロを直そう！」

;	(s)?.				; 編集モード意外で終了

これをコメントにして

	(s)??&>				;★変更　2 編集モードのみ縦線を引く

編集モード意外なら縦線を引かないようにしたら、割と問題なく動くんですね。
ただ、このままでは一部のマクロを実行後カーソル位置などがおかしくなります。

試行錯誤した結果、ネストの変るマクロ実行の後は不具合が出ることが分かりました。
「それなら、ネストを監視して、その数値が変わった時だけ常駐解除すればいいんじゃね？」
と思って、変数 uu をネスト監視用に追加して、大体下記のようにしました。

:c
	&05				;★変更 縦ラインの色変更(パッチ当て)
;	(mi==2)?cc$A0,?cc$90, m=mi,	; INS key ON青/OFF緑
;	&04 r.0=cc,			; 縦ラインの色変更(パッチ当て)
;	c=vp.8,				; c使いまわし

:r
;	(s)?.				; 編集モード意外で終了
	uu=sp-pu,			;★追加 ネスト監視用
;	(mi!=m)?>c			; INS key ON/OFF
	(mi!=m)?&05			;★変更　INS key ON/OFF
;	&>				; 2 縦線を引く
	(s)??&>				;★変更　2 編集モードのみ縦線を引く
	&c				; === 入力待ち ====
	(uu!=sp-pu)?{gv0,&d .}		;★追加 ネストが変ったら終了

STKHLP で問題が出る変数 v も vv に変更して、問題無くなりました。
ちなみに、ネストの変わるマクロとは、自作のヘボマクロです。(;_;)
 F06 を置き換える tagl.def v.05 とか
うーん、何が悪いんだろう。バグかも。

和生さんも最近お見掛けしないし、このマクロのユーザーはもう私一人かも。(;_;)
ダウンロードカウンターでユーザー数確認するために、マクロ部屋に置いています。
どなたか、これはマズイとか、もっとうまい方法をご存じでしたらご教示ください。m(__)m

＃　夢の呼吸、幻の型！！
＃　おのれは善逸か？　寝ている時に脳が活性化するとか？


2022-02-02　Ver07 V_csr.def に変更　常駐レベルアップ　変数 v を vv に　変数 uu ネスト監視用
2018-11-11　Ver06 V_cursor.def に変更　[INS]キーのON/OFF で縦カーソルの色を変更
2016-03-31　Ver5　三太クロス合体(^^; 　ほぼ完全版
2016-03-28　Ver4　縦分割の右対策 その他
2016-03-26　Ver3　v:縦ラインの長さちょい変更（v0=wy）v1=1行　v2=上下プラスの3行　以降は同様
		　 フリーカーソル完全対応　縦ラインの色変更 by wanama★
2016-03-25　Ver2　v:縦ラインの長さ（v0=wy）可変でスピードUP　フリーカーソル対応
2016-03-22　Ver1　V_line.def wanama氏とEPI氏二つのマクロを悪魔合体！！

V_csr.def 起動中にファイラーからファイルを読み込もうとすると

"〇〇〇〇"は入力できません

と表示されてファイルが開けない時がありました。
キー入力のループに問題があるのではと考え

:r
;	(s)?.				; 編集モード意外で終了
	uu=sp-pu,			;★追加 ネスト監視用
;	(mi!=m)?>c			; INS key ON/OFF
	(mi!=m)?&05			;★変更　INS key ON/OFF
;	&>				; 2 縦線を引く
	(s)??&>				;★変更　2 編集モードのみ縦線を引く
	&c				; === 入力待ち ====
	(uu!=sp-pu)?{gv0,cm0,&d .}		;★追加 ネストが変ったら終了

これを　↓　のように

:c	&05				; 縦ラインの色変更(パッチ当て)
	uu=sp-pu,			; ネスト監視用

:r	(s)?>L				; 編集モード意外なら&cにループ
	(mi!=m)?&05			; INS key ON/OFF
	(s)??&>				; 2 編集モードのみ縦線を引く
:L	&c				; === 入力待ち ====
	(uu!=sp-pu)?{gv0,cm0,&d .}	; ネストが変ったら終了
	(s)?>L				; 編集モード意外なら&cにループ

このように変更したらファイルは開けるようになりました。
VZマクロの部屋のマクロは、Ver07a に差し替えました。

http://tamaneko.world.coocan.jp/vzmac.htm

今度は外部マクロが実行できない？　だったかな？
違う不具合が出てきました。
キー入力のループに問題があるのではと考え

> :L	&c				; === 入力待ち ====
> 	(uu!=sp-pu)?{gv0,cm0,&d .}	; ネストが変ったら終了
> 	(s)?>L				; 編集モード意外なら&cにループ

これを　↓　のように

:L	&c				; === 入力待ち ====
	(uu!=sp-pu)?{gv0,cm0,&d .}	; ネストが変ったら終了
;	(s)?>L				; 編集モード意外なら&cにループ

このように変更したら問題無くなったようです。
VZマクロの部屋のマクロを、Ver07b に差し替えました。

http://tamaneko.world.coocan.jp/vzmac.htm


＃　日替わりの呼吸、変転流転の型！


＃　いいえ、蟲と共に生きる定めなのです。

探してみたら、こんなものがありました。

> 05665/05668 xxxxxxxx  Emmett           VZBUG(2) サイレントモード関連のバグ
> (15)   97/04/15 10:58

> ■　ＶＺバグ大全（２）：サイレントモード関連のバグ

> （Ａ）サイレントモードでの #k または #y の反復
> 　サイレントモードで、非ブロックモードでの行記憶またはカット（#k、#y）を連
>   続して実行すると、ある特定の点までくると、テキストスタックに格納される文
>   字列の最後が化けることがあります。


これは非ブロックモードの話なので、今回は違うかもしれませんが

> （Ｂ）サイレントモードでの #_
>   どうやらサイレントで実行された #_ は、特定の条件下でカーソル位置ポインタを
>   算出しまちがえるらしい。

> 　このトラブルは、 #_ 直後に #? などで最終行を一度表示してやれば回避するこ
>   とができます。これは #_ 直後でなければ駄目で、#38 のあとでは遅すぎます。
 
> 　　・サイレントでの #_ のあとには #? &s
> 　と習慣づけておくといいでしょう。


どうやらこれが関係ありそうです。
高橋版でもこのバグは潰しきれなかったような気がします。

 [ESC]I @I "I カーソル位置へ挿入" のマクロを

;	#b #_ (ct)?{ #> #m #x }
	#b #_ #? &s (ct)?{ #> #m #x }

このようにするか、&s を取ってしまうと、改善がみられました。

前回と同じ条件で実行して、ファイルサイズが一致するようになりました。
ただし、中身はおかしくなっているようです。
これはおそらく VTDOS の EMS がらみの不具合と思われます。

この実験で、榊原版VZだけは、ファイルサイズが小さくなりました。
ファイル挿入が途中で終わっているのか、それとも？


今まで実験に使用した生ログファイルは

 280,386 wf_log.cgi
 380,844 wf_log130407.cgi
 381,081 wf_log130408.cgi

このうちの 381k のファイルの途中に 380k のファイルを挿入していました。
挿入する 380k のファイルに問題があるのか確認のため、今度は
 280k のファイルの途中に 380k のファイルを挿入する実験をしました。

そうしたら、榊原版以外の VZ は正常に終了しました。
榊原版VZだけは、ファイルサイズが2バイト大きくなりました。
改行が1つよけいに入っていました。

この現象について、野ざらし言#4651 で、めざらさんの発言

> テキストスタックに複写する際に，テキストバッファサイズの境界付近に
> たまたまラインバッファサイズを超える長い行が存在した場合の振る舞い
> （結構レア？）に係ることかもしれないですね。「新発見」かも。

これが関係しているかもしれないと私も思いました。

ただ、MSDOS Player と DOSVAXJ3 では正常に動作しているのが謎なのです。
プラットフォームのメモリ管理とVZの相性で不具合が出ているのではないかと感じるのです。
VTDOSとXP（NTVDM）の共通点は、32ビットのメモリ管理で16ビットのVZを動かしているところ？

前回の書き込みで

> ただ、MSDOS Player と DOSVAXJ3 では正常に動作しているのが謎なのです。
> プラットフォームのメモリ管理とVZの相性で不具合が出ているのではないかと感じるのです。
> VTDOSとXP（NTVDM）の共通点は、32ビットのメモリ管理で16ビットのVZを動かしているところ？

このように書きましたが、32ビットのメモリ管理で、ふと思ったことがあります。
ちょっと前の記事ですが

#10145：MS-DOS Player 12/30版 　投稿者：konno 　 2021/12/31(金) 

> さっそく使ってみましたが、ia32版では、自作のアプリでエラーが出ます。
> 自作アプリとは、turbo basic の古いプログラムで、VGAでないと動きません。
> 
> 実は、今までの MS-DOS Player では、エラーが出て使えませんでした。
> 軟式さんの DOSVAXJ3 では使えていました。
> 
> ia32_x86	数字4桁の入力で、OE+2?? （??は数字によって変わる）エラーで止まる
> ia32_x64	数字4桁の入力で、OE+2?? （??は数字によって変わる）エラーで止まる


MS-DOS Player でも ia32版では16ビットのアプリでエラーが出ます。
なので、今は ia32版は使っていません。
VTDOS も、ia32 を使っているとしたら、ここに共通の問題があるのではないかと感じました。


#10157：turbo basic は VTDOSで動かない 　投稿者：konno 　 2022/01/15

> このプログラムを、VTDOS で動かしてみましたが、動きませんでした。
> エラーログを見てみると、ログが残っていました。
> 
> 2022-01-15 16:28:00 AISYO(17BA) 17CA:0EC8 'Out Byte 0043 34'
> 
> AX=2534 BX=0006 CX=0004 DX=1F10 SI=703A DI=7070 BP=17BA DS=17CA ES=0040 FLAGS=0046
> 
> CS:IP=17CA:0EC8
> 17CA:0EB8 2E F6 06 6E 34 40 75 13 50 E8 6D 27 B0 34 E6 43 
> 17CA:0EC8 EB 00 32 C0 E6 40 EB 00 E6 40 58 CF 50 FB 32 C0 
> 
> SS:SP=17CA:0072
> 17CA:0062 00 00 00 00 40 36 CA 17 46 00 CA 17 10 1F C4 0E 
> 17CA:0072 00 01 7B 03 CA 17 06 02 F6 01 CB 01 00 00 00 00 
> 
> 2022-01-15 16:28:00 AISYO(17BA) 17CA:0EDA 'Out Byte 0043 00'
> 
> AX=0100 BX=0006 CX=0004 DX=1F10 SI=703A DI=7070 BP=17BA DS=17CA ES=0040 FLAGS=0246
> 
> CS:IP=17CA:0EDA
> 17CA:0ECA 32 C0 E6 40 EB 00 E6 40 58 CF 50 FB 32 C0 E6 43 
> 17CA:0EDA FA EB 00 E4 40 8A E0 EB 00 E4 40 86 C4 F7 D8 40 
> 
> SS:SP=17CA:0072
> 17CA:0062 00 00 00 00 40 36 CA 17 46 00 CA 17 CA 17 BA 17 
> 17CA:0072 00 01 7E 03 CA 17 06 02 F6 01 CB 01 00 00 00 00 
> 
> 'Out Byte 0043 34'　と、'Out Byte 0043 00' の２つのエラーがあるみたいです。

このエラーが16ビットメモリ操作の裏技に由来するとしたら？
VZはメモリの裏技をバンバン使っているようですし。
 ia32 のメモリ管理は16ビットアプリの使用には問題があるとか？
メモリの自己書き換えなどを許さない仕様とか？

VTDOS では ia32 は使っていないというのであれば私の思い違いということで。m(__)m

野ざらし言#4654 に書きましたが、ここにも再掲します。

insfile.def を見てみると、ループ中に #B を使っていません。
としきさんが、#B が怪しいとにらんでいるのは正解かもと思い
製品版の [ESC]I マクロを修正してみました。


= esci.def =

製品版の [ESC]I マクロのバグ回避は、#B を使わないこと

*m


8  [ESC]I @I "I カーソル位置へ挿入"
	?. (mr==$80)?{ &m(36) . }
	&m("カーソル位置へファイルを読み込みます")
	n=wn, c=wc,
;	#R
	#R #m					;★ 直接ファイラーへ
:A	(s)?{ &c >A }
	(wc==c)? >Z
	mr=-1,
	&s
	#W &#T(n)
:B	#W &#T(c+1)
	#b #_ (ct)?{ #> #m #x }
;	#b #_ (ct|lh)?{ #> #m }		; #x は不要  T.Tanomura 94/01/05 15:48
:C
;	#y (mb)?{ #W #< #i (ek)?? #B #W >C }
	#y (mb)??>D				;★ ブロックでなければループを抜ける
	#W #< ek[+, #i ek], #W >C		;★ #B を使わない
:D	#C &#T(n)
	#< #i (ek)?? #B
	(wc>c)? >B
 	&d
:Z	&m("")

*


これで、今まで VTDOS153 で異常が出ていたファイルも正常に処理出来ました。
サイレントのままでも、試した全てのVZで問題なく動作しました。

結論として、#B にはバグがあるということですね。
そのバグは、VTDOS や NTVDM で出やすいようだというのが今の状況です。

更新した V_csr.def を使っていたら、PATHMENU.DEF に不具合が出てきました。
起動するたびにマクロバッファに新しく読み込まれる、つまり
多重起動状態になってしまったのです。

これは、V_csr.def の問題というより、PATHMENU.DEF の呼び出しの問題と思われます。
現在、VZ.DEF で

* E その他

1	vzfl+Extrmac+exmenu+vz2+PATHMENU

このようにインクルードしているのですが
VZFL.DEF では、コマンド部分に

	Q	>Q	;Pathmenu

として、マクロ呼び出しは

.:Q	&z("pathmenu") pn..37~.0-, >*	; pathbufクリア

このようになっていて、今まではこれで問題が無いと思っていたのですが
V_csr.def のような&c常駐マクロを使っていると、多重に起動してしまうようです。

そこで、以下のように修正しました。

;.:Q	&z("pathmenu") pn..37~.0-, >*	; pathbufクリア
.:Q	&Zs("pathmenu") (r)?? &z("pathmenu") pn..37~.0-, >*	; pathbufクリア
	
これで問題が無くなりました。
これが本来の呼び出し方なので、これからは手抜きをしないように心がけます。

追記
今まではインクルードしないとなにか問題があった気がしますが
この修正で、インクルードしなくて済むようになりました。

気分転換に「VZエディタ」で検索していたら、下記の記事を見つけました。

VZエディタ移植に当たって実施したことと成果。仮説(115) 
https://qiita.com/kaizen_nagoya/items/5551be98dcbed8f41949

ここの記事の中に

> NEC N5200というオフコンのDOS用に移植しました。

という VZを移植する話がありました。
有名な方なのでしょうが、お名前がわからなくて。

で、この方の移植の手法が、

> アセンブラを１行づつ註釈(comment)

> 画面の表示まで一応できた時点で、試験の意味を兼ねて、アセンブラのソースコードを１行づつ註釈にして、アセンブルし、リンクし、実行するという作業を繰り返しました。

これにはビックリしました。
それで私も初心に帰って、これを実践することにしました。


ソースの中で、add 命令後にキャリーオーバー処理をしていないと思える所

	add	[bp+si],cx
	jmps	tadj3

こういう所を

	add	[bp+si],cx
	jnc	cflg99			;★;; test
	mov	byte ptr [bp].atrtxt1,1	;★;; 変数 vn
cflg99:					;★;;
	jmps	tadj3

このように、キャリーオーバーなら 変数 vn を １ にするよう追加しました。
これでアセンブル、テストデータ実行して、vn が１になるまで繰り返しました。

数十箇所試して、vn が１になる所を見つけました。
ただ、ここは正常終了時にも１になることがあり、現在追試中です。

今後の課題は、もし原因箇所が特定できても、どう対策するか、かな。(^^;




追記


お名前がわかりました。

@kaizen_nagoya(Dr. Kiyoshi Ogawa)

小川清（おがわきよし）　さんですね。
 VZ倶楽部　に記事を書かれているようです。

> SF作家　高千穂遙、プログラマ　中村正三郎、マニュアル作家　西田雅明らとの連名。
> 出版記念パーティで初サインを有名人の関係者から求められた。
> 社長、著者、マクロ担当、マニュアル担当が、それぞれ３つ以上の筆名で書いている。
> 一つの筆名で書いているのでページ数が一人だけ多いように見えるのは誤解。

Wikipediaにもありました。
https://ja.wikipedia.org/wiki/VZ_Editor
^ NECのN5200への移植を書いたのは名古屋工業大学出身の小川清。 


チャレンジ精神の忍耐と勇気を頂きました、感謝します。m(__)m

> そんな昔から移植を！？
> ……と思ったけど，十年くらい使い込んだ頃なのでしょうかね。

パソピア１６用に改造したソースの日付は
1990/03/10  01:53             9,782 KEYIBM.ASM
1991/12/26  07:07            25,907 SCRNIBM.ASM

keyibm の変更はキーコードの入れ替えなので、90年ごろから弄り始めたのかな。
と思ったら、これは Ver1.53 のオリジナルソースのまま使えたようです。(^^;
1年半くらいで動く程度には移植できたようですね。

過去ログ #8486：Vz昔話 　投稿者：konno 　 2018/11/03
で詳しく語っていました。(^^;

> ひょっとして konno さんて T系の方だったのでしょうか。いや Dynabook 使ってると聞いたことはないものなぁ……

あれ？　J31 とは言っていたんですが、Dynabook とは言ってなかったかも。(^^;
職場でパソピア１６を使っていたので、互換性を考えて、PC98 よりも J3100 を選んだような。

> パソピアは最初に買うPCの候補のひとつだったのですが，嫌いな漫才師親子がCMやっていたので候補から落としたんですよね。当時は8ビットマシンがまだ多くて，それはMSXのだったかな。いずれにせよ買わなくてよかったのですが，16は手が出なかったなぁ……。

ああ、思い出しました。私はCM関係なく、パソピア１６のBASIC と互換性があると思ってパソピア７買いました。
互換性はあったんですが、プログラムのやり取りは外付け5インチFDDが必要で、高かったなぁ。(;_;)

> ところで，その漫才師がタクシー運転手に訴えられたことがあって，「昔で言えば『籠かき』やないか」という言動が差別発言だということだったのですが，『雲助』と言ったら差別なんだろうけど，『籠かき』は差別用語なんだろうか……と思ったものです。まぁ，どうせ後部から運転席を蹴り飛ばすくらいのことはやっただろうから，【言動】全般の問題だったのでしょうけど。

うーん、差別用語って、差別と考える人の頭の中に差別意識があるのかなと思っています。
まあ、悪意があってそういう言葉を使うから差別だと思うんでしょうね。

Chrome の monospace フォントに関するバグを回避する方法を，下記のサイト様で学びまして，
https://silight.hatenablog.jp/entry/2015/07/02/214601
うちの掲示板で試してみていたのですが，ようやく反映を確認できました。

monospaceフォントが使われることの多い要素に以下のような指定をすると，反映されます。

tt, code, kbd, samp, pre, xmp, plaintext, listing {
    font-family: monospace, serif;
}

うちの掲示板では，念のため以下のように明示的なサイズ指定も加えました。
tt, code, kbd, samp, pre, xmp, plaintext, listing {
	font-family: monospace, serif;
	font-size: medium; 
} /* Chromeはmonospaceのみの指定だとサイズが小さくなる */

うちの掲示板では，preを指定したアーティクルの背景色（薄墨）をつけているので，
Chromeで見比べてみてください。

これにより，個々の掲示板のソースでいちいちサイズ指定する必要はなくなります。
としきさんの仰るように，固定サイズ指定をバッサリ削ると自然な表示になると思います。

副作用のない指定方法を公開している，しらいと様に感謝。


なお，過去のブラウザの初期設定では，pre 要素などで小さなフォントが使われるのがふつうで，
これまでは特に疑問を感じていなかったのですが，konno さんのおかげで〈きっかけ〉ができ，
ブラウザ間の違いを改善することができました。

以前から，code や kbd などを指定した要素の表示がよろしくなくて気にはなってましたが，
おいおい解決していきたいと思います。

ありがとうございました。

> Chrome の monospace フォントに関するバグを回避する方法を，下記のサイト様で学びまして，
> https://silight.hatenablog.jp/entry/2015/07/02/214601
> うちの掲示板で試してみていたのですが，ようやく反映を確認できました。

このサイトを覗いてみたら理屈が判りました。

-------------------------------------------------
等幅フォントも可変幅フォントと同じサイズで表示したい時は次のように指定します。

font-family: monospace, serif;
これはmonospaceフォントで表示できない文字はserifフォントで表示するという意味ですが、そうなることは稀です。そして、このように等幅フォントと可変幅フォントを混在させた場合、可変幅フォントのデフォルトサイズが優先されます。（つまり可変幅フォントならserif以外でも良いです。単純に一番短いserifを選んだだけなので。）
-------------------------------------------------

なるほど納得です。

> うちの掲示板では，念のため以下のように明示的なサイズ指定も加えました。
> tt, code, kbd, samp, pre, xmp, plaintext, listing {
> 	font-family: monospace, serif;
> 	font-size: medium; 
> } /* Chromeはmonospaceのみの指定だとサイズが小さくなる */

これを入れてみたら丁度良い見栄えになりました。

> これにより，個々の掲示板のソースでいちいちサイズ指定する必要はなくなります。
> としきさんの仰るように，固定サイズ指定をバッサリ削ると自然な表示になると思います。
> 
> 副作用のない指定方法を公開している，しらいと様に感謝。

掲示板の全面改修は直ぐにはできませんが、本当に感謝ですね。

> なお，過去のブラウザの初期設定では，pre 要素などで小さなフォントが使われるのがふつうで，
> これまでは特に疑問を感じていなかったのですが，konno さんのおかげで〈きっかけ〉ができ，
> ブラウザ間の違いを改善することができました。

ブラウザ間の違いをほぼ無くせるとはまるで魔法のようですね。
私が気になっていたのは、等幅フォントのMSゴシックが線が細くて見えにくい
文字が読みにくいと感じたからです。そうとう目が悪くなったようです。
なので、等幅フォントはメイリオに変えました。