Linuxでの動作報告（とバグ報告）
-
Ubuntu 26.04 LTS + Wine 10.0
Mery 3.8.8 x64（実質的にエミュレーション）縦書きエディタとしてお世話になっております。
WindowsからLinuxに移住した影響でMeryを数ヶ月は使っていなかったのですが、数日前にLinux上でも動作させることに成功したので、そのことを報告します。Linuxでも縦書きができるのは感動です。
2025年10月のWindows 10のメインサポート終了のタイミングでLinuxに移住した民も多いと思われるので、情報共有として少々詳しめに書かせていただきます。（動作状況）
基本的な機能はおおむね使えています。配色テーマの変更もフォントの変更もできます。Zenモードも問題なく動作します。クラッシュもなくエディタとして問題なく使えています。
操作している途中でメニューの一部が動かなくなるなど不具合はあるものの、これは動作環境であるWine側の問題であり、単にMeryを再起動すればもとに戻ります。
ただし、DirectWriteを使おうとすると画面描画が壊れてしまうので、半角英数の等幅化はできません。（Linux上で動作させるまでの手順）
0. Wineのインストール
まずはシステムのセキュリティ更新をチェックして最新にする。
Ubuntu 26.04 LTSの場合、アプリセンター（snap）を開いてWineを検索する。フィルターはdebianパッケージ。該当項目を開けば、インストールのボタンがある。
Zorin OS 18の場合、Windows App Supportをインストールする。1. Wineに日本語フォントをインストール
文字化け（豆腐化）防止に必須。
ホームディレクトリに.wineという隠しディレクトリがある。UbuntuやZorin OSはファイルマネージャーがNautilusなので、Ctrl + Hで隠しディレクトリを表示できる。
.wineを開くと、drive_cというディレクトリがあるので、windows/Fontsとたどれる。そこに日本語フォントファイル（ttfやotfなど）を配置する。2. インストーラーを使ってインストールする
ポータブル版も動かせるが、インストーラー版が楽。
Ubuntuの場合は端末を開いてwine uninstallerを実行。
Zorin OSの場合はZorinメニューからWineソフトウェアの削除を実行。
プログラムの追加と削除のダイアログが表示されるので、Meryのインストーラのexeファイルを実行。以降の手順はWindowsの場合とほぼ同じ。
アンインストールのときも同じダイアログを使う。3. 再起動後に使えるようになる
システムを再起動すればWindowsスタートメニューと同様にアプリ一覧にアイコンが追加され、Meryが使えるようになる。ただし、開くときと保存するときのファイルパスはやや癖があるので、慣れるまでは注意が必要。4. 解像度の調整
ディスプレイのDPIの都合でメニューの文字が小さいなど読みづらい場合、WineのDPIの調整を行う。
Ubuntuの場合は端末でwinecfgを実行。
Zorin OSの場合はZorinメニューからWine設定を開く。
画面タブからDPIを調整できる。（バグ報告）
日本語入力が有効のとき、Zenモードを切り替えるためのCtrl + K, Zがうまく機能しません。以前に修正していただいたものの、この問題は再発しているようです。（シンタックスハイライトについて）
難しい問題であることを十分に承知のうえで書かせていただきます。構文ファイルの構造からしてEmEditorを参考に作られたのだと推察しますが、あれはキーワードハイライトであってシンタックスハイライトではありません。
Ubuntuを使っていると、どうしてもシステムに最初から入っているGNOME Text Editorと見比べてしまいます。とくにTeXとXMLのハイライトを見ていて性能差が顕著だったので。
(La)TeXの場合は\text{...}のようにバックスラッシュと単語のセットである制御綴り（コントロールシーケンス）をハイライトする必要があります。実際にコンパイラが見ているのはその形なので。これには字句解析（リテラル化、トークン化）が必要です。
XMLの場合は要素名や属性名をDTDファイルで自由に決められるのでキーワードでは対処できず、XMLとしての構文解析が必要です。
あるいはC++の0b0101や0x23という数値リテラルの検出にも字句解析が必要になります。
素人ながら調べてみたところ、highlight.jsというプロジェクトがシンタックスハイライトの参考になる気がしました。構文定義ファイルを見たところ正規表現でしっかり書かれていたので。（お詫び）
長々と書いてしまったものの、Meryそのものは本当に気に入っています。継続的な開発に感謝します。| Yuishin | 返信 -
Mery をご愛用いただき、また Linux + Wine 環境での詳細な動作報告をありがとうございます。
インストール方法や日本語フォント、DPI の調整方法まで詳しくまとめていただき、Linux 環境で Mery を利用される方にとっても参考になると思います。
まず最初にお伝えしておきたいのですが、Wine での動作はサポート対象外とさせていただいています。
とはいえ、Wine 上で発生する不具合であっても、Windows 環境でも起こり得る問題については、こちらでもできる限り対応を検討します。一方で、Wine 特有の挙動に合わせたカスタマイズは行わない方針ですので、どうかご理解ください。
そういうわけで、手元に Ubuntu 26.04 が動作するスペックの PC がないため、Linux Mint 22.3 をインストールして確認してみました。
ソフトウェアマネージャーから Wine をインストールしたところ v9.0 ということで少し古いバージョンでしたが、一応、Mery は動作しました。教えていただいた方法で、日本語も問題なく表示できるようになりました。
> （バグ報告）
> 日本語入力が有効のとき、Zenモードを切り替えるためのCtrl + K, Zがうまく機能しません。
> 以前に修正していただいたものの、この問題は再発しているようです。こちらの件については、以前ご報告いただいた際にも検証しましたが、こちらの環境では特に問題なく動作しており、現象を再現できなかったため、これまで特に対応していませんでした。
【参考】IMEが有効なときが2段階のショートカットキーがきかない
https://www.haijin-boys.com/discussions/7947今回、改めて Mery v3.8.8 (x64) で確認してみましたが、Windows 11 (Version 25H2, OS Build 26200.8875, 64-bit Edition) 環境で、Windows 11 標準の IME を使用し、「以前のバージョンの Microsoft IME を使用する」のオン/オフを切り替えた場合や、Google 日本語入力を使用した場合でも、正常に動作しました。
ただし、Linux Mint + 入力方式フレームワーク Fcitx で試してみると、ご指摘のとおり、日本語入力がオンの状態では
Ctrl + K,Zのショートカットキーが動作しませんでした。これは、キー入力が単独キー (Z など) になった場合、Linux の日本語入力の仕組みが先にそのキー入力を受け取ってしまうために起きているようです。
そのため、キー割り当てを単独キーではなく、
Ctrl + K,Ctrl + ZのようにCtrlと組み合わせることで回避できました (もちろん、Ctrl キーは押しっぱなしにしておく必要がありますが)シンタックスハイライトについても、詳しいご意見をありがとうございます。
ご指摘のとおり、現在の Mery の構文ファイルによる色分けは、基本的にはキーワードや正規表現などを利用したもので、本格的な字句解析・構文解析を行うシンタックスハイライトとは異なります。
TeX の制御綴りや XML の要素・属性、C++ の数値リテラルなど、単純なキーワード検索だけでは正確に判定できないものがあることは認識しています。
本格的なシンタックスハイライトを実現するには、構文ごとの字句解析や状態管理など、現在の Mery の色分け処理とは異なる仕組みが必要になります。
さらに、そうした仕組みをユーザー側で自由に設定できるようにするとなると、現在の Mery のようにシンプルな GUI で設定できるものではなくなってしまいます。
おそらく、構文解析エンジンの仕様に合わせた定義ファイルのようなもの (highlight.js の構文定義ファイルのようなもの) を、ユーザー側で記述してもらうかたちになるのかしら…。
すぐに対応できるものではありませんが、構文解析エンジンを開発するというのも技術的には興味深いテーマなので、今後のアイデアの一つとして覚えておこうと思います。
詳しい動作報告と貴重なご意見をありがとうございました。
| Kuro | 返信 -
> 本格的なシンタックスハイライトを実現するには、構文ごとの字句解析や状態管理など、現在の Mery の色分け処理とは異なる仕組みが必要になります。
>
> さらに、そうした仕組みをユーザー側で自由に設定できるようにするとなると、現在の Mery のようにシンプルな GUI で設定できるものではなくなってしまいます。
>
> おそらく、構文解析エンジンの仕様に合わせた定義ファイルのようなもの (highlight.js の構文定義ファイルのようなもの) を、ユーザー側で記述してもらうかたちになるのかしら…。設定UI以外にも、表示速度の低下とフットプリントの増大とのトレードオフになってしまうため、よい落としどころを探すのが大変そうです。
ELispやVimScriptで実装しているEmacsやVimのように、内蔵スクリプトに処理を任せるようにし構文解析もユーザーに投げてしまうのも手だと思います。SintaxHighlightで現状最も高速でモダンな実装は、VS CodeのテキストエディタエンジンであるMonaco Editorのものと思います。
https://github.com/microsoft/monaco-editorですが、Monaco EditorからSintaxHighlightとCustomizeを取り除いたマークダウンエディタのKotooriの高速さから鑑みるに、やはり相当重い処理なんだと思います。
https://github.com/kermount-dev/Kotoori-TextEditorMicrosoft自身、lshというRustによるSintaxHighlightをeditで再実装しています。
高速化と軽量化のためか、構文ルールを仮想マシンのアセンブラで記述してコンパイルする形式のようです。
https://github.com/microsoft/edit/tree/main/crates/lsh| enaka | 返信 -
詳しい情報ありがとうございます。
こうしていろいろ教えていただくと、構文解析を本格的に実装するのは、思っていた以上に奥が深そうですね。機能を充実させようとすると、どうしても処理速度やメモリ使用量とのバランスを考える必要がありそうです😅
> ELispやVimScriptで実装しているEmacsやVimのように、内蔵スクリプトに処理を任せるようにし構文解析もユーザーに投げてしまうのも手だと思います。
この方向は個人的には結構面白いと思っています。
開発者側の都合はいったん置いといて、ユーザー側の視点だけで考えると、Emacs や Vim のようにユーザーがスクリプトで機能を拡張できる仕組みは、Mery のマクロ機能とも相性が良さそうです。
たとえば、色分け用の API だけ用意して、「どこをどう解析するかはユーザーが自由に実装する」という方式ですね。
ただ、Mery の利用状況を考えると、そこまで自由度の高い仕組みを必要とするケースがどのくらいあるのか、というところは少し悩ましいところです。
> SintaxHighlightで現状最も高速でモダンな実装は、VS CodeのテキストエディタエンジンであるMonaco Editorのものと思います。
VSCode の最近の実装については詳しく追えていないのですが、以前調べたときには、シンタックスハイライトに TextMate が採用していた TextMate grammar が使われていて、構文定義ファイルも共通のものが利用されていたと記憶しています。
TextMate 形式の構文定義は、さまざまな言語向けのものが公開されていたので、Mery でも対応できないかなと思ったことがあります。ライセンス周りがちょっと怖くて、そのときは諦めましたが😱
一方で、VSCode を実際に使っていると、シンタックスハイライトも常に一瞬で終わるわけではなく、数百キロバイト程度の少し大きめのテキストでは、色分けが少し遅れて反映されることもあります。
もちろん、VSCode が重いという話ではなく、きちんとした構文解析をリアルタイムで行おうとすると、それなりの処理コストがかかるんだな、という印象です。
> ですが、Monaco EditorからSintaxHighlightとCustomizeを取り除いたマークダウンエディタのKotooriの高速さから鑑みるに、やはり相当重い処理なんだと思います。
Kotoori さんは興味深かったです。実際にインストールして試してみたところ、Monaco Editor ベースとは思えないくらい軽快ですね。
アウトラインや Markdown プレビューもあって、Mery の Markdown プラグインでやりたかったことが、かなり実現されているように感じました。
一方で、シンタックスハイライトを完全に取り除いているので、Markdown の見出しやコードブロックなどまで色分けされないのは、個人的にはちょっと寂しいところです。
そう考えると、Mery はその中間くらいのところで、現在の正規表現ベースの「なんちゃって」な色分けを維持するくらいが、バランスとしてはちょうど良いのかもしれません。
> Microsoft自身、lshというRustによるSintaxHighlightをeditで再実装しています。
> 高速化と軽量化のためか、構文ルールを仮想マシンのアセンブラで記述してコンパイルする形式のようです。おお…。これはかなり面白いですね。
正規表現エンジンの高速化などにも通じるような、実行時の処理をできるだけ単純化する方向の設計に見えます。構文ルールをコンパイルして専用の VM で実行するというのも、かなり割り切ったアプローチですね。
Mery の場合は、ここまで大規模な仕組みにしてしまうと、今度は実装や保守のコストが大きくなってしまうので、どこまでやるかは悩ましいところです。
というか、そもそも VM の命令セットまで自作できる気がしませんが😭
今回いろいろ教えていただいて、あらためて考えてみると、一周回って、Mery は現状の「なんちゃって」構文解析くらいがちょうど良いのかもしれないな、と思えてきました。
Mery はできるだけ軽快に使えることを重視しているので、より高度な構文解析が必要な場合は、VSCode などの専門的なエディターを使っていただく、という住み分けでも良いのかなと思います。
いずれにしても、lsh のようなアプローチはかなり参考になりました。
| Kuro | 返信
