入力補完時に呼ばれるコールバック用の.dl - 秀丸エディタマクロ作者会議室 - スレッド08194, 2016/08/15

入力補完時に呼ばれるコールバック用の.dl

天翔記jp さん　16/08/15 17:20

こんにちわ。
秀丸マクロ.net の天翔記.jp です。
(一体どちらがドメインでどちらがハンドルなのか…）

秀丸の入力補完ですが、入力補完内容をダイナミックに変更するのが
非常にやりにくいと考えています。

入力補完と強調表示とは、

①事前に決め打たれている定型的な変数・関数・メソッド・予約語

②正規表現などを利用した状況証拠から割り出せる、(大抵は不完全ならがも)入力を
サポートする、もしくは、間違った入力を判定する

③抽象構文木構造（普通は会話ではASTと言うと思います。Abstract Syntax tree)

の３本柱で構成されます。

秀丸では①②は、辞書や協調定義ファイルで機能を達成することが出来ますが、
③による入力補完単語のダイナミックな追加を、秀丸へと伝達することが非常に困難
です。

強引なまでにマクロを使えば出来なくはないです。
しかし、「マクロ実行スロットが１つ」の秀丸では、その性質上、
「入力補完」といった「編集行為中、頻繁に実行する基本的行為に属すモノ」にはマ
クロを割り当てると、
当然、「時間のかかる他マクロ」を実行中の際、マクロ衝突が発生し、
入力補完(どころか入力自体も)ままならない、といった事態となります。

そこで、提案なのですが、「変換モジュールライブラリ」と同様に、
入力補完時に候補を操作するための専用dllライブラリがあれば便利かと思います。

ご検討ください。

RE:08194 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/15 17:33

ちなみに、このような要望の発端となっている理由ですが、

機能を作っても速度の点やマクロ衝突の点で実用には至らなかったためです。

又、ここ数年、ASTも含めた入力補完のための仕組みが
どんどんオープンソースで外部プロセスの形で提供されはじめてきていることもあり
ます。

Clangしかり、OmniSharpをはじめとするOmni系列しかりです。

ご検討のほどよろしくお願いします。

RE:08194 入力補完時に呼ばれるコールバッ

でるもんたいいじま さん　16/08/15 18:36

でるもんた・いいじまです。
また今度も話が高度になっていきますねぇ…^^

> 秀丸の入力補完ですが、入力補完内容をダイナミックに変更するのが
> 非常にやりにくいと考えています。
>
> 入力補完と強調表示とは、
> ①事前に決め打たれている定型的な変数・関数・メソッド・予約語
> ②正規表現などを利用した状況証拠から割り出せる、(大抵は不完全
> ならがも)入力をサポートする、もしくは、間違った入力を判定する
> ③抽象構文木構造
> （普通は会話ではASTと言うと思います。Abstract Syntax tree)
> の３本柱で構成されます。
> 秀丸では①②は、辞書や協調定義ファイルで機能を達成することが
> 出来ますが、

ここまでは分かりました。

> ③による入力補完単語のダイナミックな追加

ここがピンときません。具体的に「どういう入力があったとき」に、
「どんな候補」を補完候補にするのでしょうか？
具体例をいくつか挙げていただけないと、この4番会議室の参加者と
いえど、なかなか理解できないと思います。

