【要望】Gitの編集

  1. 現状ではGitの編集として関連付けすると
    正常にgit rebase -iやgit commitなどの編集ができないので
    できれば対応していただけたらなと思います

    よろしくお願いします

     |  S  |  返信
  2. 書き込みありがとうございます。

    git の編集ですが、git から渡されるファイルのパスが「/」区切りになっているため Mery 側ではじいているようです。ここのチェックを少し変えれば一応 git の編集もできるようにはなったのですが…

    git rebase などは他のアプリを起動して、そのアプリが終了するまで待機するという仕組みになっているようですが、Mery のように一つのプロセスで複数のファイルを編集するタイプのアプリケーションでは、すでに Mery が起動中の場合には git 側で外部アプリの起動・終了が監視できないので git rebase がそのまま最後まで走ってしまいますね…

    Mery を強制的に別プロセスで起動するような仕組みを設ければ実現可能かもしれませんが、そもそも一つのプロセスでの動作を前提に設計しているアプリケーションなので動作保証外ってことにはなりそうですね。

    なかなか難しそうです。

     |  Kuro  |  返信
  3. ks です。
    案だけですが、中継用の exe (not Mery) を用意して、それ経由で Mery を起動して編集するというのはどうでしょう。

    流れとしては
    1. git が中継用 exe のプロセスを生成。
    2. 中継用 exe が Mery を叩く。
    3. Mery の編集完了を何らか取得(プラグインなど?)
    4. 中継用 exe が終了
    となるでしょうか。

    これなら Kuro さん側での対応は不要になります。
    (パス区切り文字も、中継で変換してしまえば良いので)

     |  ks  |  返信
  4. > 書き込みありがとうございます。

    > git の編集ですが、git から渡されるファイルのパスが「/」区切りになっているため Mery 側ではじいているようです。ここのチェックを少し変えれば一応 git の編集もできるようにはなったのですが…

    > git rebase などは他のアプリを起動して、そのアプリが終了するまで待機するという仕組みになっているようですが、Mery のように一つのプロセスで複数のファイルを編集するタイプのアプリケーションでは、すでに Mery が起動中の場合には git 側で外部アプリの起動・終了が監視できないので git rebase がそのまま最後まで走ってしまいますね…

    > Mery を強制的に別プロセスで起動するような仕組みを設ければ実現可能かもしれませんが、そもそも一つのプロセスでの動作を前提に設計しているアプリケーションなので動作保証外ってことにはなりそうですね。

    > なかなか難しそうです。
    http://stackoverflow.com/questions/1634161/how-do-i-use-notepad-or-other-with-msysgit
    同じような構造?のNotepad++では別プロセスで走らせるコマンドラインオプションをつけるという形になってますね

     |  S  |  返信
  5. > ks です。
    > 案だけですが、中継用の exe (not Mery) を用意して、それ経由で Mery を起動して編集するというのはどうでしょう。

    > 流れとしては
    > 1. git が中継用 exe のプロセスを生成。
    > 2. 中継用 exe が Mery を叩く。
    > 3. Mery の編集完了を何らか取得(プラグインなど?)
    > 4. 中継用 exe が終了
    > となるでしょうか。

    > これなら Kuro さん側での対応は不要になります。
    > (パス区切り文字も、中継で変換してしまえば良いので)
    なるほど…
    ただ、自分はIPC通信どころかWindows用のプログラム(C/C++/Delphi)を作ったことがないのできつそうです…

     |  S  |  返信
  6. 別 exe を中継する作戦は私も考えてみたのですが、編集終了を取得するのがちょっと難しそうですね。
    NotePad++ と同様、E○Editor でも動作保証外ですが別プロセスで起動する起動時引数を使うようになっているようですね。

    Mery でも別プロセスで起動できる引数を用意したとして、二重起動した場合に問題になりそうなところといえば、常駐してたらトレイアイコンが二つ表示されることぐらいしか思い浮かばないですが…w

    試しに実装してみようかしら。

     |  Kuro  |  返信
  7. > 別 exe を中継する作戦は私も考えてみたのですが、編集終了を取得するのがちょっと難しそうですね。

    Kuro さんもすでに考えられていたとはっ
    どや顔で書き込んでいた自分が恥ずかしい……

    編集終了はタブを閉じたときにプラグインから exe に伝えれば良いかと
    プロセス間のやりとりは、簡単な方法だと特定ファイルの作成・削除かなぁ

    > 試しに実装してみようかしら。

    こちらも試しに作ってみますね

     |  ks  |  返信
  8. > プロセス間のやりとりは、簡単な方法だと特定ファイルの作成・削除かなぁ

    編集終了の通知だけなら exe に SendMessage してやっても良さそうですね。

    それか、今回のケースは exe のプロセスさえ死ねばいいわけなので、編集終了時に exe を kill してやるだけでも良いかもしれませんね。

    現在の Mery で使用できそうな方法を hoge.exe と hoge.js で考えてみました。

    ① git rebase などで hoge.exe を呼び出す
    ② hoge.exe は引数の 1 番目 (ファイル名) の「/」を「\」に置換して Mery に渡す、ついでに自分の PID も
    ③ Mery のイベントマクロ「文書を閉じた時」に hoge.js が発動して hoge.exe のプロセスを taskkill する

    こんな感じでしょうか。

    ちなみに Mery を無理やり別プロセスで起動するオプションを試しに実装してみたのですが、本気で作りこまない限りは下記のような問題が発生しそうですので、許容範囲かどうか判断に迷うところです。

    ・異なるプロセス間でのタブの移動はできない
     → これは我慢できそう
    ・編集中のファイルを別のプロセスでも編集できてしまう
     → これも仕方がないな~で済みそう
    ・設定 (INI) の保存は最後に終了したプロセスが上書きする
     → 設定を変更しても反映されてない!ってことが起こり得る
    ・マクロや外部ツールの設定などが別プロセスに反映されない
     → せっかくマクロを登録しても最後に終了したプロセスの設定で上書きされてしまう

    こんな感じです。
    これらの問題は NotePad++ でも発生しますが…w

     |  Kuro  |  返信
  9. > ・異なるプロセス間でのタブの移動はできない
    >  → これは我慢できそう
    →これは特に問題にはならないと思います
    > ・編集中のファイルを別のプロセスでも編集できてしまう
    >  → これも仕方がないな~で済みそう
    →これも特には問題にならないかなと
    > ・設定 (INI) の保存は最後に終了したプロセスが上書きする
    >  → 設定を変更しても反映されてない!ってことが起こり得る
    > ・マクロや外部ツールの設定などが別プロセスに反映されない
    >  → せっかくマクロを登録しても最後に終了したプロセスの設定で上書きされてしまう
    →これらは、新しいプロセスで起動したものは常にデフォルトのiniなどを使用するという形では利用できませんかね?
     例えば、作業フォルダを変更するなど(?)

     |  S  |  返信
  10. とりあえず実装してみたので、Wiki に置きました。
    http://www.haijin-boys.com/wiki/%E5%88%A5%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%A7%E7%B7%A8%E9%9B%86

    これでいいのか自信はないですが……。

    動きとしては、普通に Mery のタブとして開き、タブを閉じると中継プロセスが死ぬようにしています。
    Kuro さんの用意されたオプションにくらべ、
    ・同一のエディタ上で開く
    ・設定なども特に別になるようなことはない
    という点が違います。
    割と適当に作っているので、タブを別のフレームに移動したりすると動かないかもしれません。
    あと開発の関係上、.NET Framework 4.0 以降が必要で、たぶん起動は少し重いです。

     |  ks  |  返信
  11. > とりあえず実装してみたので、Wiki に置きました。
    http://www.haijin-boys.com/wiki/%E5%88%A5%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%81%A7%E7%B7%A8%E9%9B%86

    > これでいいのか自信はないですが……。

    > 動きとしては、普通に Mery のタブとして開き、タブを閉じると中継プロセスが死ぬようにしています。
    > Kuro さんの用意されたオプションにくらべ、
    > ・同一のエディタ上で開く
    > ・設定なども特に別になるようなことはない
    > という点が違います。
    > 割と適当に作っているので、タブを別のフレームに移動したりすると動かないかもしれません。
    > あと開発の関係上、.NET Framework 4.0 以降が必要で、たぶん起動は少し重いです。

    タブを閉じたときに感知されないということがありますが、他は完璧です
    感謝の言葉も見つからないくらいです

    実装の面でもなるほどという感じです
    ありがとうございます

     |  S  |  返信
  12. > タブを閉じたときに感知されないということがありますが、他は完璧です

    やはり問題がありましたか……。
    とりあえず、右クリックからの「他の全てのタブを閉じる」などで反応しなかったのだけ修正しました。
    他の問題については、挙げていただいて再現すれば直せるかもしれません。

    # あとはソースもアップしたので、きっと誰かもっとマシなコードにしてくれるはず!

     |  ks  |  返信
  13. ご無沙汰しております
    いつもお世話になってます

    もうこれを作っていただいて2年も経つんですね…
    ほんとにずっと使ってて手放せないってくらいになってますw

    64bitのほうでは終了を正しく感知できなくなった(?)っていう報告を
    ただ、リレーだけ32bitのほうに送るようにして使えてはいるので、どういう原因なのかなという興味という感じですが…w

     |  S  |  返信
  14. ご無沙汰しております、返信が遅くなって申し訳ありません。
    見落としていました… ^^;

    > もうこれを作っていただいて2年も経つんですね…
    あれから 2 年、ks さんとは音信不通なので、その後どうされているのかわかりませんが、Mery のマクロやプラグインなど高品質なものをたくさん作っていただき感謝です。

    > 64bitのほうでは終了を正しく感知できなくなった(?)っていう報告を
    64 ビット版では、32 ビットの DLL を読み込むことができないので正常に動作しなくなっているのだと思います。

    ks さんの投稿されている Wiki ページを見るとソースも公開してくださっているようなので、64 ビットでビルドし直せば動くのではないかと思うのですが、私、C# はサッパリわからないのです…。

    > ただ、リレーだけ32bitのほうに送るようにして使えてはいるので、どういう原因なのかなという興味という感じですが…w

    64 ビット版の Mery と 32 ビット版の Mery を同居させている場合ですと、仕様上、64 ビット版が起動している状態で 32 ビット版の exe をたたくかリレーをたたけばすでに起動中の Mery (64 ビット版) が反応します。

    でも 64 ビット版を起動させてない状態ですと、普通に 32 ビット版が起動してくるんじゃないかなと思います。

    ks さん、かむばぁぁぁっく!

     |  Kuro  |  返信
  15. まず、ds14050さんが、新しいプラグインを開発してくれたので、おそらくこれでご要望は解決できるのではないかと思います。
    https://www.haijin-boys.com/wiki/%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E4%B8%AD%E7%B6%99%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3

    ただ、非.netのMeryから、どうやって.netのDLLを呼び出しているのか、少し興味が湧いたので調べてみました。
    従来.netのDLLをアンマネージから呼び出すためにはCOMとしてレジストリ登録して、COM経由で呼び出すのが一般的ですが、当然Meryからはこのような呼ばれ方はしません。

    これを解決するために、アンマネージのブリッジ用DLL(C++で書いてるみたいです)があって、これがMeryから呼ばれる。
    ブリッジDLLにはMeryから呼ばれるインターフェイスがすべて実装されていて、呼ばれたらマネージDLLに転送して、そちらで目的の処理を実行。
    という手順をとっているようです。
    こちらに同様の処理をするサンプルがありました。
    https://github.com/OpenTouryoProject/SampleProgram/tree/master/Other/DotNETBridge

    で、問題はこのブリッジDLLで、これが32bitなので64bit版では動作しないのですが、残念ながらksさんのアップしているソースにはこの部分のソースが含まれていません。
    ブリッジDLLは、ksさんの.NETプラグイン開発キット でも使われているのですが、こちらも64bitは未対応です。
    頑張れば作れると思うのですが、なんか車輪の再発明的でとてもその気分にはなれそうにありません。

    と思っていたら、ksさんのブログには64bit版のブリッジDLLが提供されていました。
    http://merysmacro.seesaa.net/article/376139614.html
    ksさん流石です。
    ただ、ブログは2013年当時のもので、最新版とは動作が異なるかもしれませんが....
    ブログの方でもブリッジDLLについてはソースは提供されていませんでした。

    やっぱり本気でやるならブリッジDLLを作るしかなさそうですね。
    ks さん、かむばぁぁぁっく!

     |  pizz  |  返信
  16. pizz さん、ご返信ありがとうございます。

    スゲェェェ!
    ds14050 さんありがとうございます。このプラグインがあれば解決しそうですね。

    ブリッジ用の DLL、非常に興味深い内容ですね。.Net はほとんど触れたことがなかったので DLL って普通に呼べるものだと思っていました ^^;

    ks さんのブログの 64bit 版のブリッジ DLL、拝見しました。説明書に「※ x64 版は将来的に必要になった場合を想定して同梱しています.」と書かれていて、感動しました。64 ビット版のリリースはそこから 4、5 年先ですから、ks さん、完全にタイムリープされてますね。

    2013 年以降、プラグインの仕様は変わっていないとは言い切れないので、私のほうでブリッジ DLL だけでもメンテできれば可能性が広がりそうですが、ソースがないのは残念です…。

    そういえばこのスレッドでちょっと話してた「Mery を別プロセスで起動できる引数」なのですが、あの時、裏技で仕込んでたんですよね。そうしたらもっと便利なプラグインを開発していただいたので、言う前に解決しちゃいましたが…。

    で、先日このスレッドに S さんから書き込みがあったときに、最悪の場合、別プロセス引数で、、、と言おうと思ったら、その引数の実装ミスってて動かねぇや。ってなりました ^^;

    Ver 2.6.8 では直ってます。

    「/sp」(セパレート・プロセス) を引数につけて起動すると別プロセスで起動しますが、このスレッドで書いているとおりプロセス間で設定を共有できないとか問題があって動作保証なしの機能です。気が向いたらプロセス間通信で、ある程度同期できるようにしようと思っていながら、もう数年経過ですわ…。

    ks さん、「秀〇ユーザになったから」とかなら良いのですが、音沙汰ないので体調を崩されたりしていないか心配です。

     |  Kuro  |  返信
  17. こんにちは。

    > Ver 2.6.8 では直ってます。
    > 「/sp」(セパレート・プロセス) を引数につけて起動すると別プロセスで起動します

    Cadソフトのjw_cadにMeryを設定した場合、文字の編集でMeryを利用しようと思っても、
    「予めMeryを起動している場合」には、jw_cadから文字の編集用に立ち上げたMeryで
    編集しても、編集が終わった後、jw_cadに変更が反映されないという症状が出ていました。
    (私だけでしょうか?)

    ただこれは、jw_cadを利用していない方には、全く関係ない話なので、
    仕方がないと思っていました。

    しかし下記のようにしたところ、反映されるようになりました。
    (参考にと思い、書いてみます。)
    ----------------------------------------
    下記のようにしてみました。

    AutoItスクリプトを下記のように書きました。
    ShellExecuteWait("Mery.exe", "/sp TEMP.TXT", "c:\jww", "open")

    それを、exeにして、Mery.exeの代わりに登録しました。
    別プロセスの利用方法のひとつみたいです。

    ※サ〇ラだと、「予め起動している場合」でも問題は無いので
    Meryとjw_cadの仕様上の相性かもしれません。
    ----------------------------------------
    上記は、動作報告です。
    (他の方のパソコンでどうなるかは、分かりません。)

    動作環境は、下記です。
    Mery(x64) Version 2.6.8(但し2.6.7でも同じだと思います。)
    Jw_cad Version 8.03a(現時点の最新版)
    Windows10 64ビット
    ※私は、MeryのフォルダーにPATHを通しています。

     |  いっち  |  返信
  18. こんばんは、ご無沙汰しております。

    > 編集しても、編集が終わった後、jw_cadに変更が反映されないという症状が出ていました。
    > (私だけでしょうか?)
    きっと、このスレッドで話題になっている現象と根本は同じだと思います。

    > Meryとjw_cadの仕様上の相性かもしれません。
    サク〇エディタさんは、複数起動すると別のプロセスになる「マルチプロセス」というタイプのアプリケーションですが、Mery は複数起動してもひとつのプロセスで動作する「シングルプロセス」なので、ShellExecuteWait で呼び出した場合、プロセスが死なないと終了を検知できないため、Mery を全部終了しないと「終了」が検知されません。

    > AutoItスクリプトを下記のように書きました。
    > ShellExecuteWait("Mery.exe", "/sp TEMP.TXT", "c:\jww", "open")

    ↑ まさに、このような使い方を想定して「/sp」オプションを用意してます。

    ただ、「/sp」オプションは本来シングルプロセスで動作するソフトを別のプロセスとして起動しているだけなので、jw_cad から呼び出した場合など、現時点では下記のような問題が発生するのでご注意ください。

    ・すでに Mery が起動している状態で /sp オプションで呼び出した場合、オプションや最近使ったファイルの履歴、検索文字列とかの情報が同期されません
    ・すでに起動中の Mery にタブを移動させたりとかもできません
    ・終了時に設定ファイルが上書きされますが、最後に終了したプロセスの設定が優先されます
    ・タスクトレイに常駐オプションを使っているとタスクトレイに 2 つ常駐しちゃいます

    なので、jw_cad から呼び出してちょこっとテキストを編集してすぐ閉じる、という用途なら使えると思いますが、jw_cad から呼び出した Mery をそのまま別の作業にも使うと、上記のような問題に遭遇しやすくなりますのでご注意くださいませ。

     |  Kuro  |  返信
  19. Kuroさん、
    お返事ありがとうございます。

    > 上記のような問題に遭遇しやすくなりますのでご注意くださいませ。
    分かりました。
    ありがとうございます。
    ----------------------------------
    Meryのマーカー機能すばらしいです。
    > jw_cad から呼び出してちょこっとテキストを編集してすぐ閉じる
    時に利用する機能ではありませんが、
    AutoItで変数の宣言を確認する時に大変便利なので、とても気に入っています。

    UWSC Proが公開終了してしまった事から、AutoItでスクリプトを書き直すことを最近行っていて、そんな時「マーカー機能」が活躍しています。

     |  いっち  |  返信
  20. Meryを立ち上げた状態にしている事が比較的多く、かつ「トレイアイコンを表示」にしていない場合は、必要に応じて/spを付けてMeryを起動させるのが良いと思いました。

    jw_cadでMeryを利用させて頂く場合は、C:\jww\TEMP.TXTだけではなく、環境設定ファイルの編集、座標ファイルの編集でも利用する事を思い出しました。

    Mery.exeの代わりに使うexeのスクリプトは、作業ディレクトリや開くファイル名を固定にしないようにしてみましたら、快適に使えるようになりました。

    ご報告の意味で投稿致します。

     |  いっち  |  返信
  21. > あれから 2 年、ks さんとは音信不通なので、その後どうされているのかわかりませんが、Mery のマクロやプラグインなど高品質なものをたくさん作っていただき感謝です。
    ほんとにksさんには感謝です
    もちろんKuroさんにも
    ただ、音信不通なのは心配ですね…

    > ks さんの投稿されている Wiki ページを見るとソースも公開してくださっているようなので、64 ビットでビルドし直せば動くのではないかと思うのですが、私、C# はサッパリわからないのです…。
    私もC#、というよりソフトウェア関連はほぼほぼ触れてなくて同じくサッパリです…
    同じようにここを読んでそんなすごいことしてあったのかとびっくりしました

    > 64 ビット版の Mery と 32 ビット版の Mery を同居させている場合ですと、仕様上、64 ビット版が起動している状態で 32 ビット版の exe をたたくかリレーをたたけばすでに起動中の Mery (64 ビット版) が反応します。
    > でも 64 ビット版を起動させてない状態ですと、普通に 32 ビット版が起動してくるんじゃないかなと思います。
    そうですね。ご指摘のように動作してました。基本的に同時起動しないような状況ばかりだったので、最初のほうは全く気付いてませんでしたが、少ししてから気づきました。

    > pizzさん
    > まず、ds14050さんが、新しいプラグインを開発してくれたので、おそらくこれでご要望は解決できるのではないかと思います。
    ありがとうございます!まったく気づいてませんでした…
    ここで言って届くかわからないですが、ds14050さんありがとうございます!

    P.S. ks さん、かむばぁぁぁっく!

     |  S  |  返信
スポンサーリンク