鬼車と鬼雲のどちらをメインにしたほうが良いのか
-
Kuroさん、こんにちは。
Meryの記事やフォーラムで鬼車と鬼雲についてKuroさんが下記のようなコメントしてしているのが気になったのでスレッドを立ち上げました。
- Ver 3.7.10の変更ログの3つ目のコメント:「鬼車と鬼雲、どちらをメインにするか、なかなか悩ましいですね。」
- QuickJSやDelphiに関するちょっとした雑談:「(まあ、それを言うと鬼雲/鬼車も同じ仕組みで実装してるし、RegExMode=2 も同じですけどw 試験的な実装なので、最終的にはどちらか廃止の方向ですね)」
コメントを読んで思ったことは、5年間リリースが止まっている鬼雲よりは、現在も最新版がリリースされている鬼車をメインにしたほうが長期的には良いと思いました。
なお、上記の意見はあくまで1つの意見として参考にしてもらえると幸いです。
| MSY-07 | 返信 -
トピック作成、ありがとうございます。
> コメントを読んで思ったことは、5年間リリースが止まっている鬼雲よりは、現在も最新版がリリースされている鬼車をメインにしたほうが長期的には良いと思いました。
ご意見、ありがとうございます。
現時点では、他のエディターでは鬼雲を使っているものが多いみたいですね。
鬼車は新機能がどんどん追加されているので、バグのリスクも気になるところですが、その辺がどうなるかですね。
鬼雲が更新されていないのは、もう完成度が高いからとも言えますが、Unicode 16 対応などのメンテナンスがないと、今後ちょっと厳しくなりそうですね。
鬼車の試験的な実装をお試しいただいた方は、ぜひ鬼車か鬼雲について、ご意見を聞かせていただけると嬉しいです。
| Kuro | 返信 -
ご返信ありがとうございます。
> 現時点では、他のエディターでは鬼雲を使っているものが多いみたいですね。
下記のテキストエディターでは鬼雲を使用しているので、鬼車に切り替えるかの判断をするのは時期尚早ですね。
- EmEditor(設定でOnigmo.RubyまたはOnigmo.Perlに変更)
- サクラエディタ(bregonig.dllを標準で内蔵)
- 秀丸エディタ(設定でhmonig.dllを指定)
> 鬼雲が更新されていないのは、もう完成度が高いからとも言えますが、Unicode 16 対応などのメンテナンスがないと、今後ちょっと厳しくなりそうですね。
鬼雲はVer 6.2.0でUnicode 11に対応したのが最後なので、そこは気になりますね。
| MSY-07 | 返信 -
時折繰り返し表現の「x*」を先読み、後読みで使いたくなってしまうのですが、その場合、鬼車はOKで、鬼雲では使えないのですよね。
もちろん鬼雲でも代替的な記述もできますし、言うほど大きく不便ではないのですけどね。
鬼車のアップデートによるバグ可能性はさておくと、やっぱり鬼車の方が便利だなーとは私も思います。
| yuko | 返信 -
鬼車、開発終了だそうですね。
GitHubリポジトリがアーカイブとなっていました。
衝撃…| yuko | 返信 -
> 鬼車、開発終了だそうですね。
> GitHubリポジトリがアーカイブとなっていました。
> 衝撃…鬼雲でなく鬼車が終了宣言したのか。存命な正規表現ライブラリはGoogleRE2とPCRE2ぐらいだろうか。
https://github.com/k-takata/Onigmo
https://github.com/kkos/oniguruma
https://github.com/google/re2
https://github.com/PCRE2Project/pcre2以下、雑談の昔話。
昔、殆どの処理系に付属する正規表現ライブラリはASCIIのみの対応で、特に¥に関わるダメ文字のあるSJISでは使い物にならなかった。
そんな頃、小飼氏がPerlの多言語対応を行い、Perl公式配布に主要なサードパーティライブラリを含む前は、Perlのコードの半分くらいは正規表現とUnicodeのテーブルだった。新しい言語では文字列型の内部コードがUnicodeであることも多く、外部の正規表現ライブラリが必要な場面も少なくなった。
Perlの拡張正規表現を使えるPCREもEOLとなり、Javascript等の正規表現と互換性を持つPCRE2に生まれ変わった。今どきのDelphi付属の正規表現ライブラリってどんななんでしょうね。
| enaka | 返信 -
> GitHubリポジトリがアーカイブとなっていました。
> 衝撃…鬼車の開発終了、これはかなりの衝撃ですね…。
鬼雲の更新が止まっていた頃、本家の鬼車が久しぶりに活発に更新され始めて、「おっ、これは!」とワクワクしていたのですが、まさか突然の開発終了とは…😱
フリーソフトの開発って、モチベーションの維持も大変ですし、開発者の方にも何か事情があったのかもしれませんね。
ただ、鬼車って以前も 5.9.5 あたりで長らく更新が止まっていた時期があったので、今回も「実質的に一区切り」ということなのかも。
もしかしたら、また気が向いたときに再開されることもあるかもしれませんし、前向きに応援していきたいところです。
> 今どきのDelphi付属の正規表現ライブラリってどんななんでしょうね。
Delphi に付属している
TRegExクラスは、鬼車と比べると機能面では物足りない印象がありますね。プログラムの補助的な用途で、ちょっとした正規表現が使えれば OK、という場面では十分だと思います。
ただ、テキストエディターのようにユーザーが自由に正規表現を活用できるような高度な用途では、Unicode 対応や柔軟性の面で少し機能不足かな、という印象です。
| Kuro | 返信 -
Ver 3.7.14のリリース対応お疲れさまでした。ダークモードの充実はすごくいいです。
外部コマンド出力の強化対応も、選択の置換と後に挿入の二通り登録していたコマンドをクリップボードに統一したりと、すっきりしました。
今、単語翻訳結果をツールチップで表示できないか試行錯誤中です。> ただ、鬼車って以前も 5.9.5 あたりで長らく更新が止まっていた時期があったので、今回も「実質的に一区切り」ということなのかも。
たしか当時、まだ仕様が固まっていない開発途中バージョンをRuby1.9に取り込まれて、モチベが下がっちゃったんだったかな。RubyMLでそっちでメンテするなら好きにしてみたいなやり取りがあってハラハラした。
Ruby側も自前の古い正規表現ライブラリのメンテが限界で、一刻も早く新しいライブラリが欲しくてRuby1.9は開発版だから仕様変更があっても構わない、と先走って行き違いが生じてしまっていた。> プログラムの補助的な用途で、ちょっとした正規表現が使えれば OK、という場面では十分だと思います。
>
> ただ、テキストエディターのようにユーザーが自由に正規表現を活用できるような高度な用途では、Unicode 対応や柔軟性の面で少し機能不足かな、という印象です。後方参照や先読み戻り読みの機能を省いて高速化するのが、最近の正規表現ライブラリのトレンドみたいです。
SRELLというC++の正規表現テンプレートを開発されている方が、興味深い比較と解説をされていました。
インテルのHyperscanというライブラリは初耳でした。https://www.akenotsuki.com/misc/srell/relibs.html
https://github.com/intel/hyperscan| enaka | 返信 -
> Ver 3.7.14のリリース対応お疲れさまでした。ダークモードの充実はすごくいいです。
ありがとうございます。共通ダイアログのダーク モード対応は、実は 2021 年から開発に着手していて、かなり時間がかかっているんですよね…。そう言っていただけると嬉しいです。
> 今、単語翻訳結果をツールチップで表示できないか試行錯誤中です。
もし外部ツールで難しい場合、マクロの
shell.ExecとshowTipを使うことで、もう少し柔軟に処理できるかもしれません。> たしか当時、まだ仕様が固まっていない開発途中バージョンをRuby1.9に取り込まれて、モチベが下がっちゃったんだったかな。
そんなウワサを聞いたことはありますが、モチベが下がる気持ちはすごくよく分かります…。
> SRELLというC++の正規表現テンプレートを開発されている方が、興味深い比較と解説をされていました。
情報ありがとうございます。かなり興味深い内容ですね。Ver 3.7.14 が落ち着いたら、じっくり読ませていただきますね。
| Kuro | 返信 -
> > 今、単語翻訳結果をツールチップで表示できないか試行錯誤中です。
>
> もし外部ツールで難しい場合、マクロの`shell.Exec`と`showTip`を使うことで、もう少し柔軟に処理できるかもしれません。transコマンド等を呼ぶだけでオンライン翻訳は実現可能なのですが、MSYS2で標準で用意されていないコマンドのため、代用のシェルスクリプト作成中です。マクロで組まないのは、どうせならBash上でも使いたいから。
https://qiita.com/Hashibirokou/items/280cb7466f7f61b517c4
https://qiita.com/adelie_pf/items/c6991d8e8a795f5333f8ローカルの英和・和英辞書検索はgrepとsedで簡単に実現できました。もっと単純なやり方があると思うのですがすぐには思いつかなかった。
英和・和英で辞書を分ければsed不要なんですが、このsedが何をしているのか一目でわかる方は古強者とお見受けします。$ wget http://www.namazu.org/~tsuchiya/sdic/data/gene95.tar.gz
$ tar xvf gene95.tar.gz
$ iconv -c -s -f SHIFT_JIS -t UTF-8 gene.txt > gene.dic$ wget https://kujirahand.com/web-tools/dict/gs9j1x9up98636/ejdic-hand-txt.zip
$ unzip ejdic-hand-txt.zip
$ sed 's/\t/\n/' ejdict-hand-utf8.txt > ejdict.dic$ mkdir /usr/share/dict
$ cp *.dic /usr/share/dict$ grep -A1 -wi ^"let's" /usr/share/dict/ejdict.dic
let's
let usの短縮形$ sed -n 'h;n;p;g;p' /usr/share/dict/ejdict.dic | grep -A1 -wi "日本語"
『日本の』;『日本人』(『語』)『の』 / 〈C〉『日本人』;《集合的に》日本人 / 〈U〉《冠詞をつけないで》『日本語』
Japanese| enaka | 返信 -
> transコマンド等を呼ぶだけでオンライン翻訳は実現可能なのですが、MSYS2で標準で用意されていないコマンドのため、代用のシェルスクリプト作成中です。マクロで組まないのは、どうせならBash上でも使いたいから。
なるほど、trans コマンド、知らなかったです。
DeepL を使う方法も面白そうですね (たしか API は無料版でもクレカ登録が必要だった気がするので、少しハードル高めですが…😅)
> 英和・和英で辞書を分ければsed不要なんですが、このsedが何をしているのか一目でわかる方は古強者とお見受けします。
sed は…私にはさっぱりです。でもツールチップの機能、お役に立てたなら嬉しいです。
> SRELLというC++の正規表現テンプレートを開発されている方が、興味深い比較と解説をされていました。
ご紹介いただいたリンク、楽しく読ませていただきました。
Hyperscan は初耳でしたが、鬼車の代わりになるかというと、ちょっと微妙なところもありますね。
速度特化なのは魅力ですが、先読み・戻り読みが使えないのは痛いですし、「キャプチャから取り出す処理は別のライブラリでやってね」スタイルも、なかなか尖ってますね。
鬼車の開発が終わってしまった今、「鬼車と鬼雲のどちらをメインにしたほうが良いのか」というスレッドのテーマについても、最初に MSY-07 さんが書かれていた、
> コメントを読んで思ったことは、5年間リリースが止まっている鬼雲よりは、現在も最新版がリリースされている鬼車をメインにしたほうが長期的には良いと思いました。
という前提が崩れてしまったので、判断がますます難しくなってきましたね🤔
| Kuro | 返信 -
> > 英和・和英で辞書を分ければsed不要なんですが、このsedが何をしているのか一目でわかる方は古強者とお見受けします。
>
> sed は…私にはさっぱりです。でもツールチップの機能、お役に立てたなら嬉しいです。sedはgrepに毛が生えただけです。UNIXパイプを考えたマキロイ先生が作ったtrと、トンプソン先生がedから取り出して一晩で作ったg/RE/pを見て、マクマホン先生がedからg/RE/sを取り出しただけ。
マクマホン先生がsedが企図通りに置換したかのデバック用に作ったcommを見て、マキロイ先生が作ったのがdiff。マキロイ先生はクイックソートアルゴリズムの研究でsortも作ってる。
トンプソン先生は有限オートマトンにならないからとedに別枠でv/RE/pというコマンドを作ったらしい。vrepは途中でgrep -vに吸収されたんでしょうか。$(CurText)を使うと選択しなくてもカーソル一の単語の辞書が引けて便利なんですが、改行込みで選択するとCPU100%掴んで固まります。入力:選択テキスト、を使う分には平気です。
多分、この書き方だと引数に改行が入ってダブルクオートが閉じず、Bashがプロンプトを出した状態でプロセスを掴んだままになる、からだと思うのですが、どう記述するのがよいでしょうか。タイトル: 英和辞書
コマンド: C:\msys64\usr\bin\bash.exe
引数: -c "grep -A1 -wi ^\"$(CurText)\" /usr/share/dict/ejdict.dic"
作業フォルダー: ${Dir}
アウトプットバーを使用する: オン
アウトプットバーにフォーカスを設定する: オフ
終了時に閉じる: オン
入力: なし
出力: ツールチップを表示
エンコード: UTF-8タイトル: 和英辞書
コマンド: C:\msys64\usr\bin\bash.exe
引数: -c "sed -n 'h;n;p;g;p' /usr/share/dict/ejdict.dic | grep -A1 -wi \"$(CurText)\""
作業フォルダー: ${Dir}
アウトプットバーを使用する: オン
アウトプットバーにフォーカスを設定する: オフ
終了時に閉じる: オン
入力: なし
出力: ツールチップを表示
エンコード: UTF-8タイトル: Bash
コマンド: C:\msys64\usr\bin\bash.exe
引数: -l
作業フォルダー: ${Dir}
アウトプットバーを使用する: オン
アウトプットバーにフォーカスを設定する: オフ
終了時に閉じる: オン
入力: 選択テキスト
出力: クリップボード
エンコード: UTF-8> Hyperscan は初耳でしたが、鬼車の代わりになるかというと、ちょっと微妙なところもありますね。
> 速度特化なのは魅力ですが、先読み・戻り読みが使えないのは痛いですし、「キャプチャから取り出す処理は別のライブラリでやってね」スタイルも、なかなか尖ってますね。100倍速いとは言え、便利な軽トラとスポーツカーを比較するようなものですしね。
インテルは最新版Hyperscanをクローズドソースにしたようなので候補から外してよいかと。早速フォークされてARM対応したようですが。> という前提が崩れてしまったので、判断がますます難しくなってきましたね🤔
Rubyのonigmoは少し手が入っているようですが、GCC15(C++20?)でビルドできないのを直したとか、機能強化はしていない模様。
誰かがメンテの手を挙げる可能性もあるし、現状で問題が起きるまで棚上げでいいんじゃないでしょうか。
とは言えCVEが出てから慌てるのもまずいですが、その時もきっと誰かかが直してくれるはず(他力本願)| enaka | 返信 -
grep にそんな歴史があったとは…。勉強になります。
私は Windows 3.1 から入った世代なので、コマンド入力系の OS にはあまり馴染みがなくて…。
Mery も、どちらかというとマウス操作中心の GUI 世代向けを意識しているところがあるので、ターミナル派の方には物足りないところがあるかもしれませんね。
> 多分、この書き方だと引数に改行が入ってダブルクオートが閉じず、Bashがプロンプトを出した状態でプロセスを掴んだままになる、からだと思うのですが、どう記述するのがよいでしょうか。
いただいた外部ツールの設定で試してみたところ、プロセスが掴まれたままになるような挙動は確認できませんでした。
プロセスが終了しない場合は、[外部ツール] メニューの [ツール ジョブの中止] が有効になり、ここから強制終了できます。
ただ、[英和辞書] や [和英辞書] のような設定では、改行を含めて文字列を選択しても [ツール ジョブの中止] が有効にならないため、プロセス自体は正常に終了しているようです。
$(CurText)や$(SelText)などの変数は、改行文字もそのまま外部プロセスに渡しています。たとえば、[英和辞書] ツールで以下のような 2 行のテキストを選択して実行すると、
apple orangeその 2 つの単語に対応する翻訳結果がまとめて返ってくる動作になるようです。
ちなみに、前回少し触れた、マクロで
shell.ExecとshowTipを使う方法だと、次のように書けます。英和辞書マクロ例:
const sel = document.selection; if (sel.isEmpty) { sel.selectWord(); } var e = shell.exec('C:\\msys64\\usr\\bin\\bash.exe -c "grep -A1 -wi \\"' + sel.Text.replace(/\n/g, ' ') + '\\" /usr/share/dict/ejdict.dic"'); showTip(e.stdOut);この例では、改行を半角スペースに置き換えて渡していますが、事前に文字列を加工できるぶん、より柔軟に外部ツールを扱えると思います。
> インテルは最新版Hyperscanをクローズドソースにしたようなので候補から外してよいかと。早速フォークされてARM対応したようですが。
そうですね。さすがに Intel の CPU 専用というのは、Mery のユーザーさんに怒られてしまいそうですし ^^;
ARM 対応も、見逃してあげればよかったのに…怒られてしまったようで、あまり深入りしない方がいいかもしれませんね。
> 誰かがメンテの手を挙げる可能性もあるし、現状で問題が起きるまで棚上げでいいんじゃないでしょうか。
そうですね。まだ、Mery では鬼雲のほうがメインの正規表現エンジンなので、しばらくは現状維持ということで…。
> とは言えCVEが出てから慌てるのもまずいですが、その時もきっと誰かかが直してくれるはず(他力本願)
そのときは、何かしら対策を考えないといけないですね。
簡単な脆弱性であれば、私のほうで対処できるかもしれませんが、外部ライブラリのメンテまではできれば手を出したくないところです。(とはいえ、既に鬼車のソースコードはカスタマイズしちゃってますが…😅)
| Kuro | 返信 -
> grep にそんな歴史があったとは…。勉強になります。
トンプソン先生が一晩でやってくれましたシリーズは、いろいろあるので調べると面白いです。
UTF-8を考案したのとか。さすがに一晩では実装までは無理だったようですが。> 私は Windows 3.1 から入った世代なので、コマンド入力系の OS にはあまり馴染みがなくて…。
> Mery も、どちらかというとマウス操作中心の GUI 世代向けを意識しているところがあるので、ターミナル派の方には物足りないところがあるかもしれませんね。端末入力もbash-completionやfzyコマンドのようなインテリセンス補完が当たり前になって、ずいぶん簡単で便利になりました。
WindowsPowerShellは全然使いこなせていませんが。年寄りの自分が新しいものについていけていないだけともいう。> いただいた外部ツールの設定で試してみたところ、プロセスが掴まれたままになるような挙動は確認できませんでした。
:
> その 2 つの単語に対応する翻訳結果がまとめて返ってくる動作になるようです。選択範囲の最後が改行だと発生するようです。途中に入る改行だと上手いこと2つの単語を検索してくれます。
どうも検索でヒットせずに、しばらく待つと巨大な空白のツールチップが開いて処理が戻ってきました。
普通に検索にヒットしない場合はすぐ戻ってくるのに、何にそんなに時間を食っているのだろう?> ちなみに、前回少し触れた、マクロで`shell.Exec`と`showTip`を使う方法だと、次のように書けます。
:
> この例では、改行を半角スペースに置き換えて渡していますが、事前に文字列を加工できるぶん、より柔軟に外部ツールを扱えると思います。確かに、ダブルクオート、リダイレクト、セミコロンなどは加工しておかないと問題になりますね。
> そうですね。さすがに Intel の CPU 専用というのは、Mery のユーザーさんに怒られてしまいそうですし ^^;
AMDのCPUでも動くからMeryでは問題ないかも。スナドラのPCでMeryを動かしている人っているんだろうか。
| enaka | 返信 -
> 選択範囲の最後が改行だと発生するようです。途中に入る改行だと上手いこと2つの単語を検索してくれます。
こちらの環境でも再現しました。操作が固まったような感じになりますね。
> 普通に検索にヒットしない場合はすぐ戻ってくるのに、何にそんなに時間を食っているのだろう?
アウトプット バーを表示して確認したところ、どうやら辞書ファイルの全行 (たぶん 200 万文字くらい?) がそのまま返ってきてるっぽいです。
ツールチップの仕様上、表示できるのは多くても数千文字程度だと思うので、そのあたりはコマンド側で対処が必要ですね。
コマンドラインツールには詳しくないのですが、たとえば grep に渡す前に、コマンド側で trim のようなものを使って末尾の改行を取り除くことはできないでしょうか?
> AMDのCPUでも動くからMeryでは問題ないかも。スナドラのPCでMeryを動かしている人っているんだろうか。
なるほど、「Intel の CPU 以外では動作しない」とあったので、そういうものかと勘違いしてました。
スナドラで Mery を使ってる人は…さすがにいない気がします (笑)
ちなみに、Wine 経由での使用についてお問い合わせをいただくことはありますが、Wine も基本サポート対象外なので、あまり気にしなくて大丈夫だと思います。
| Kuro | 返信 -
> アウトプット バーを表示して確認したところ、どうやら辞書ファイルの全行 (たぶん 200 万文字くらい?) がそのまま返ってきてるっぽいです。
理解。改行ごとまとめて文字列をコマンドに渡すのではなく、一行ごとに複数回コマンドを実行していたんですね。
そのため、grep "" ejdict.dic して全ヒットしていたようです。> コマンドラインツールには詳しくないのですが、たとえば grep に渡す前に、コマンド側で trim のようなものを使って末尾の改行を取り除くことはできないでしょうか?
空検索しないよう、検索パタン修正で回避できました。
NG -c "grep -A1 -wi \"\<$(CurText)\>\" /usr/share/dict/ejdict.dic"
OK -c "grep -A1 -wi \"\<$(CurText)\{1\}\>\" /usr/share/dict/ejdict.dic"他のgrep互換コマンドも探して試してみたのですが、highwayは10年前に開発が止まってますが鬼車の力ですべての日本語コードを横断検索できてよいです。
https://github.com/tkengo/highway
> ちなみに、Wine 経由での使用についてお問い合わせをいただくことはありますが、Wine も基本サポート対象外なので、あまり気にしなくて大丈夫だと思います。
MacOS15+Rosetta2+Wineで動かしている人はネットのどこかで見た気がします。今探したところでは、秀丸は動いているようですがMeryは見つかりませんでした。MacOS15+Rosetta2、AVX2命令まで行けるのか。
MSY-07さんの実験でWindows2000でもMeryが起動するようなので、Wineもある程度期待できそうです。問題が起きそうなのはDirect WriteとPrintとマクロ周りでしょうか。VirtualBOX+ReactOSとか実験してみたい。
| enaka | 返信 -
> 理解。改行ごとまとめて文字列をコマンドに渡すのではなく、一行ごとに複数回コマンドを実行していたんですね。
なるほど、挙動としてはそのように見えますね。ただ、Mery 側で特にそういった仕様にしているわけではありません。
Mery では、Win32 API の CreateProcessW に改行文字を含んだ文字列をそのまま渡しているだけです。
念のため、受け取った引数を表示するだけのシンプルなコマンドラインツールを作成して挙動を確認してみましたが、コマンドが複数回実行されているということはなく、コマンドラインツール側では引数が 1 つ、改行文字もそのまま含まれている状態で受け取られていました。
おそらくですが、grep コマンド側の仕様で、改行を含む引数を複数の単語として解釈しているのかもしれませんね。
> 他のgrep互換コマンドも探して試してみたのですが、highwayは10年前に開発が止まってますが鬼車の力ですべての日本語コードを横断検索できてよいです。
鬼車対応は面白いですね。名前からしても速そうですし、日本語対応も頼もしいです。
> MSY-07さんの実験でWindows2000でもMeryが起動するようなので、Wineもある程度期待できそうです。問題が起きそうなのはDirect WriteとPrintとマクロ周りでしょうか。VirtualBOX+ReactOSとか実験してみたい。
以前に確認した限りでは、Wine 上では DirectWrite は動作しませんでした。それ以外の部分については、ある程度動作していたように思います。
マクロもたしか動作した記憶がありますが、記憶が曖昧です。
一応、Wine はサポート対象外という扱いにしていますが、Wine 向けに特別な対応をすることはなくても、Mery を Wine 上で使った際に発生する問題で、Windows 上でも再現の可能性があるものについては、ご報告をいただければ対応するようにしています。
【参考】Wine上のMery Ver 3.6.1 (64 ビット版) ポータブルが起動時にクラッシュする
https://www.haijin-boys.com/discussions/7496| Kuro | 返信 -
> おそらくですが、grep コマンド側の仕様で、改行を含む引数を複数の単語として解釈しているのかもしれませんね。
Bash上では改行(Ctrl-V Enterで入力)を含んだ検索パタンでも再現しませんでした。
$ grep -A1 -wi "apple^Mzoo" /usr/share/dict/ejdict.dic
(ヒットせず)考えるに検索パタンのファイル渡しの時の挙動と同じです。
$ echo ^apple$ > word.txt
$ echo ^zoo$ >> word.txt
$ grep -A1 -wi -f word.txt /usr/share/dict/ejdict.dic
apple
『リンゴ』;リンゴの木
--
zoo
『動物園』望み通り動いているので、妖精さんの仕業として飲み込むことにします(笑)
> > 他のgrep互換コマンドも探して試してみたのですが、highwayは10年前に開発が止まってますが鬼車の力ですべての日本語コードを横断検索できてよいです。
> 鬼車対応は面白いですね。名前からしても速そうですし、日本語対応も頼もしいです。PKGBUILDファイルを書いて野良パッケージ化すれば、MSYS2でも簡単に使えます。
$ cat PKGBUILD.highway
name='highway'pkgname="${name}"
pkgver='1.1.0'
pkgrel='1'
pkgdesc="highway: High performance source code search tool"
arch=('x86_64')
url="https://github.com/tkengo/highway/"
license=('MIT')
source=(
"https://github.com/tkengo/${pkgname}/archive/refs/tags/v${pkgver}.tar.gz"
)
md5sums=(SKIP)build() {
cd "${srcdir}/${pkgname}-${pkgver}"
./tools/build.sh
}check=(SKIP)
package() {
cd "${srcdir}/${pkgname}-${pkgver}"
make DESTDIR="${pkgdir}" install
}$ makepkg -p PKGBUILD.highway
$ pacman -D highway-1.1.0-1-x86_64.pkg.tar.zst
$ /usr/bin/hw -A1 -Nwi "^apple$" /usr/share/dict/ejdict.dic
/usr/share/dict/ejdict.dic
apple
『リンゴ』;リンゴの木> 以前に確認した限りでは、Wine 上では DirectWrite は動作しませんでした。それ以外の部分については、ある程度動作していたように思います。
> マクロもたしか動作した記憶がありますが、記憶が曖昧です。JScript9.dllをコピーすればマクロも動く気はするのですが、互換エンジン実装まではしていないと思ってました。
オープンソースになったのをWineが取り込んだのかな?> 【参考】Wine上のMery Ver 3.6.1 (64 ビット版) ポータブルが起動時にクラッシュする
> https://www.haijin-boys.com/discussions/7496メモリ割り当てのランダム化はLinuxディストリビューションが有効化した際も、実質メンテナ不在の結構なレガシーアプリが振るい落とされていました。
| enaka | 返信 -
> Bash上では改行(Ctrl-V Enterで入力)を含んだ検索パタンでも再現しませんでした。
Ctrl-V Enter だと改行文字として認識されていないのかもしれませんね。
$ newline=$'\n' $ grep -A1 -wi "apple${newline}zoo" /usr/share/dict/ejdict.dic合ってるかどうかちょっと自信ないですが、こんなふうに改行文字を渡してあげたら再現できました。
> 望み通り動いているので、妖精さんの仕業として飲み込むことにします(笑)
ですね (笑) 結果オーライってことで!
> PKGBUILDファイルを書いて野良パッケージ化すれば、MSYS2でも簡単に使えます。
情報ありがとうございます。
ただ、ちょっと私にはまだレベルが高めでして…。教えていただいた内容をコピペして
makepkg -p PKGBUILD.highwayを試してみたのですが、エラーが出てしまいました。たぶん何かパッケージが足りないだけだと思うのですが、調べ始めると沼りそうなので… ^^;
> JScript9.dllをコピーすればマクロも動く気はするのですが、互換エンジン実装まではしていないと思ってました。
> オープンソースになったのをWineが取り込んだのかな?気になったので Ubuntu (22.04) の Wine (10.6) で確認してきました。
jscript9.dll かどうかまでは分かりませんでしたが、特に何もしなくてもマクロは JScript のバージョン 5.8 で動作しました。
DirectWrite も、細かくはチェックしていませんが、一応動いているようです。レンダリング モードや OpenType 機能も大丈夫そうです。
> メモリ割り当てのランダム化はLinuxディストリビューションが有効化した際も、実質メンテナ不在の結構なレガシーアプリが振るい落とされていました。
なるほど、そういう目的の機能なのかどうかは分かりませんが、アプリ側がそれなりに丁寧に作られていないと、ふるい落とされてしまいそうですね。
このあたりは、事前の検証にも限界があるので、問題が発生したらその都度対応していくしかなさそうです。
| Kuro | 返信 -
こんばんは~😉
鬼車の開発終了を受け、みなさんからのご意見を参考にしつつ、今後の展望として PCRE2 の導入を検討しています。
そのほか、Google の RE2 や Intel の Hyperscan なども調べてみたのですが、いずれも鬼車と比べると、機能面では少し物足りない印象でした。(動作速度は圧倒的に速いのですが…)
PCRE2 は、正規表現エンジンとして機能が豊富で、Unicode 対応も充実しており、動作速度も比較的高速です。さらに、現在も継続的にメンテナンスされている点も含め、個人的には有力な候補かなと感じています。
ただ、鬼車は Ruby 系構文、PCRE2 は Perl 互換構文なので、方言の違いが気になるかたもいらっしゃるかもしれません。
逆に、Perl 互換が好きなかたには気に入っていただける可能性もありますが😅
というわけで、Mery v3.8.4 以降で、PCRE2 を試験的に実装してみました。
私は Ruby だとか Perl だとか、「なにそれポケモンですか?」という感じの人間なので、正規表現についてはまったく詳しくありません。
そのため、正規表現に詳しいかたや、PCRE2 に興味のあるかたに、
- PCRE2 対応のアリ・ナシ
- 対応する場合に検討すべき点
- 実際の使い勝手や互換性
などについて、ご意見をいただけると嬉しいです。
PCRE2 を有効にするには、
pcre2-16.dllをMery.exeと同じフォルダーに配置するだけです。
PCRE2 v10.47 (64 ビット版) [258,359 バイト 2026/05/16]
https://www.haijin-boys.com/download/PCRE2-x64-10.47.zip
ウイルスチェック: https://www.virustotal.com/#/file/e53da2891882cef0b77f4aefe6679d6c035940e5501f690fb6c52fcce64711b4こちらでビルドした
pcre2-16.dllを掲載しておきます。
ウイルスなどが不安なかたは、ご自身でビルドしていただいても大丈夫です。
【参考】https://github.com/PCRE2Project/pcre2
この機能を有効にすると、以下の仕様が変更されます。
- [オプション] → [基本] カテゴリの [正規表現に鬼車を使用する] オプションが消えます
- 検索ダイアログの [>] ボタンのメニューから、以下のオプションが消えます
- [選択範囲の先頭を行頭とみなさない]
- [選択範囲の終端を行末とみなさない]
- 代わりに、検索ダイアログの [正規表現] の右側に […] ボタンが表示され、クリックすると [高度] オプションダイアログが表示されます
[高度] オプションでは、以下の設定が利用できます。
- 選択範囲の先頭を行頭とみなさない
- 従来の [>] メニューから移動しました
- 選択範囲の終端を行末とみなさない
- 従来の [>] メニューから移動しました
- 次を検索で重ならない文字列のみ一致する
- [次を検索] の動作を、Windows メモ帳準拠にします
- すべて置換で繰り返し置換しない
- 正規表現置換の動作を、いわゆる
/g的な挙動にします
【参考】https://www.haijin-boys.com/wiki/よくある質問#正規表現で行頭の置換が期待どおりに動作しない
- 正規表現置換の動作を、いわゆる
- 折り返しを超えて強調表示する
- 従来の隠しオプション
RegExMode=2に相当します
【参考】https://www.haijin-boys.com/wiki/よくある質問#改行や折り返しをまたぐ検索が強調表示されない
- 従来の隠しオプション
- 正規表現エンジン
- [正規表現に鬼車を使用する] オプションはこちらへ移動しました
- PCRE2 を利用する場合は、ここで選択してください
…と、少し長くなってしまいましたが、以上が概要説明です。
今回、特に検証していただきたい点としては、PCRE2 の実用性についてです。
もちろん、
- PCRE2 は使いづらい
- 必要ないと思う
- 導入しないほうがいい
といった否定的なご意見でもまったく構いませんので、率直にフィードバックをいただけると助かります。
ちなみに、鬼車 (鬼雲) には最適化された [前を検索] が実装されているのですが、PCRE2 にはそれに相当する機能がありません。
そのため、正規表現によっては [前を検索] が極端に重くなったり、最悪の場合フリーズする可能性もあります。
念のため、大切なファイルはバックアップを取ったうえでお試しください。
現在、そのあたりを Mery 側でなんとか改善できないか模索している段階ですので、重い・フリーズする正規表現などを見つけた場合は、ぜひ教えていただけると助かります。
繰り返しになりますが、私は正規表現について全然詳しくないので、もし正規表現ガチ勢のかたや、正規表現警察のかたがご意見をくださる場合は、どうか優しく教えていただけると嬉しいです。
| Kuro | 返信 -
> というわけで、Mery v3.8.4 以降で、PCRE2 を試験的に実装してみました。
サプライズ!
> 私は Ruby だとか Perl だとか、「なにそれポケモンですか?」という感じの人間なので、正規表現についてはまったく詳しくありません。
「宝石ですか?」ではない時点で非一般人かもしれません(笑)
Perlの作者ラリー・ウォール氏は敬虔なクリスチャンのため、新約聖書の高価な真珠の逸話にちなみ命名されたことまで知っていると教養人。https://en.wikipedia.org/wiki/Parable_of_the_Pearl
当時のダイヤは加工しにくく使い道のない石、マリア様の蒼であるサファイヤのほうが高価。さらに天然物しかない真珠は最も高価な宝石だった。
聖人に付随する色や道具のことをアトリビュートと言います。聞いたことのある単語だ。> ただ、鬼車は Ruby 系構文、PCRE2 は Perl 互換構文なので、方言の違いが気になるかたもいらっしゃるかもしれません。
EMCAScript の拡張正規表現は Perl 由来であり、PCRE2 の拡張正規表現は Javascriptなどに仕様を寄せたため、エディタ操作とマクロ記述で正規表現を統一できて、相性は良いかもしれません。
>PCRE2 を有効にするには、pcre2-16.dll を Mery.exe と同じフォルダーに配置するだけです。
MSYS2でPCRE2をインストールできるのですが、DLLファイル名が違いました。
Meru.iniで指定した場所とファイル名でDLLがあれば、MeryでPCRE2を選択できるとうれしいです。Windowsネイティブ版
$ pacman -S mingw-w64-ucrt-x86_64-pcre2
:
$ ls -l /ucrt64/bin/*pcre2*
-rwxr-xr-x 1 enaka none 654082 2025-10-23 01:42 /ucrt64/bin/libpcre2-16-0.dll
-rwxr-xr-x 1 enaka none 625922 2025-10-23 01:42 /ucrt64/bin/libpcre2-32-0.dll
-rwxr-xr-x 1 enaka none 718625 2025-10-23 01:42 /ucrt64/bin/libpcre2-8-0.dll
-rwxr-xr-x 1 enaka none 44974 2025-10-23 01:42 /ucrt64/bin/libpcre2-posix-3.dll
-rwxr-xr-x 1 enaka none 2195 2025-10-23 01:42 /ucrt64/bin/pcre2-config
-rwxr-xr-x 1 enaka none 93962 2025-10-23 01:42 /ucrt64/bin/pcre2grep.exe
-rwxr-xr-x 1 enaka none 314707 2025-10-23 01:42 /ucrt64/bin/pcre2test.exeMSYS2環境版
$ pacman -S pcre2
:
$ ls -l /usr/bin/*pcre2*
-rwxr-xr-x 1 enaka none 397714 2025-10-22 17:34 /usr/bin/msys-pcre2-16-0.dll
-rwxr-xr-x 1 enaka none 383378 2025-10-22 17:34 /usr/bin/msys-pcre2-32-0.dll
-rwxr-xr-x 1 enaka none 443825 2025-10-22 17:34 /usr/bin/msys-pcre2-8-0.dll
-rwxr-xr-x 1 enaka none 11325 2025-10-22 17:34 /usr/bin/msys-pcre2-posix-3.dll
-rwxr-xr-x 1 enaka none 2192 2025-10-22 17:34 /usr/bin/pcre2-config
-rwxr-xr-x 1 enaka none 50274 2025-10-22 17:34 /usr/bin/pcre2grep.exe
-rwxr-xr-x 1 enaka none 265393 2025-10-22 17:34 /usr/bin/pcre2test.exe> 繰り返しになりますが、私は正規表現について全然詳しくないので、もし正規表現ガチ勢のかたや、正規表現警察のかたがご意見をくださる場合は、どうか優しく教えていただけると嬉しいです。
正規表現を使いこなす上で、以下2冊はマストバイ。
古本なら合わせて2~3000円ぐらい。10年以上前の本なので情報が古くなったところがあるのが玉に瑕。
入門を流し読みして、詳説を拾い読みするだけで十分です。正規表現技術入門 最新エンジン実装と理論的背景
https://gihyo.jp/book/2015/978-4-7741-7270-5詳説 正規表現 第3版
https://www.oreilly.co.jp/books/9784873113593| enaka | 返信 -
詳しい情報をありがとうございます。
なるほど、Perl の語源ってそういう由来だったんですね。完全に「なんか強そうな単語」ぐらいの認識でした😅
しかも、当時は真珠が最も高価だったとか、アトリビュートの話まで含めて、なかなか奥が深い世界ですね。
> EMCAScript の拡張正規表現は Perl 由来であり、PCRE2 の拡張正規表現は Javascriptなどに仕様を寄せたため、エディタ操作とマクロ記述で正規表現を統一できて、相性は良いかもしれません。
たしかに、それはありそうですね。
鬼車は自由度が高い反面、Perl 系とは少し毛色が違う印象もありましたし、そのあたりの統一感は良い方向に働く可能性もあるかもしれませんね。
> MSYS2でPCRE2をインストールできるのですが、DLLファイル名が違いました。
先日掲載した
pcre2-16.dllは、Visual Studio 2013 でビルドしたものです。(なぜ 2013 かというと、Windows XP にも対応させるためです)教えていただいた方法で、こちらでも MSYS2 に PCRE2 をインストールできました。
「Windows ネイティブ版」のほうは、
libpcre2-16-0.dllをpcre2-16.dllにリネームし、Mery.exe と同じフォルダーに配置することで動作しました。一方、「MSYS2 環境版」のほうは動作しませんでした。MSYS2 ランタイムに依存しているのか、通常の Windows ネイティブな DLL とは扱いが異なるのかもしれません。
> Meru.iniで指定した場所とファイル名でDLLがあれば、MeryでPCRE2を選択できるとうれしいです。
MSYS2 環境の PCRE2 を直接利用したい、という意図なのかなと思いますが、試しに Mery の開発環境で
C:\msys64\usr\bin\msys-pcre2-16-0.dllを直接参照させてみたところ、動作しませんでした。また、DLL の読み込みについては、意図しない DLL を読み込んでしまう問題などもあるため、Windows アプリとしては、アプリケーションのフォルダー内に限定しておくほうが、安全面では望ましいかなと思います。
> 正規表現を使いこなす上で、以下2冊はマストバイ。
> 古本なら合わせて2~3000円ぐらい。10年以上前の本なので情報が古くなったところがあるのが玉に瑕。
> 入門を流し読みして、詳説を拾い読みするだけで十分です。書籍情報もありがとうございます。
「詳説 正規表現」のほうは、鈍器というのを見かけたことはあるのですが、なかなか怖くて手を出せずにいます。
Amazon で見てみたら、私のポケットマネー的にはちょっと「ぐぬぬ…」なお値段でしたので、今度ブックオフに行く機会があれば探してみようと思います。
| Kuro | 返信 -
> しかも、当時は真珠が最も高価だったとか、アトリビュートの話まで含めて、なかなか奥が深い世界ですね。
歴史のIFとして、真珠裁判で養殖真珠が偽物とされていたら中東の安い石油が生まれず、石炭産業から石油産業へのシフトが大幅に遅れていたかもしれません。
真珠裁判で日本の養殖真珠が本物と認められて真珠相場が暴落、イギリスが天然真珠目当てで植民地にしたクウェートの真珠漁産業が壊滅、石油産業に活路を見出したのが中東問題の始まり。> MSYS2 環境の PCRE2 を直接利用したい、という意図なのかなと思いますが、試しに Mery の開発環境で `C:\msys64\usr\bin\msys-pcre2-16-0.dll` を直接参照させてみたところ、動作しませんでした。
多分、MSYS2とネイティブのABIに互換性がないから、仕方ないです。
> また、DLL の読み込みについては、意図しない DLL を読み込んでしまう問題などもあるため、Windows アプリとしては、アプリケーションのフォルダー内に限定しておくほうが、安全面では望ましいかなと思います。
手コピーはライブラリの更新漏れが怖いですが、MSYS2で一括管理していると、その辺が楽です。今回はシンボリックリンクで対応しました。
MeryでDLLを一括配布されるようになれば不要と思います。おっしゃる通りパスの通った場所を自動で追加は危険なので、Mery.iniで直接パスとファイル名を指定できれば、と考えていました。
一時的に別バージョンのDLLをテストしたい時など、隠しオプションとしてあれば便利かなと。> 「詳説 正規表現」のほうは、鈍器というのを見かけたことはあるのですが、なかなか怖くて手を出せずにいます。
枕にちょうどいい高さ、というのは見かけたかも。
> Amazon で見てみたら、私のポケットマネー的にはちょっと「ぐぬぬ…」なお値段でしたので、今度ブックオフに行く機会があれば探してみようと思います。
詳細の初版はAmazonで最安53円でした(笑)
2版以降との違いは、Javascriptなど言語ごとの方言の章の追加、初版以降の新しい拡張正規表現への対応、などです。
https://www.amazon.co.jp/dp/4900900451| enaka | 返信 -
ええっ、そこまで繋がるんですか…!
正規表現の話から、中東情勢の歴史 IF に飛んでいって、スケールが大きすぎてびっくりしました😂
世界史は苦手科目だったもので…。しかし、真珠 → 石油という流れは、歴史の連鎖として面白いですね。
> 多分、MSYS2とネイティブのABIに互換性がないから、仕方ないです。
なるほど、こちらは単純に DLL だけ差し替えれば動く、という話ではなさそうですね。
> 手コピーはライブラリの更新漏れが怖いですが、MSYS2で一括管理していると、その辺が楽です。今回はシンボリックリンクで対応しました。
> MeryでDLLを一括配布されるようになれば不要と思います。シンボリックリンクで対応していただけたとのことで、ありがとうございます。
現状は「とりあえず試験実装してみた」という段階なので DLL 手配置方式にしていますが、もし正式対応するなら、Mery に同梱するかたちになると思います。
ビルドオプションの違いなどで挙動が変わる可能性もありますし、そのほうが管理もしやすそうですしね。
> 一時的に別バージョンのDLLをテストしたい時など、隠しオプションとしてあれば便利かなと。
なるほどです。
常用というより、「検証用途」や「切り替えテスト用途」という感じですね。
> 詳細の初版はAmazonで最安53円でした(笑)
私のポケットマネーは53円です…。って、送料のほうが戦闘力高いですね😂
> 2版以降との違いは、Javascriptなど言語ごとの方言の章の追加、初版以降の新しい拡張正規表現への対応、などです。
おーん、言語ごとの方言の章は欲しいところですし、新しい拡張正規表現への対応も気になるところです…。
とりあえず、ブックオフに行ってきました。
…が、残念ながら正規表現関連の書籍は 1 冊もありませんでした。
代わりに「C言語で学ぶアルゴリズムとデータ構造」が 500 円で売られていて、危うく買いそうになりましたが、なんとか耐えました。
というわけで、ここはひとつ、みなさんの開発支援を有効活用させていただきまして、ブックオフのオンラインストアで 2 冊注文しました。
これで夜はぐっすり眠れそうです。(枕にするんかい!)
| Kuro | 返信