V9.19β10No.11025
秀丸担当 さん 22/09/14 16:11
 
V9.19β10を公開しました。
V9.19はあまり追加せずいったん落ち着かせる方向にしたいと思っているのですが、
また追加や変更をしてしまっています。

以下のページの「先行開発バージョンはこちら」からダウンロードできます。
https://hide.maruo.co.jp/software/hidemaru.html

32bit版:
https://hide.maruo.co.jp/software/bin3/hm919b10_signed.exe

64bit版:
https://hide.maruo.co.jp/software/bin3/hm919b10_x64_signed.exe

[ ]
RE:11025 searchoptionの fEnableSearchOpNo.11026
こみやんま さん 22/09/15 16:36
 
searchoptionの fEnableSearchOption2の
#fEnableSearchOption2 = 0x80000000 は intに収まってない

ヘルプにある 0x80000000 はintに収まっていません。

秀丸マクロの場合、ビットをそのまま対象のマクロのintptr_tのビット並びで解釈す
るので、問題はないですが(それでもint32_tを超えた値を指定しているので、例とし
ては若干不適切には見えてしまいますが、64bitでも同じ0x80000000でしょうから仕
方がないのかも?)

jsでは、スリ潰れているのではないかと思います。


#a = 0x80000000;
message(str(#a));

js {
var test = "あいうえお\r\n";
setVar("#b", 0x80000000); // これが(setVar(...)の段階で擦り潰れるのであれば、
#fEnableSearchOption2 = 0x80000000 との論理和などを渡すhidemaruGlobal内のい
くつかの関数はそのオプションを機能させうるとは思い難い...
var c = getVar("#b");
message(c);

}

message(str(#b)); // 0になってる... この伝達状態ではjsからはおそらく機能して
いないのでは...?

[ ]
RE:11026 searchoptionの fEnableSearchOpNo.11027
秀丸担当 さん 22/09/15 18:06
 
確かに32bitの最上位ビットだけの場合、setVarはマイナスかプラスかによってうま
くいかないことになってしまいました。
setVarはどのエディションでも差異無く32bit(符号付き)ということになっているの
で、最上位ビットだけを渡す必要がある場合は、何らかの別の方法にするしかないと
思います。

js上で明示的に0x80000000だけを指定したいという場合は問題なさそうでした。
setsearch("test",0x80000000);

明示的に0x80000000指定ではなく、何が入っているかわからないけど、とにかくsear
choptionを変数でsetVarで渡したいという場合は、0x80000000にはならない(必ず0x
3800がある)ので、よほどのことがなければ問題になることは無いと思います。


[ ]
RE:11027 searchoptionの fEnableSearchOpNo.11028
秀丸担当 さん 22/09/15 18:24
 
>searchoptionを変数でsetVarで渡したいという場合は、0x80000000にはならない(必
>ず0x3800がある)ので、よほどのことがなければ問題になることは無いと思います。

と思ったのですが、マイナスと扱われるかどうかだけでよくて、0x3800はあってもな
くても同じでした。
なので、どっちにしてもsearchoptionをsetVarを渡すことはできるようでした。

[ ]
RE:11028 searchoptionの fEnableSearchOpNo.11029
こみやんま さん 22/09/15 18:30
 
渡す時には、javascriptの「数値」を「数字」にして、そのままevalしているので、
セーフ(ビットの並びはjsではなく秀丸マクロが処理するから)で、
一方、マクロからjsに返ってくる際は、
すでに秀丸によって32ビットに収まる値(0x80000000なら-0x80000000)になって渡っ
てくるからよく考えればセーフなんですかね?

(32bit同士は大丈夫だけど、秀丸エディタ64bit⇒jsは返りし大丈夫なんだろうか...)

(うーむ、ぎりぎりの実装な気配ですが、現状たしかにセーフっぽいです)

[ ]
RE:11029 searchoptionの fEnableSearchOpNo.11030
こみやんま さん 22/09/15 19:59
 
秀丸マクロの方ですが、
64bit版の方は、ビット自体は足りていますが、
32bit版と互換にするため、
searchoption 相当の引数を受け取るものは、
-0x80000000 相当のビット部分の符号を反転させて 0x80000000 にしているように思
えます。

setsearch "abc", -0x80000000, 0x00000001;
// setsearch "abc", 0x80000000, 0x00000001; と同一になってると思われる。

if (searchoption > 0) {
    message("反転する");
}

ということは、(他がプラス値の)OR演算しかしないため、(どんどん数値が大きくな
る一方なので)
var fEnableSearchOption2 = -0x80000000

にしておけば、32bitでも64bitでも、値を別空間へと橋渡ししていくさいでも大丈夫
なのかなーと思いました

[ ]
RE:11030 searchoptionの fEnableSearchOpNo.11031
秀丸担当 さん 22/09/16 10:08
 
JavaScript上の数値の-0x80000000は、setVarできる最小値と同じになって、そこか
ら | 0x123とかしても通用するようでした。
-0x80000123はできないので、ちょっと混乱しそうではありますが、1つの解決策に
はなると思います。

いろいろ回避策を考えるより、0x40000000のビットが最後に空いているので、もし問
題があったらこれを使ってしまった方がいいような気もしてきました。
今後何か増やすような場合、最上位ビットを使うのはなるべく避けるようにしようと
思います。

[ ]
RE:11025 hidemaru.getInputStates()は...No.11032
こみやんま さん 22/09/16 23:45
 
hidemaru.exeのネイティブ用の関数としても用意したほうがいいかなぁと思います。

Hidemaru_GetInputStates()

こういった役割の関数を一番上手く利用できるのは、非同期の
スレッドから状況を監視して、何かを満たしていたら、
それに応じたアクションをすることでしょうし。


[ ]
RE:11025 V9.19β10No.11033
こみやんま さん 22/09/17 02:17
 
refreshtabstop_pause を JSの関数へと移植しやすれているのではないかと思います。
()

[ ]
RE:11033 V9.19β10No.11034
こみやんま さん 22/09/17 02:22
 
enablebreak 文をJSへと移植しやすれているのではないかと思います。

[ ]
RE:11034 V9.19β10No.11035
秀丸担当 さん 22/09/20 13:08
 
Hidemaru_GetInputStatesもあったほうがよさそうです。
追加しておこうと思います。
不足の点のご指摘もありがとうございます。
修正しておきます。

[ ]