V9.18β5 - 秀丸エディタβ版 - スレッド10927, 2022/08/18

秀丸担当 さん　22/08/18 15:45

V9.18β5を公開しました。
通常版にもHideMath.dllを付属するようにしています。

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

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

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

RE:10927 V9.18β5

こみやんま さん　22/08/19 00:13

JavaScriptのwith文について、WebView2では存在しないと記載されていますが、
with文は一応存在するかとは思います。(非推奨であることは変わりません)

(ただし、機能する範囲は異なるかもしれませんね。)

jsmode "WebView2", 0;

js {
with ( hidemaruGlobal ) {
debuginfo(2);
console.log(x);
}

}

RE:10929 V9.18β5

秀丸担当 さん　22/08/19 11:25

WebView2でもwithは使えるのですね。
with自体はエラーにならないようですが、使おうとすると適用されていないように見
えて、使い方が違うのか、ちょっとよくわかっていないです。
何にしても推奨しない参考程度ということにしておこうと思います。

RE:10927 「"""」から始まる文字列

こみやんま さん　22/08/19 18:11

一応最低限は動作確認して動作してるっぽいことが確認できました。

ヘルプに4連引用符OKとありますが、そもそも引用符が
・3つ以上連続で続いている「同じ数の対」
　が機能条件するということを直感的に伝えるサンプルがあった方がよい気がしまし
た。

(私は事前に秀丸担当さんの投稿を見ていたので、
<hr>線のようなコメント線のようでいて、かつ Raw化を兼ねる
的な旨を知っていたのですぐ気づきましたが、
　多分ヘルプだけ見ただけの人は気づきにくいと思います。

ヘルプに乗せるような（あ、そういうことできるんか）と気づきやすいサンプル

$msg =
"""""""""""""""""""""""""""""""""""""""""""""
概要
日本海に面した海食崖で、険しい岩壁が続き、
最も高い場所で約25mの垂直の崖がある。
東尋坊を構成する岩は、輝石安山岩の柱状節
理で、これほどの規模を持つものは世界に３
ヶ所だけであり、地質上極めて貴重とされ、
国の天然記念物および名勝に指定[２]されて
いる。観光地として開発されており、遊歩道
や遊覧船、展望用のタワーや商店街などもあ
る。

地質
東尋坊は、今から約1,200 - 1,300万年前の新
生代(以下略)

"""""""""""""""""""""""""""""""""""""""""""""
;

message($msg);

個人的にはこういうのがR()よりは見やすくなりました。
#DLL = loaddll(hidemarudir + @"\hmPython3.dll");

#_ = dllfuncw(#DLL, "DoString",
""""""""""""""""""""""""""""""""""""""""""""""""""
from hmPython import hm

hm.OutputPane.Output("あいうえお\r\n");
lineno = hm.Macro.Var.lineno
hm.OutputPane.Output(str(lineno) + "\r\n");

""""""""""""""""""""""""""""""""""""""""""""""""""
);

freedll(#DLL);

RE:10927 よく書きそうな変数のV8系での防

こみやんま さん　22/08/20 00:23

ちょっとやってみた感じだと、概ね下記あたりに近いものがバランスとれそうです。

function ReadOnlyProperty(name) {
Object.defineProperty(
window,
name,
{
get: hidemaruGlobal[name],
set: function (v) {
if (typeof(v) == 'function') {
// 多分HidemacGlobalJSからの再代入でしょ...
return;
}
hidemaruGlobal.debuginfo(2);
let value = "";
if (typeof(v) == "number" || typeof(v) == "string" ) {
value = " " + v.toString() + " ";
}
let errormsg = `'${name}'関数を${typeof(v)}型${value}で上書きしよう
としました。\r\n`;
console.log(errormsg);
throw new Error(errormsg);
}
}
);
}

if (typeof ReadOnlySetted == 'undefined') {
ReadOnlySetted = 1;
ReadOnlyProperty("x");
ReadOnlyProperty("str");
ReadOnlyProperty("result");
ReadOnlyProperty("lineno");
ReadOnlyProperty("column");
ReadOnlyProperty("y");
ReadOnlyProperty("filename");
}

hidemaruGlobal.debuginfo(2);
var str = "abc";
var x = 3;
console.log(str);

RE:10934 よく書きそうな変数のV8系での防

こみやんま さん　22/08/20 00:32

> get: hidemaruGlobal[name],
は
get: function() { return hidemaruGlobal[name]; },
にしなきゃダメっぽいですね。

RE:10933 「"""」から始まる文字列