私の思いつくところでは、拡張子 .c ないし .cpp のファイルで
「int main」と入れると「(int argc, char **argv) {」が出て
そこで改行・タブまで補完される、という例題がありそうですが、
もしかして全く的を外していますか？

> 強引なまでにマクロを使えば出来なくはないです。
> しかし、「マクロ実行スロットが１つ」の秀丸では、その性質上、
> 「入力補完」といった「編集行為中、頻繁に実行する基本的行為に
> 属すモノ」にはマクロを割り当てると、
> 当然、「時間のかかる他マクロ」を実行中の際、マクロ衝突が発生し、
> 入力補完(どころか入力自体も)ままならない、といった事態となります。

ちょっとここのところの説明ももう少し具体例で詳しくお願いします。

> そこで、提案なのですが、「変換モジュールライブラリ」と同様に、
> 入力補完時に候補を操作するための専用dllライブラリがあれば
> 便利かと思います。

う～む。
この機能を追加してもそれだけでは、自分でDLLを作れる超ヘビー
ユーザーしか喜ばないように思います。DLLに渡される文字列は
秀丸の内部コードでしょうから、DLL側では8bit文字列型の配列を
ゴリゴリと操作する羽目になりそうです。

それに、大抵の人は
　・Visual Studio…買うだけのお金がない
　・MinGW…たくさんあるモジュールのどれを取捨選択すれば
　　いいのかわからないので、インストールが大変
というのが実情だと思います。

あるいは、
　1.変換モジュールのように汎用のDLLを誰かが用意する
　2.補完機能パッケージを作りたい人は、ASTを何らかの文法に
　　則って記述して、そのDLLの初期設定関数に渡しておく
　3.秀丸に文字が1文字加除されるたびに、そのDLLの特定の
　　関数が呼び出され、ASTに従って補完候補を返す
という使い方であれば「補完機能パッケージを作りたい人」はAST
だけを書けばよくて、C/C++コンパイラをインストールする必要も
なければ、七転八倒してポインタ操作をする必要もなくなります。

…が、そうすると、じゃあそのASTを記述する文法はどう設計するの、
という話になります。そこまで行くとマクロ言語をもうひとつ
ゼロから設計し直すことになって、車輪の再発明になります。

ちょっともう少し細部を詰めてみる必要がありそうです。

☆　☆　☆

以下、少しだけ不躾なお願いをお許しください。

前回の「ヒアドキュメントが使えるようになりませんか？」という
ご要望のときにも感じたのですが、具体的にこういうコードを入力
する際に不便でしょ、そういうときに秀丸がこう動いてくれたら
今までにはなかったこんな便利なことがあるでしょ、という具体例を
しっかり出していただければ、もっと他の人も話に乗ってこられる
のにな、と残念に思います。

そもそも、ここに集う人のほとんどは「プログラミング言語の開発で
生計を立てている人」ではありません。

ですので、
> Clangしかり、OmniSharpをはじめとするOmni系列しかりです。
と書かれても私には、
　　・「Clang」…オープンソースのCコンパイラで、最近の
　　　　FreeBSDとかでGPL汚染品排除の動きに呼応してシェアを
　　　　伸ばしているプロジェクト。
　　・「Omni系列」…オムライスの親戚？
という程度しかわかりません。

というわけで、申し訳ありませんがもう少し丁寧に「具体的にどんな
場面でどんな結果が出ることを望んでいるのか」を噛み砕いて説明
していただければ嬉しいです。その際の読者のレベルとしては、
「VBAでWord/Excelを少し便利に使うことくらいはできるけど、
C言語の配列・文字列の扱いの危うさ（バッファオーバーフローが
なぜ機械語コードのインジェクションにつながるのかとか）はよく
分からない」という程度のレベルの人を想定して書いていただければ、
この4番会議室の読者には確実に伝わると思います。

ちなみに前回のヒアドキュメントの場合、私が「これなら多少手間を
かけても複数行文字列を実装するだけの価値があるな」と考えを
改めるようになった決め手は、「複数行文字列の始まり・終わりの
キーワードと強調表示パターンとを関連付けておけば、当該複数行
文字列の内部をその関連付けに従って強調表示できる」という点でした。

RE:08197 入力補完時に呼ばれるコールバッ

h-tom さん　16/08/15 20:18

h-tom です。

ここだけ
>　・Visual Studio…買うだけのお金がない
今は、Visual Studio Community や、 Visual Studio Express(for Desktop)
があるので、開発環境を手に入れるのは無料で可能ですよ。

RE:08197 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/15 21:04

入力補完関係のマクロを作成したほとんどの人が
非常に苦い思いをし続けてきたことと思うのですが、

例えば、
メタな例だとして(言語でなくともxmlなどでもいいのですが)

import MyButton;

class MyClass {
publc MyButton bi;
}

MyClass().bi.

ここまで入力した時、現状の秀丸では「bi.」の続きを補完するのが困難です。
しかし、bi.を押したとき、「なんと補完すべきか」は秀丸が考える必要はありません。
マクロ作成者が考える必要すらもありません。

現代では、エディタではなく、外部のツールに問い合わせればいいだけです。

外部のコンソールツールに、「今のファイルの全体の文字列」「今のカーソルの位
置」「プロジェクトに属してるならプロジェクトなど」を
伝達すれば、MyBuffonがソースだろうとマネージドなバイナリだろうと、
「高精度でこれこれこれが補完候補だよ!」とリストを返してくれるのです。

ですから、SublimeText, ATOM, VSCode, Vim, Emacs あたりは、
２年前あたりから、続々と導入していき、ここ数年で補完精度が
急上昇しました。

必要な機構としては比較的単純で、入力補完の際に、
・編集中のソースとカーソル位置等を、外部コンソールツールに伝えられるか
です。

これだけ聞けば、「マクロでやれるんじゃないの？」となります。
実際マクロでやれます。
やれますが、「マクロではやるべきではナイのではないか」ということ申し上げてい
るのです。
(理由は最初の投稿で記載した通り。マクロでやっても不具合や衝突の嵐なので使わ
なくなるだけだから。)

あと、余談でどうでもよいことですが、
VSは格安ですし「個人開発」や「売り上げ少ない小小企業」ではPro相当(10万相当)
が無料ですよ。

RE:08200 入力補完時に呼ばれるコールバッ

でるもんたいいじま さん　16/08/15 23:11

でるもんた・いいじまです。

> import MyButton;
> class MyClass {
> publc MyButton bi;
> }
> MyClass().bi.

> bi.を押したとき、「なんと補完すべきか」は秀丸が考える必要はありません。
> マクロ作成者が考える必要すらもありません。
> 現代では、エディタではなく、外部のツールに問い合わせればいいだけです。

なるほど。今はそういう仕組みがあるのですね。

> 外部のコンソールツールに、「今のファイルの全体の文字列」「今の
> カーソルの位置」「プロジェクトに属してるならプロジェクトなど」を
> 伝達すれば、MyBuffonがソースだろうとマネージドなバイナリだろうと、
> 「高精度でこれこれこれが補完候補だよ!」とリストを返してくれるのです。

ファイルの中身全部を投げるのは個人的には怖いなあ…当然SSLで通信
するんでしょうけど、企業秘密の混じったコードは万一のことを考えると
投げられないですね。
＃それでもやりたければLANの内部に専用サーバを立てるんでしょうけど。

> ですから、SublimeText, ATOM, VSCode, Vim, Emacs あたりは、
> ２年前あたりから、続々と導入していき、ここ数年で補完精度が
> 急上昇しました。

2年くらい前ですか…確かにそのへんの時期の最新事情には詳しくないです。

> 必要な機構としては比較的単純で、入力補完の際に、編集中のソースと
> カーソル位置等を、外部コンソールツールに伝えられるかです。
> これだけ聞けば、「マクロでやれるんじゃないの？」となります。
> 実際マクロでやれます。
> やれますが、「マクロではやるべきではナイのではないか」ということ
> 申し上げているのです。

これですけど、私は「マクロでやる『べき』」だと考えます。
理由は、費用対効果が見合うとは今のところ思えないからです。

この例でいうと、「MyClass().bi.」のピリオドを打った瞬間に自動的に
ファイルの中身全部とカーソル位置をサーバに送るということは、
システム設計上の絶対条件ではありません。何かのキー、たとえば
Ctrl+Enter（タブキーは迂闊に使えませんので）を押したときに初めて
問い合わせを投げるほうがネットワーク負荷も少なくなります。

たとえば「MyClass().bi.」のあとメソッドなりプロパティなりの名前と
して「abcde」と5文字入れたときに、1文字ごとに毎回勝手にテキスト
全文が流れるのは不経済で、入力速度ダウンにも直結します。

＃私の場合、Googleの検索ページで1文字入れるごとに補完候補が
＃ぞろぞろと出てくるだけでストレスがたまります。指がキーボードの
＃次のキーを打つ前に情報がネットワークを往復しきれないのです。

> 理由は最初の投稿で記載した通り。マクロでやっても不具合や
> 衝突の嵐なので使わなくなるだけだから。

そうでしょうか。天翔記さんの上記の予測は、1文字入力するたびに
自動的に辞書サーバに全文を投げる設計を前提にしているからでは
ありませんか？　もし、自動的に投げるのではなくて、明示的に
Ctrl+Enterなりなんなりを押した時点ではじめてクエリーを飛ばす
設計にすれば、普通に使っている限り他のマクロとの衝突は起きない
はずです。

＃別の秀丸プロセスの上で常時マクロが走っているなら話は別ですが、
＃そういう方法を秀丸は想定していません。

> VSは格安ですし「個人開発」や「売り上げ少ない小小企業」ではPro
> 相当(10万相当)が無料ですよ。

そうだったのですか。ただ、気がかりが2点。

1.VSはライフサイクルが終わったOSを無条件で切り捨てると認識しています。
　たとえば、最新のVC++でコンパイルしたバイナリは、Windows XPまでの
　OSではもはや起動時点でハネられるはずです。もしかしたら4年後には、
　今までWindows7でバイナリが普通に動いていたのに、ある日セキュリティ
　パッチを名目にランタイムライブラリがサポート切れになり、突如
　動かなくなる、というシナリオも充分あり得ます。
　人にもよるでしょうけど、これは私の場合、致命的です。
　Unicode絡みでWindows 4.xを切り捨てざるを得ないケースでも、せめて
　Windows 2000なりXPなりではある程度まで動いてほしいと思います。

2.一定の条件下で無料になる、というのはありがたいのですが、こうやって
　無料で手にしたコンパイラで作ったバイナリに制限は何かかかって
　いたりはしませんか？たとえば、営利事業に使ってはいけないとか、
　決算で最終利益が一定以上出たら遡って有償版を買わされるとか。

このへんどうなんでしょ。会計関係の英語には疎いので、どなたかその手の
ドキュメントの日本語版を教えていただけませんか？

RE:08202 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/15 23:20

SSL通信とかではないですよ。

インターネットごしやリモートＰＣで通信するのではなく、
そういうコンソールコマンドをローカルに置いておけるのです。
(好きなフォルダにでも置いておけばよいのです。）

いろいろ言語やフォーマットごとに取りそろってますが、
まぁオープンソースが多いですかねぇ。

要するに、gnuのgrepコマンドとかと同じですよ。
「こんな文字列含まれたファイル、これ以下にある？」と検索すると
ずらずらとリストが返ってくるように、

「こんな感じのソースで今カーソルはここなんだけど、補完候補はある？リストく
ださい」
と問い合わせると結果が返ってくるのです。

RE:08203 入力補完時に呼ばれるコールバッ

でるもんたいいじま さん　16/08/16 00:31

でるもんた・いいじまです。

> インターネットごしやリモートＰＣで通信するのではなく、
> そういうコンソールコマンドをローカルに置いておけるのです。
> (好きなフォルダにでも置いておけばよいのです。）

> 要するに、gnuのgrepコマンドとかと同じですよ。
> 「こんな文字列含まれたファイル、これ以下にある？」と検索すると
> ずらずらとリストが返ってくるように、
>
> 「こんな感じのソースで今カーソルはここなんだけど、
> 補完候補はある？リストください」
> と問い合わせると結果が返ってくるのです。

なるほど、そういうことですか。

で、もし、プロセスを生成して、結果を出して、終了して、メモリを
解放して…というオーバーヘッドすら気になるなら、それこそデーモンを
立ち上げておいて、プロセス間通信なりlocalhost宛のTCP通信なりを
使ってデータをやり取りすることも（実際にそういうものが存在するか
どうかは別として、原理的には）できるわけですね。

☆　☆　☆

で、いまだに理解に苦しむのは、「なぜ、キーボードの押下直後に自動
的に候補が表示されることを唯一の選択肢としているのか」という点です。
前回のヒアドキュメントの時にも議論しましたけど、新しいマシンばかりが
秀丸のプラットフォームではありません。

もちろん私としても、キー入力1回ごとにDLLの関数が実用的な速さでコール
バックされる仕組みができれば、（まあ、インストーラーを走らせただけで
死蔵しているMinGWの初期設定から始めなきゃいけませんが）やってみたい
ことは一応あります。でも、それでパフォーマンス（今回の場合はテキスト
の入力速度）が実用レベル未満まで落ちるようならば、既に秀丸を使う
意味は失われていると思うのです。

そこまでのことを求めるのであれば、わざわざクローズドソースの、しかも
有料の秀丸を選んでおいて開発元に要望を丸投げするのではなくて、Emacs
でもvimでも結構ですからオープンソースのエディタを自前で改造して然る
べきだと思うのです。それだけの実力は天翔記さんには十分あるはずです。

☆　☆　☆

ここまで書いてきて、ひとつ明確になった点があります。

要するに、天翔記さんの矢継ぎ早の要望が私から見て気に喰わないのは、
開発側に対して充分な対価を払わずに、「よその製品では◯◯ができるん
だから」という理由だけを根拠にしてタダでおんぶだっこしようとする
姿勢ですね。嫌ならよそへ行けよ、と言いたくなります。

…牢名主の僻みですかね。

RE:08205 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/16 00:53

対価を払わない？

うちは100ライセンスやそこらの購入数ではすみませんが。

RE:08205 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/16 00:59

新しいマシンじゃない人は、ONにしなければいいじゃないですか。

全員の秀丸が「ガク」っと重くなってしまうような提案は一切してないんですよ。

PCが貧弱な人は、その範疇で秀丸を利用する。
PCが潤沢であれば、PCの性能を秀丸にも振り分けて、より便利さを教授する。

ネットにしてもそうですよねぇ。
Win95のころの一般家庭にあった回線で今のネットがまともに見れますか？
見れないですよねぇ。
ファイルのダウロードすらおぼつかないでしょう。

でもそういう環境もある。そういう環境の人はそのいう環境なりの使い方をすればよ
いのです。
しかし、現在平均的なマシンとしては、秀丸を利用する上では潤沢な性能を持ってい
ます。
潤沢な性能を眠らせておっく必要なんかないですよ。

スピードを気にして、全部アセンブラで書く必要なんかないんですよ。

全ては自分の手持ちの札に応じて、「何をONにして」「何をOFFにするか」を決めれ
ばよいことです。

唯一、「秀丸のデフォルトが極端に重くなってしまう」、といった要望があれば、そ
の時は待ったといった声が上がってもよいでしょうが、
今回の要望はいずれも、デフォルトの重さは一切変わりません。

RE:08197 入力補完時に呼ばれるコールバッ

IKKI さん　16/08/16 01:43

こんばんは。補完マクロ製作経験者の IKKI です。
ちょっと良くない流れのように思うので、横から口出しさせてください。

---- 以下は議論の本筋と関係ありません ----

>私には、…という程度しかわかりません。
すべての読者が内容を理解する必要はないでしょう。分かる人同士で議論を進めれば
よいのです。

少なくとも私は天翔記jpさんの仰ることを98%は理解できますし、指摘内容・提案内
容とも妥当なものと思います。だから沈黙をもって賛意を示していました。
当然、秀丸担当さんや秀まるおさんも天翔記jpさんの仰ることを100%理解なさってお
いでです。

そうして全うに議論されている内容を理解できない第三者が、公の場で「私には理解
できない」と表明することに何の意味がありましょうか。
性能や互換性に目配せするのはひとえにサイトー企画さんの役割ですし、これに関し
てユーザーが先回りして心配する必要がないことは重々ご存じでしょう。

> …牢名主の僻みですかね。
「沈黙は金、雄弁は銀」なる時を弁えるのが、良き先達としての在り方かと存じます。
ここは優秀な後輩にのびのびと活動してもらおうじゃありませんか。

RE:08210 入力補完時に呼ばれるコールバッ

でるもんたいいじま さん　16/08/16 15:04

でるもんた・いいじまです。面目ありません。

> ちょっと良くない流れのように思うので、横から口出しさせてください。

水入り、恐れ入ります。以下、長くなりますがお付き合いください。

> > 私には、…という程度しかわかりません。
> すべての読者が内容を理解する必要はないでしょう。
> 分かる人同士で議論を進めればよいのです。

概ね首肯しますけど、少しだけ引っかかるところがあります。

というのは…
この会議室は公開の場所です。本件でもその他の件でも、サイトー企画
さんと利用者さん（今回の場合は天翔記jpさんですね）とのやりとりは、
機密情報の入ったメモリダンプなどの一部例外を除いて、誰でも簡単に、
コミュニテックスの会員登録すらせずにアクセスしうる状態にあります。

これを私は、秀丸関係のノウハウはサイトー企画の内部に埋もれさせず、
社会全体の共有財産にしたい、という意図が含まれているものだと勝手に
解釈することにしています。もちろん、公開にしている理由はそれだけ
ではないでしょうけど。

というわけで、私が投稿するときには、それが「社会全体の共有財産」
として遺される内容の一部分にふさわしいように、概ね次のような
方針で書いているつもりです。今回の件で守れているかどうかは
ちょっと怪しいですが。

　　1.各会議室の「標準的な参加者」であれば、その話題が自分に
　　　関係のあるものかどうかを判断できること。
　　2.自分に関係がある、と判断した人が読めば、その内容の「半分
　　　程度」は自力で理解できること。
　　3.残り半分の「理解できない部分」については、必要なら発案者や
　　　上級者に質問できる雰囲気になっていること。

　　　　※「標準的な参加者」「半分程度」という語は厳密には
　　　　　定義しないことにしています。線引きの基準は案件ごとに
　　　　　変動しますので。

今回の場合は、何度も質問を往復して、そして昨晩いちど頭を冷やして、
やっと天翔記jpさんが何の目的で何をやりたいのか理解し、その上で
hidesoft.4:08208 でやっと、私（でるもんた・いいじま）には当面
関係なさそう、という言質が取れた、という状態です。
上記の流れでいうと、やっと 1. の段階を突破できたんです。

以下、前後します。

> そうして全うに議論されている内容を理解できない第三者が、
> 公の場で「私には理解できない」と表明することに何の意味が
> ありましょうか。

繰り返しになるかもしれませんが、「自分に関係があるかどうか
分からない（自分に悪影響が出るかもしれない）から、何をどう
したいのかきちんと説明してほしい」というのが最大の理由です。

今回の場合、「入力補完時に呼ばれるコールバック用の.dll」
にしても、「単語等にマウスカーソルを当てるとヘルプチップを
出す機構が欲…」にしても、天翔記jpさんは、DLLを呼び出す機能の
追加を要望しています。

とすると設計次第では、秀丸本体までもが古いWindows（NT4/98/Me
まで、2000まで、あるいはXPまで）上で起動しなくなる、もしくは、
古いマシンでは重すぎて使い物にならなくなる危険性があります。

（私の場合、古いアプリのためにWindows 98やWindows 2000をVMware
　の上で飼っていますので、そういう事態になったら死活問題です。）

それが杞憂だと納得したのは、hidesoft.4:08208 を読んでからです。

> 性能や互換性に目配せするのはひとえにサイトー企画さんの役割
> ですし、これに関してユーザーが先回りして心配する必要がない
> ことは重々ご存じでしょう。

そうですね。ちょっと私のほうにも行き過ぎがありました。

☆　☆　☆

というわけで、この機会に天翔記jpさんにひとつ要望します。

「◯◯する機能を作ってください」と提案するときには、「それを
使って△△をしたい」「◇◇という便利な結果が得られる」といった
情報を噛み砕いて説明するということをもう少し頑張っていただけ
ないでしょうか。つまり、「手段」をリクエストするときには、
同時に「目的」「効果」をはっきり提示してほしいのです。

そうすれば、「その目的には別の××という手段のほうがよいのでは？」
といった検討も容易になります。今回の天翔記jpさんはかなりの達人と
お見受けしましたが、その逆の初心者からの質問・要望の場合には、
本人が使おうとしている手段が全くの頓珍漢で（あるいは予算やネット
ワーク構成など外部要因のために非現実的で）、別解を提示してそれで
手を打ってもらう、ということが多々あります。

私自身が大学時代にユーザーサポートの学内アルバイトをしていた
時代の経験からも、質問を受け取ったときに最優先で検討すべきなのは
「質問者が提示してきた手段はどうすれば実現可能か」ではなく、
「質問者が達成したい目的はどうすれば実現できるか」です。

今回の場合、唯一目的らしく明示されていたのは「他社のエディタには
◯◯の機能があるから、同じものを秀丸にも実装してほしい」という
主張だけです。それだけしか理由がないのだとすれば、「そんなに
そのエディタの機能がほしいなら、秀丸を捨ててそのエディタを使えば
いいのに」と言いたくもなります。

☆　☆　☆

実例として、
「hidesoft.4:08136| 秀丸マクロへの「ヒアドキュメント」の実装願い」
について詳しく見ていきます。

このスレッドの最初の投稿の場合、天翔記jpさんが希望している「手段」は
「『ヒアキュメント』を実装すること」です。しかしながら、その「目的」
「効果」については、「秀丸マクロの中に他の言語を直接書けるようになる」
「秀丸マクロの可能性拡大」「メリットは計り知れない」といった具合に
漠然と大言壮語するのみで、具体的・現実的な例題や、その効果の説明が
全くありません。

つまり、
・メリットとして主張している内容が、地に足がついた現実的な
　ものとは到底思えない
・にもかかわらず、現在の秀丸の設計次第では大きな労力を要する
　作業を要求している
と私には見えたのです。

まず確認ですが、そもそも、ある言語の中に他の言語のコードを埋め込む
ためには、ヒアドキュメントの類は必須条件ではありません。実際に現状
でも、hidesoft.4:08145 で担当さんが提示されたコードを借りれば、

$code = "import clr\n" +
"import System\n" +
"clr.AddReferenceByPartialName(\"System.Windows.Forms\")\n" +
// 中略
;
#_ = dllfunc(#PY, "DoString", $s);

といった具合に書けるわけで、これが私の目には
目的：「頑張れば既にできる事柄ではあるが、少しだけ楽をしたい」
手段：「マクロの文法をいたずらに複雑にしかねないヒアドキュメントを
　　　実装してもらう」
と映りました。

ヒアドキュメントを使って具体的に何をやりたいのかについても、
hidesoft.4:08136 を読む限りでは、「秀丸上のテキストを加工するために、
秀丸マクロと他の言語とをシームレスに併用したい」としか読み取れません。
それだけなら、別のファイルにスクリプトを書いて外部プロセスとして呼び
出すなり、あるいは、もっと細かい制御が必要ならDLLを使うなりといった
方法があるはずなのに、「なぜ、それらでは不満なのか」についての説明が
ありません。

で、天翔記jpさん本人（このスレッドでは「あきくん」を名乗っていますね）
から真意の表示が出たのは、hidesoft.4:08148 です。複数行文字列のラベル
に使う文字列を強調表示セットと関連づけておけば、文字列の内側をその
強調表示セットに従って色分けができる、とあります。

これは確かに大きなメリットです。最初からこちらを指摘してほしかったと
思います。私自身はPythonは分かりませんが、たとえば、HTMLを加工する
マクロの中に記述したタグがきちんとHTMLとして強調表示されれば、
R"..." のメリットを実感できます。

後から振り返れば、天翔記jpさんは最初からこのメリットまで想定して
提案していたわけですが、そういう想定が頭の中にあっても、きちんと
言語化・文章化しないと、他の人には何がどう嬉しいのか分かって
もらえない、ということを、もう一度しっかりと認識してほしいと思います。

＃hidesoft.4:08207 を読むと、天翔記jpさんはソフトウェアの開発を
＃お仕事にしているようにお見受けいたしましたが、試しに1週間くらい、
＃末端ユーザのサポート部門を体験してみてはいかがですか？
＃自分の「当たり前」が世間一般には通用しないことがある、という
＃ことを痛感するはずです。

☆　☆　☆

今回の2つの提案に対するコメントは、今までに出てきた情報を別稿で。
結論から言えば、どちらも「細かい追加注文はあるがおおむね賛成」です。

RE:08208 入力補完時に呼ばれるコールバッ

でるもんたいいじま さん　16/08/16 15:36

でるもんた・いいじまです。

各論です。

> 新しいマシンじゃない人は、ONにしなければいいじゃないですか。
> 全員の秀丸が「ガク」っと重くなってしまうような提案は一切して
> ないんですよ。

ここまでたどりついて安心しました。

ただ、

> PCが貧弱な人は、その範疇で秀丸を利用する。
> PCが潤沢であれば、PCの性能を秀丸にも振り分けて、
> より便利さを教授する。

というところにちょっと齟齬があるようなので、私の投稿を再掲します。

hidesoft.4:08205:
| で、いまだに理解に苦しむのは、「なぜ、キーボードの押下直後に自動
| 的に候補が表示されることを唯一の選択肢としているのか」という点です。
| 前回のヒアドキュメントの時にも議論しましたけど、新しいマシンばかりが
| 秀丸のプラットフォームではありません。

まず、「新しいマシン」かどうかの基準はマシンパワーだけではありません。
プラットフォーム（OSなど）の新旧も影響します。新しいマシンでの利便の
ために古いプラットフォームとの互換性が犠牲になるようなら、何か対策を
しないといけません。今回は「DLLで」という要望でしたので、こちらの
危険性を懸念していました。

次に、マシンパワーについても、「貧弱」と「（CPUなどの資源が）潤沢」の
2択ではありません。今回問題にしている補完についても、少なくとも
a.1文字ごとに外部プロセスを起動してもストレスなく使える環境
b.1文字ごとではつらいが、途中まで入力してキー入力をトリガーに
　して補完する方式なら我慢できる環境
c.キー入力をトリガーにする方式でも厳しい環境
くらいには場合分けする必要があります。

a.の環境ならばたしかに、DLLでリアルタイムに補完できれば嬉しいで
しょう。逆に、c.の環境では補完は完全に諦めざるを得ません。
（ストレージも少ないことが懸念されるので、場合によってはそれも
　足枷になるでしょう。…というのは心配しすぎかな？）

ではb.は？今までの議論からは失礼ながら、このクラスの環境への
配慮が欠けているように感じられました。私のタイプスピードだと、
設計次第では数GHzのマシンでもストレスを感じるでしょうから
（幸い、Excel 2010のVBAエディタではストレスは感じません）、
そのへんは今後詰めていただければと思います。

> 唯一、「秀丸のデフォルトが極端に重くなってしまう」、といった
> 要望があれば、その時は待ったといった声が上がってもよいでしょうが、
> 今回の要望はいずれも、デフォルトの重さは一切変わりません。

念押しですが、待ったをかける理由は重さだけではありません。
繰り返しになりますが、互換性も重要です。

RE:08208 入力補完時に呼ばれるコールバッ

でるもんたいいじま さん　16/08/16 16:07

でるもんた・いいじまです。

この投稿は雑談です。

> そういう環境もある。そういう環境の人はそのいう環境なりの
> 使い方をすればよいのです。

まあ、これは同意です。

> ネットにしてもそうですよねぇ。
> Win95のころの一般家庭にあった回線で今のネットがまともに見れますか？
> 見れないですよねぇ。

試しにガラケーで64k接続して試してみました。
・NHKネットラジオ「らじるらじる」→ちょっと音が鳴っただけで中断
・ラジコ→そもそも初期画面が完成するまで待てずに断念
・Twitter→途中でタイムラインの読込が打ち切られ、ネットワークが
　過負荷ではと言われる

まず、らじるらじるは音声信号のビットレートの問題のようなので、
どうしようもありません。
ラジコやTwitterの場合は、JavaScriptで手の込んだことをやりすぎて
いるのが主因でしょうね。

> ファイルのダウロードすらおぼつかないでしょう。

これは逆に楽ですよ。さすがに数百MBのデータは無理ですが、
数MB程度までなら我慢の範囲内に入ります。

> スピードを気にして、全部アセンブラで書く必要なんかないんですよ。

今は「アセンブラで書くとCよりパフォーマンスが落ちる」という事態すら
発生してますね。しっかり最適化されたCコンパイラなら複数の処理をコアの
内部で並列処理できるように命令の順序を入れ替えてくれるけど、そのへんの
ノウハウを知らない素人がアセンブラで直接書くとなかなか並列化できない、
というケースも発生します。

あとは、i386、amd64、その他、という複数環境で同じソースをコンパイル
できるように、というのも要件になることがあるので、その場合もフル
アセンブラはデメリットのほうが大きいですね。

RE:08214 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/16 16:20

なんだか謎ですねぇ。

指摘しているポイントがトンチンカンというか、
失礼ですが、実は「全くというほどプログラム書けない」のではないですか？

負荷がかかるポイントの心配や、互換性云々の心配もトンチンカンな視点ばかりで
「私はまともなプログラム書いたことがない」
「私はまともなプログラム書いたことがない」
「私はまともなプログラム書いたことがない」
とオウムのように繰り返しているようにしか、私の目には映りません。

ヒアドキュメントの時からそうでしたが。

RE:08216 入力補完時に呼ばれるコールバッ

でるもんたいいじま さん　16/08/16 20:06

でるもんた・いいじまです。
喧嘩じみた投稿はこれで最後にします。

> なんだか謎ですねぇ。

こちらからしても、こんなに話がこじれるのは予想外でした。
hidesoft.4:08210でIKKIさんが諫めてくださいましたけど、
それでもおさまらないとは。

ヒアドキュメントのときに、C++の経験が25年あるけど
それでもC#で書くほうが速い、と書いてましたね。
その25年の人生経験が泣きますよ。

☆　☆　☆

> 失礼ですが、実は「全くというほどプログラム書けない」のでは
> ないですか？

この「プログラム」なるものの範疇はどこからどこまでですか？
その内容によって、私の答えは「25年前から毎日のように書いている」
にもなりえますし、「確かにその通り、ほとんど経験がない」にも
なりえます。

最近は秀丸関係ではここhidesoft.4とhidesoft.2にいろいろと、
それから時たまturukame.3にも投稿していますから、最近の私の
投稿を検索して読んでいただければ、私が何を書いているか、
逆に何を書いていないのかはあらかた見えると思います。

turukame.3:09000あたりがわかりやすいかな？

☆　☆　☆

で、ここの部分で思ったんですけど、天翔記jpさんの投稿には、
こういう「世間一般で使われている意味、あるいは辞書に書かれて
いる意味とはどうも違うようだけど、ではどういう意味なのかが
明らかでない」という単語がいくつかあるんです。

今はそれでも許されるかもしれませんけど、このままではあなたの
10年後、20年後が心配です。

＃俺のことを言う前にまず自分の心配しろよ、と言われそうですけど。

☆　☆　☆

> 指摘しているポイントがトンチンカンというか、
...
> 負荷がかかるポイントの心配や、互換性云々の心配もトンチンカンな
> 視点ばかりで

そういう頓珍漢な人にも大意が通じるように書かないといけないんです、
テクニカルドキュメントとかビジネスドキュメントとか言われるものは。

天翔記jpさんの文章の癖に対する指摘はhidesoft.4:08213にまとめて
ありますので、ぜひともそれに対するご意見（「頓珍漢だ」のレッテル
以外で何か）をいただきたいものです。

☆　☆　☆

> 「私はまともなプログラム書いたことがない」
> 「私はまともなプログラム書いたことがない」
> 「私はまともなプログラム書いたことがない」
> とオウムのように繰り返しているようにしか、私の目には映りません。

失礼ながら、ここはそのまま反射しますよ。
「私はまともなドキュメントを書いたことがない」

「私はまともなドキュメントを書いたことがない」

「私はまともなドキュメントを書いたことがない」
とオウムのように繰り返しているようにしか、私の目には映りません。

☆　☆　☆

書いていて少しずつ虚しくなってきています。
こういう煽り合いはそろそろやめませんか？

RE:08195 入力補完時に呼ばれるコールバッ

あべのり さん　16/08/16 22:52

あべのりです．半分雑談です．

>機能を作っても速度の点やマクロ衝突の点で実用には至らなかったためです。
編集後タイマーにマクロを登録して，特定の文字が来た場合に
* 外部プロセスを起動し，補完候補を取得
* それともとにautocompleteで単語補完を出す
とした場合，実用的な速度には達さないのでしょうか？（マクロが一個しか動かせな
いというのはとりあえず無視します．）

# 補完マクロ作成の際に苦しんで，妄想していたのがこういうのでした．
# 実際にやってみたことがないので，単純に技術的な興味があります．
# もし試したことがあれば教えていただけると嬉しいです．

RE:08233 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/17 00:05

>* 外部プロセスを起動し，補完候補を取得
OmniSharpに関しては、まだ私も「コンソールレベル」でしかやっていません。
コンソールレベルだと結構レスポンスは良いです。

(他のエディタのOmniSharp入力はためしています。これも「おや速い」という感じです)

私が実験しているのはLuajitのjitエンジンでコンパイルしたバイトコードを解析し
た情報に基づいた入力補完で、これ自体は速いです(未完成でボコボコですがｗ)

今の秀丸で自動補完を増やそうとすると、
①tagsを使ってないならtagsに貯める、
②tagsを汚さないなら、秀丸をステルスモードで起動して、そこに入力補完リストを
挿入
とじて、autocompleteのオプションで「１つ前の秀丸」からも拾う、
みたいにするしかないと思いますね。

私はこのあたりの秀丸のノウハウは経験不足なので、
CompleteXなどで長年試行錯誤されたIKKIさんとかの方がよほどか詳しいかと。

RE:08236 入力補完時に呼ばれるコールバッ

あべのり さん　16/08/17 02:48

すみません，質問の仕方が悪かったようです．次のようなことをしてはどうかと思い
ました．
例えばC++で，"."が入力された時にそのクラスのメンバなどを補完することを考えま
す．

まず次のようなプログラムcomplete.exeが存在すると仮定します
complete.exe <file> <lineno> <column> <output>
として起動すると，filenの(lineno,column)の位置での補完候補の一覧をoutputには
き出す．

この仮定のもとで，次のようなマクロを自動起動マクロの編集後タイマーに登録する．
# 動かしていないのでバグっているかもしれませんが，空気を読んでください（苦笑）

$tmp = getenv("TMPDIR") + "\\complete.tmp";
if(geteventparam(0) != 0)endmacro; // 通常の編集のみ相手にする
if(geteventparam(4) == '.'){// 入力されたのがピリオド
run "complete.exe " + filename + " " + str(lineno) + " " + str(column) + "
" + $tmp;
autocomplete 0,0x2 | 0x4,0x3 | 0x20,$tmp;
}

-------------
>OmniSharpに関しては、まだ私も「コンソールレベル」でしかやっていません。
>コンソールレベルだと結構レスポンスは良いです。
一番辛いのが正しい補完候補をとるところだと思うので，そこのレスポンスが良けれ
ば行けるのではないかと妄想……

RE:08237 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/17 11:24

あべのりさんが言われるように「マクロの衝突」等は不問、
ということであれば、

① autocompleteのパフォーマンスは問題は無し
② autocompleteの前の辞書問い合わせの部分
　　　└２つのDeleyがあります
　　　　　├ (a)マクロでその場でプロセス起動をした場合に伴うDeley
　　　　　├ (b)問い合わせ先のプログラム自体がリストを構築するDelay
　　　　　└ (c)リストを秀丸のautocompleteで取り扱える形にするDeley

(b)は対象のツール自体の性能なので、置いておきます。
　（これは先の投稿でOmniSharpでも「あらおもってるよりは速い」といった感触です）

(a)プロセス起動に伴うDelay　　　　　
プロセス起動に伴うDelayについては、
マクロの自動起動の「アクティブ切り替え」でdll呼び出し、
そのdllの中で、アウトプロセスと通信を確立してしまっておくことで、
かなり圧縮できるかと。
要するに、「外部プロセスを立ち上げて問い合わせる」のではなく、インプロセスに
問い合わせるように変更します。

(c)については、私はスマートな解決方法がわかりませんでした。
　（これも先に投稿したtagsが～とか、直前の秀丸エディタが～とかのもの)

もし、マクロ衝突とかの問題がなかったら、(c)こそがネックと踏んで、
今回の要望は全然違ったものになったと思います。
例えば、
「autocompleteで、検索対象に、マクロ内の配列を対象と出来るようにして欲しい」
例

$word_array[0] = "abc1";
$word_array[1] = "abc2"; // この配列には、インプロセスで問い合わせた結果をそ
のまま変数に入れるので時間的ロスはすごく少ない
autocomplete 0, 0x*** $word_array, ...; // autocompleteに新たなパラメタが必要

みたいになったと思います。

RE:08238 入力補完時に呼ばれるコールバッ

秀丸担当 さん　16/08/17 16:12

入力補完のためのコールバック用のDLLができたらいいということで、マクロだ
けでは不十分なこともあるので、可能ならばあったらいいとは思います。
内部データに近いところにアクセスすることになりそうなので、一度やるとその
互換性を維持していくことや、もし問題があった場合の対処が難しいことになり
そうなのが心配ではあります。
もしやるとしたら、いつでもテキストのどの部分にもアクセスできると壊れたり
大変になりそうなので、できるだけ限定的なアクセスのほうがいいかもしれませ
ん。
できたらいいということは理解できます。
そういうご意見として参考にさせていただきます。

RE:08238 入力補完時に呼ばれるコールバッ

あべのり さん　16/08/17 16:50

>(b)は対象のツール自体の性能なので、置いておきます。
>　（これは先の投稿でOmniSharpでも「あらおもってるよりは速い」といった感触で
>す）
お聞きしたかったのは，この部分まで含めてどのくらい速い/遅いのだろうというこ
とでした．
別件でためした感じだと，自動起動マクロ内で云々する場合，かなりの速度で終えな
いと入力取りこぼしが起こる感じがします．
# まぁそろそろ自分で試せと言う気がしてきました……

> (c)リストを秀丸のautocompleteで取り扱える形にするDeley
>(c)については、私はスマートな解決方法がわかりませんでした。
>　（これも先に投稿したtagsが～とか、直前の秀丸エディタが～とかのもの)
前の投稿では，とりあえずシンプルな外部ファイル作成です．
例えばclangでは
COMPLETION: (補完対象) (型情報とか？)
という形で得られるみたいですが，
clang起動→標準出力で受け取り，上の「補完対象」だけ抜き出す→ファイルに書き出す
ということをするプログラムを作って，これをautocompleteに渡すとどうだろうと．

(a)+(c)で遅くて使い物にならないということならば，もはやどうしようもないので
すが，さすがにそれはないだろうと思っています．
すると(a)+(b)+(c)で使い物になるかという点が気になってしまい，(b)のパフォーマ
ンスを気にしていました．
これについては天翔記jpさんがいろいろ試されているのではないかと思いきかせてい
ただいた，ということです．

# この質問は現実的な解を探そうとかそういう意図はなく，元々の要望に対する賛否
を言う物でもなく，
# 要するに「clangとかOminiSharpとかの使うツールって速いの？」という質問です．
で，「速い」の定義として，
# 例えば前述のマクロを自動起動に設定した場合，ストレスなく使えるか，というこ
とにしてみました．
# 「あらおもっているよりは速い」だと，この定義では速くないかもしれないですね．

RE:08241 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/17 17:36

了解しました。
検討ありがとうございます。

私の方で、
マクロを介することなく、入力補完内容をダイナミックに切り替えれるよdllをちょ
っと作ってみます。

RE:08243 入力補完時に呼ばれるコールバッ

天翔記jp さん　16/08/17 17:41

>(a)+(c)で遅くて使い物にならないということならば，もはやどうしようもないので
>すが，さすがにそれはないだろうと思っています．
(c)の部分が遅いのです。

しかし、今回サイトー企画さんの方から、
「参考としたいが、今はちょっと…」的な反応でしたので、
私の方で、適当に少量のアセンブラ等を使ったインジェクションdllを作ってみます。

(c)の部分はファイルの書き込みだけに出来るので、
スピードはめちゃくちゃアップすると思いますが、やってみないとわからないですね。