秀丸担当 さん　22/08/22 09:15

ご確認ありがとうございます。
"""は、インデントできるのが良いと思いますが、例を見て、というかインデント例
が無いのを見て、もしかしたらそれがうまくいっていないのかなと思いました。
空白だけの行であってもインデントが最終行と揃っていないといけないようにしてい
たのですが、「保存するときに行末の空白を除去する」によって除去されていると、
うまくいかないことがわかりました。
C#の仕様としてはどうかわかりませんが、空白だけの行であればできるようにしよう
と思います。
そういうことがわかるようなサンプルも記載しておこうと思います。

RE:10935 よく書きそうな変数のV8系での防

秀丸担当 さん　22/08/22 09:33

別スレッドからの続きですが、いろいろありがとうございます。
Object.definePropertyですごい細かい制御ができるのですね。
>x
>str
>lineno
>column
>filename
>y
>result

グローバル展開時はx,y,strに加えてこれらも書き換えできないようにしてみようと
思います。

RE:10927 読まれた.jsが自身の場所を知る

こみやんま さん　22/08/22 11:38

■読まれた側の.jsは自身の場所を知る必要あり

jsmode用の require の実装を試みてしていて気づいたのですが、

execjsにしろ、requireにしろ(requireは担当さんの方で作成されるかどうかはわか
りませんが)

「対象の.jsの実態のファイルはどこにあるのか」が、
読み込まれた.js側から知る手段が必要だと思いました。
(requireの方に関してはそのような情報を簡単にモジュール側に伝達するプロパティ
を追加することが簡単です)

■なぜなのか、具体例で

例えば、今比較的汎用的なライブラリがあるとします。

ライブラリ作成者Ａさんです。
ライブラリ使用者1000人が居るとします。

ライブラリ作成者Ａさんは、１つの機能として
good_libライブラリを作りました。

ライブラリは、１つの.jsファイルだけではなく、
・good_lib.js
・good_lib.json
・good_lib.dll
の３つで構成されているとします。

このライブラリの使用者1000人が意識するのは、あくまでも
good_lib.js のみであり、
good_lib.json や good_lib.dll はライブラリ使用者が使うものではなく、
あくまでもライブラリ作者Ａさんが、内部的に good_lib.js から
使うものだとします。

このライブラリは配置に制約もあります。
「上の３つのファイルは同じディレクトリに配置すること」という制約です。
このような制約はごく普通のことでしょう。

一方で「３つセットでの配置場所」は自由です。

汎用的であるほど、currentmacrodirectoryに配置されることはなく、
「マクロディレクトリ(macrodir)」のサブディレクトリあたりに配置するのが良い考
え方でしょう。

しかし、どこに配置するかは「ライブラリ使用者1000人」の自由です。
macrodir(のサブディレクトリなど)に配置する人もいれば、
hidemarudir(のサブディレクトリなど)に配置する人もいれば、
結局currentmacrodirに配置する人もいることでしょう。

・1000人のユーザーは以下のようにこのライブラリを読み込んだとします。

　execjs "ほげほげパス/good_lib.js";

・さて、ライブラリ作者Aさんは、どうやって good_lib.dll や good_lib.json を読
み込めばよいのでしょうか。
　「ほげほげパス」を認識することなしに、ライブラリ作者A さんは good_lib.dll
や good_lib.json を読み込むことが困難です。

　jsプログラムが実行できているのに、ほげほげパス/good_lib.jsの場所をさらに、
別途設定するのでしょうか。
　それはおかしな話となります。

■以上のようなことを想定すると、
「読まれたJS」は自分自身でそのパスを知ることができる必要性があるかと思います。
　execjsをすると、それをされた側の.jsは、その.js内で
何かのプロパティか関数を実行すると、
自分自身のパスを引き出せる、といった必要性があるかと思います。

RE:10938 読まれた.jsが自身の場所を知る

秀丸担当 さん　22/08/22 16:09

現在のjsのある場所がわかる方法もあったらいいと思います。
作り方次第ではなんとかできるとは思いますが、JavaScriptでないほうの、execjs文
であればcurrentmacrodirectoryのように、currentjsdirectoryとかあってもいいか
もしれません。
js{}内のexecjsは、ちょっと緩いというか、一応サポート範囲内には入れていなくて、
ただevalしているだけになっています。
js{}内では、hidemaru.loadTextFileさえあれば、緩いなりに自由にできると思いま
すが、execjsの存在がまぎらわしいということになるとjs{}内では使用できないよう
にしてしまったほうがいいかもしれないです。
とりあえず、execjs文のほうのcurrentjsdirectoryを検討します。

RE:10939 読まれた.jsが自身の場所を知る

こみやんま さん　22/08/23 11:04

>現在のjsのある場所がわかる方法もあったらいいと思います。

require モジュールを秀丸マクロライブラリに登録してみましたが、
若干 js だけで実装するのは、エラースタックやエラー時情報などを考慮すると
無理気味だなぁと思いました。

(hmJSやhmV8は本体側でrequire処理するから比較的安定したエラーが出せますが、
jsだけでrequire作ると、まぁこうなりますねw)

RE:10940 読まれた.jsが自身の場所を知る

秀丸担当 さん　22/08/23 15:08

requireをアップされたとのことで、何かしら使えそうですね。

js内のexecjsは、まぎらわしいので、無くしてしまおうと思います。
execmacroと似た感じの名称から、先頭実行ではなく例えばmenu()からの振り分け実
行とかに使いたくなってしまいますが、実行ネストやスコープが全然違うので、混乱
しそうです。
js外のexecjs文だけにしようと思います。
キーワードはやっぱりjsファイル名で、currentmacrofilenameやWScript.ScriptFull
Name相当の、currentjsfilenameにしようと思います。

RE:10941 秀丸マクロのexecjsにrequireに

こみやんま さん　22/08/24 10:43

今回アップした require では、
currentmacrodirectory 他、[macrodir]/jsmode_modules/*** とかいくつかの場所を
検索するのですが、

require("dumper"); ⇒
① currentmacrodirectory + \\ + dumper.js
② macrodir + \\jsmode_modules\\dumper.js
③ macrodir + \\jsmode_modules\\dumper\\dumper.js
④・・・
⑤・・・

秀丸マクロのexecjs も
❝末尾に.jsも何もない、/や\も無いシンボルだけ書けば❞
ここを読み込みますよ、と決め打った方が、
自然と提供者・利用者ともに、いろいろと整理された場所に格納ように思えました。
(使用者・提供やともに知らず知らず整理してライブラリ的なものを
　適切なフォルダに格納するようになる)

例えば、
秀丸マクロのexecjsで
execjs currentmacrodirectory + @"\abcde.js" みたいに
ちゃんと拡張子があるパスで記述した場合は、これまで通りの挙動になるようにし、

(実際には、execjsの引数のファイルパスが、ファイルパスとしてexistsであるとい
う判定）

一方で
execjs "abcde"; とした場合、末尾に拡張子が無くシンボルのみの場合、

①currentmacrodirectory + "\\" + abcde.js
②macrodir + "\\" + jsmode_modules + "\\" + abcde + "\\" + abcde.js

の２箇所のみを対象とする、とexecjsの仕様を決めるというものです。

（
　あちこちグダグダ場所を増やすのではなく、
　・カレントマクロ(currentmacrodirectory)の場所[一番強い]
　・ライブラリの場所
　と配置場所を絞ることが重要です。

　・ライブラリの場所は、複数のライブラリが同一ファイル内に存在すると整理が難
しくなりますので、
　　１ライブラリが１フォルダに入るような(上のような例)にしておくことが大切で
す。

　・誤爆を避けるため、「カレントマクロディレクトリではない、ただのカレントフ
ォルダ」の場所にあるものはシンボルだけでは読みませんよ、とすることも重要です。
）

こうすれば自然と、「どこにあるかとか考えることもなく」
・dumperライブラリ入れたんですよね？だったら

execjs "dumper"; で読み込めるようになります。

これは自然と、Aのライブラリは、他者制作のBのライブラリに依存したマクロも記述
しやすくなりますし、提供もしやすくなるでしょう。

（いちいちライブラリの.js の場所に合わせて書き換えてください、などと言わな
くてよくなっていくからです）

RE:10927 console.dir を提供した方がよさ

こみやんま さん　22/08/24 11:01

こんかいマクロライブラリに dumper をアップしましたのですが、
Dumper.stringify(...)
Dumper.dir(...)

さて、ほぼ全てのJSが走るブラウザには「console.dir」という関数があり、
JavaScriptの値やオブジェクトを調査する目的で使用します。
その実態は何なのか、もしプロパティなどがある「オブジェクト」であるなら、
プロパティはどう構成なのか、などGUI上で確認することが出来ます。

jsmode には console.dir は今は実装されていませんが、
Dumper.dir と比較的近いような(JSONに相乗りする)実装で、console.dir を提供し
た方がいいと思いました。

RE:10942 秀丸マクロのexecjsにrequireに

秀丸担当 さん　22/08/24 16:07

requireでは自由にしてもらっていいですが、execjs文は、複数の場所を調べたり固
定のサブフォルダというのはどうかと思います。
execjs文はライブラリとしてではなく、実行本体であってもいいです。
例えばexecmacroの振り分け実行的に、以下のような感じもありです。
menu "1","2";
#r=result;
if(#r==1){
execjs "1.js";
} else if(#r==2){
execjs "2.js";
}

これをjs{}内でexecjs()でやるのは無しで、無くそうと思いますが、js{}外ではあり
なので、フルパスでない場合でも１つの場所を指していることにしたほうがよさそう
です。

RE:10943 console.dir を提供した方がよさ

秀丸担当 さん　22/08/24 16:08

console.dirというのもあるのですね。
せっかくこみやんまさんが作られたということで、それでようさそうな気もしますが…
ちなみに書き換え禁止候補とした１つの、lineno()の中身を見るのはエラーとなる予
定です。

いままでのマクロでできることはそろそろにして、受動的というか非同期で操作する
場合も考えるべきと思っているのですが、V9.18でするか考え中です。WebView2のイ
ンスタンスはマクロ実行後も残していて、マクロ実行中でないときの何らかの操作を
するとしたらマクロ実行空間も何もないので、eval系ではなくexecmacro系というか、
WM_REMOTE_EXECMACRO_FILEなどのような、呼ぶ側の立場になってやる感じになりそう
です。

RE:10945 console.dir を提供した方がよさ

こみやんま さん　22/08/24 18:21

> lineno()の中身を見るのはエラー
う～ん、中身を見るだけでもしも「ダイアログを伴うエラー」だとしたら、
いろいろと微妙になる気がします。

linenoと直接書くだけでなく、
for in でhidemaruGlobalを回して出力するなども全部エラーになってしまうので、
プラスよりマイナスの方が目立つと思います。

今、windowオブジェクトとかがAccess Deny オブジェクトを一杯もっているのですが、
必ずダイアログを伴うエラーになるので、結構取り扱いにくいです。

とはいえ、「元々キーだったものが関数になったもの」、
例えば、currentmacrodirectoryやlinenoやxなどは、
強烈な入力支援機構があったとしても入力段階ではエラーも警告もでないので、
エラーにしたいというのはわかります。

個人的には、「ダイアログは伴わない」がアウトプット枠とOutputDebugString に
「debuginfo(2)していなかったとしても」
警告として出す、あたりでいいかと思います。

RE:10946 console.dir を提供した方がよさ

こみやんま さん　22/08/24 19:28

>非同期

■hm.NET(やhm.CppInvoke/hm.NetCOM)では、
・Hm.Macro.Exec.Method
　https://xn--pckzexbx21r8q9b.net/?page=nobu_tool_hm_dotnet_started_macro_method
・Hm.Macro.Exec.File (担当さんが投稿してるSendMessgaeでWM_REMOTE_EXECMACRO_F
ILE が実態ですね)
・Hm.Macro.Exec.Eval(同じくWM_REMOTE_EXECMACRO_MEMORY)

と言う形で、非同期の口を整理して実装しました。

C#は「イベントハンドラー」の概念が言語やライブラリに
色濃く反映されているため、
「dllとしてプロセスに張り付いて、しかも一度張り付くと解放が実質不可能でハズ
れない」関係上、
「ボタンを押したら○○するとか、書き換えられたら△△するとか」
そういうことをしたいよね、といったことで用意しました。

■一方スクリプト系のもの(hmPythonやhmJS)は、Webだとリスナーなどでイベンド駆
動タイミング等の取り扱うものの
秀丸の場合「自動実行マクロ」があることと、「マクロ実行枠は、全プロセスで合わ
せて１つ」しかない関係上
非同期系の口は用意せず、「同期実行」「Once実行」を旨としました。
(混乱しか呼ばないと判断した側面もあります）
しかし、後片付けだけはしたいかもしれない、ということで、DestroyScopeを
コールバックとして用意しました。
(本当はAddDestroyScopeHandlerにするべきだったですが、まぁ
基本は各人の個人使用を出ないだろうから大丈夫でしょう）

■jsモードで非同期呼ぶならば,,,
　非同期で呼ぶといっても、実態としては、呼び出しタイミングだけ非同期で、
　実行としては同期となるハズです。
　(もとが実行枠が１つしかないのですから、同期でないとマクロ空間上の関数を機
能させるのが難しいハズなので）

　・１つはあらかじめエディタならではの「イベント名」を決めておき、
　　a) イベントハンドラー(addEventLisner/addEventHandler)といったようなもの
で、「処理関数」もしくは「処理ファイル」を登録するというものでしょうか。

　　　　例えば、「編集ペインのファイル名が変化した時」とかだと addEventHandl
er(あるいは、addEventListener などといった名称で

hidemaru.addEventHandler("OnChangeFileName", myChangeFileName); // m
yChangeFileName = function(newFilePath)

hidemaru.addEventHandler("OnProcessClosing", myProcessClosing); // O
nProcessClosing = function(closingReason)

hidemaru.addEventHandler("OnProcessClosing", currentmacrodirectory()
+ "\\OnProcessClosing.js");

　 b) 上のような「サイトー企画側から与える規定のイベント駆動名」だけでなく、
ユーザーが条件を決める、
　　　といったようなところをしたいところですが、

　　　「非同期の間は、秀丸マクロのhidemaruGlobalの関数は使えなくなる」「マク
ロ実行枠は全プロセスで合わせて１つしかない」ことを
　　　考えると、
　　　「駆動条件自体の記述にどの関数が使えて、どの関数が使えないのかよくわか
らない」といったことになるような気もします。

　c)　特定の条件によらない、例えば、Tickのようなものもあって良いかもしれません
hidemaru.addTickEventHandler(3000, myTickEventHandler); //
　　　しかし、現実的な使用感としては、このTickの度に「秀丸マクロ用の関数使用
可能に切り替えるため同期モード」になるので、、
　　　なにやら「引っかかりが有るんだけれども...」になりやすいんじゃないかと
思います。

RE:10944 秀丸マクロのexecjsにrequireに

こみやんま さん　22/08/24 20:05

>これをjs{}内でexecjs()でやるのは無しで、無くそうと思いますが、js{}外ではあ
>りなので、フルパスでない場合でも１つの場所を指していることにしたほうがよさ
>そうです。
フルパスでない場合は、「カレントマクロディレクトリ」といったことにするのが無
難かと思います。
「カレントフォルダ」を対象としてしまうと、意図してない誤爆が多くなってくるか
と思います。

RE:10947 非同期とイベントハンドラ

こみやんま さん　22/08/24 20:57

hidemaru.addEventHandler("OnChangeFileName", myChangeFileName); // myChangeF
ileName = function(newFilePath) だと文字列で入力補完も定義ファイルも作れなく
なるので、

hidemaru.addEventHandler(hidemaru.onChangeFileName, myChangeFileName);

みたいな感じで文字列ではない方が良いですかね。

又、myChangeFileName など、イベントハンドラの受け口の関数の引数は、全て１つ
の「イベントプロパティを格納したオブジェクト」を引数にとるようにして、

hidemaru.addEventHandler( hidemaru.onChangeFileName, myChangeFileName );

function myChangeFileName(e) {
var = e.fileName; // それぞれのイベントハンドラの e がなんのプロパティを
持つかは秀丸マクロのマニュアルで記載していく

// 処理処理
}

とかの方がやわらかいでしょうか。
多くの一般的なイベントハンドラの記述方法にも通ずるものがあるかと思います。

RE:10949 非同期とイベントハンドラ

秀丸担当 さん　22/08/25 11:48

linenoを見るのは、JScriptではネイティブでする都合があるのですが、どこまです
り替え可能かという意味も込めて、そういう文字列（"function..."）を返すプロパ
ティでやってみようかと思います。

非同期というのは、イベント登録とかもできたらできたでいいとは思いますが、検討
するべきと考えているのはJavaScriptとしてPromiseとかasyncとかあるので、それを
扱ったときのことになります。
WM_REMOTE_EXECMACRO_FILEに相当することだと、自身の入れ子ネストで呼ぶようなこ
とになりWebView2はそれを禁止していてるようでした。実行をスケジュールしてする
といいらしく、remoteExecMacroFileではなくpostExecMacroFileみたいな感じでやっ
てみようとしています。

RE:10950 非同期とイベントハンドラ

こみやんま さん　22/08/25 16:33

> 検討するべきと考えているのはJavaScriptとしてPromiseとかasyncとかあるので、
>それを扱ったときのことになります。
async/await の方ですか。

C#のhm.NET方だと、上に書いた、Hm.Macro.Exec.Methodや
とかが「async中」にそれらのメソッドに「C#メソッド」を渡す、と
その「渡されたメソッド内」だけ同期（というかメインスレッドというか、
秀丸マクロ関数が使える）ような感じにしていました。

jsでも同じような感じでいいんではないかと思う一方で、

「JavaScriptの変数」は「マクロ終了の時間を超えて」生き残っていたとしても
「秀丸マクロ変数」は原則Onceだから消えてしまっていますので
Jsだと、Hm.Macro.Exec.Method よりも Hm.Macro.Exec.File 側、
秀丸担当さんの投稿でいう postExecMacroFile みたいな感じの方が
違和感が少ないかもしれないですねぇ。

ん～とはいえ、JSだと、async書いちゃうと、どのみち
そのasync関数実行にメインスレッド（同期の方の)jsとマクロ終焉を
迎えてしまって、
「関数の途中途中までhidemaruGlobal使えてたのに、途中から
　いきなりエラーが出た」みたいな謎に思える現象になるんじゃないか、
　と思ったりするのですが...

結局 await をかますようになるような？

RE:10952 非同期とイベントハンドラ

こみやんま さん　22/08/25 17:27

> 実行をスケジュールしてするといいらしく、

そういえば、秀丸マクロ自体を１つだけ(２でもギリOKかな？)Queue予約みたいな
仕組みがあると、全プロセスで１つのマクロしか実行できない
という制限がある程度緩和されるのではないか、と思っていました。

秀丸の設定に
===================================================
[o] マクロ実行中に、あらたなマクロを実行しようとした時、そのマクロを予約する
(最大枠は予約２個まで）
　　　最大待機時間 (2000ミリ秒) ← 500ミリ秒～3000ミリ秒まで可変
===================================================

みたいな「マクロと衝突した時」「次のマクロをまちいますよ」といった機能を設け
るのはありだと思いました。

RE:10952 非同期とイベントハンドラ

こみやんま さん　22/08/25 18:37

あれ、9.18 β2だったかβ3 だったかまではトップレベルで await 使えましたが、
β5はトップでawait 使えないですね。
トップでawait使えないと、asyncを書いてもwaitする場が無いような？

エラー出すために、jsmodeが全体的にevalで囲むようになってしまったから
こうなったんでしょうか。う～む？