コードが強調表示されたエディター。 問題と解決策

Habrのオーディエンスのほとんどは、定期的にコードを書きます。 テキストエディタまたはIDEで。 また、ウィンドウやメニューの数に関係なく、エディターの中心はウィジェットであり、コードを編集して強調表示します。

1年以上前にHabréで、QScintillaコンポーネント（ 1、2、3 ）についての名前空間からの一連の記事と、その批判を含む私の記事がありました 。 結果は控えめな表現でした。 すべてが悪いことは明らかですが、何をすべきかは明確ではありません。

Qutepartという自転車コンポーネントを作成しました。このサイクルには続編があります。
この記事では、私のプロジェクトで構文の強調表示がどのように配置されるか、どのような問題が発生し、どのように解決されたかについて説明します。 これはアプローチに関するものであり、特定のGUIツールキットの仕様に関するものではありません。 テキストエディタの「内部」を見ることに興味がある場合は、catにようこそ。

これが基本的な科学記事ではないことをすぐに控えてください。 これは私の経験です。 代替アプローチとソリューションに関するコメントを読むのは非常に興味深いでしょう。

やる気

私はvimとemacsの精神でテキストエディタを作っています。 ユニバーサル、クロスプラットフォーム、拡張可能、経験豊富なユーザー向け。 しかし、 PyQtのやや直感的で最新のGUIを使用します。 そのためには、コードエディターが必要です。
QScintillaとkatepartの2つのオプションしかありませんでした。
私はもともとQScintillaを使用していましたが 、 ここにリストされている欠点のために、それを放棄することにしました。
katepartは非常に優れていますが、KDEライブラリに依存するものに満足できません。 そしてそれらを依存関係に置くことは、特にWindowsとMacOSにとってはあまり便利ではありません。

コード解析

私のプロジェクトは特定のテクノロジーに焦点を合わせていません。多くの言語を強調したいと思います。 自分をマスターできる以上のもの。 したがって、katepartの既存の構文定義データベースを使用することが決定されました。

katepartでサポートされているプログラミング言語ごとに、 ハイライト定義があります-構文とハイライトの説明を含むXMLファイルです。
ハイライト定義は、ステートマシンのようなものを記述します。 マシンは状態を変更しながら、テキストを連続的に解析します-「コンテキスト」。 各コンテキストには、別のコンテキストに移動する必要がある一連のルールがあります。 オートマトンは、現在の状態になった状態を記憶し、以前のコンテキスト（コンテキストスタック）に戻ることができます。
例：C ++。 コンテキストでは、 コードにルールがあります： 文字「met-コンテキストに移動」文字列「 。コンテキスト」文字列「文字を赤で強調表示し、ルールを保持： 文字が一致」-前のコンテキストに戻ります 。
コンテキストごとに、テキストを強調表示するスタイルが定義されます。

このシステムは非常に便利で多用途です。 ファイル形式はよく文書化されています。 これがおそらく、katepartが約200の言語と形式を強調している理由です。
私の意見では、唯一の欠点は、ほとんどの場合、構文定義ベースのコードを解析するインタープリターのパフォーマンスが特定のプログラミング言語のパーサーよりも低下することです。

最適化

構文の強調表示を書いたとき、私の喜びは際限がありませんでした。 すべてが機能し、すべてが美しい。 katepartコレクションの異なる言語の59個のファイルはすべて正しく見え、すぐに開きます。 やった！ Pythonは遅い言語だと誰が言いますか？！
そして、大きなファイルを開こうとしました。 本当に大きい。 そして突然 、私のパーサーはそれほど速くないことが判明しました。 最適化を行う必要がありました。

プロファイラーを使用して数時間バックライトを数回加速しました。 しかし、それでも遅すぎることが判明しました。 そして、最適化のためのスペースはほとんど使い果たされました。 ひどく混乱するコードのために、パーサーを数十パーセント高速化することは可能でしたが、そのような天気の最適化はそうではありません。

私はCでモジュールを書く方法を学び始めました。それはまったく難しくないことが判明しました。Pythonは拡張機能に非常に優しいです。
パーサーの作成中に問題が発生しました。Cには正規表現がありません。 そして、私は本当に依存関係を結びたくありませんでした。 この問題は、C-Pythonの相互作用が2つの方向で機能するという事実により解決されました。 Pythonは解析のためにCを呼び出し、Pythonの関数はCからジャークして正規表現をテストします。

拡張機能を使用してパーサーのテストを開始したとき、パフォーマンスはPythonバージョンとそれほど変わらないことがわかりました。 プロファイラーを再度取り、問題を探しに行きました。
パーサーがPythonを呼び出して正規表現をチェックする時間の90％が判明しました。 さて、ハックは失敗しました。 外部ライブラリを使用する必要がありました。 そのため、コンポーネントには単一の依存関係、つまりC pcreの正規表現処理ライブラリがありました。 これにより、パフォーマンスはかなり許容できることが判明しました（数値は低くなります）。

その結果、Pythonを使用することの適切さに失望することはありませんでした。 Cのパーサーは、コンポーネントのコードベースの約1/3です。 労力の面では、このようなハイブリッドオプションはC ++のソリューションよりも簡単であることが判明したと思います。

非同期バックライト

ほとんどのテキストファイルのサイズは非常に小さくなっています。 しかし、ソースを編集しなければならないこともありました。この場合、30万行以上になります。 パーサー開発者がどれほどクールであっても、言語がどれほど速くても、そのようなファイルを最後まで解析するのに、ユーザーが待つことに同意するよりも時間がかかります。

katepartは、GUIストリームのコードを強調表示します。 そして、彼はそれを怠ziに行います-それはあなたが画面上に描くのに必要なだけ強調表示されます。 ファイルが最初に開かれている場合、このアプローチは非常にうまく機能します。 ただし、大きなファイルの最後にジャンプすると、GUIがフリーズします。 このアプローチは私には向いていませんでした。


vimとemacsは、必要に応じて大きなファイルの終わりを描画し、中央からテキストを解析します。 この方法は、強調表示時に長時間GUIをブロックしないという点で優れています。 しかし、それほど単純ではありません。 プログラミング言語は順番に解析されます。 たとえば、複数行コメントの終了文字を正しく処理するには、コメントが前の行で始まったかどうかを知る必要があります。 場合によっては、中間からの解析が不正確な照明を生成することがわかります（vimのスクリーンショットのように）。

現在、クロック周波数の増加がコアの数の増加に変わったとき、コアによる分離による計算の最適化がしばしば重要になります。 ただし、ここで問題が発生します。これは、ファイルを順番に解析する必要があるためだけではありません。
ユーザーは常にコードを編集しています。 GUIスレッドはキーストロークを処理し、ドキュメントを変更します。 ドキュメントが解析され、ストリームで強調表示されている場合、変更を同期する必要があります。 Qtツールキットは常にマルチスレッド指向ではありません。ドキュメントへのアクセスを確実に同期する方法を見つけていません。 フローを拒否する必要がありました。

実験の結果、次の解決策が得られました。ファイルが解析され、タイマーによってGUIストリームで強調表示されます。 タイマーは20ミリ秒実行され、その後、ユーザーアクションを処理するためにメインループに制御を返し、再び呼び出されます...ユーザーが巨大なファイルを開いてすぐに最後にジャンプした場合-ファイルは表示されますが、強調表示されません。
コードは編集でき、ハイライトは少し後に表示されます。

増分バックライト

ユーザーがコードを編集するとき、最初からではなく、編集中の場所からテキストを再度強調表示する必要があります。 そして、原則として、1つまたは複数の行が変更されます。

解析中に、パーサーのステータスを含むメタデータブロックがファイルの各行に添付されます。 テキストが変更されている場合、メタデータを使用して特定の行から解析を開始します。
増分解析は、新しい解析後にメタデータが変更されていない行が見つかるまで続きます。

性能比較

バックライトの性能の比較はありがたいです。 ハードウェア、ソフトウェアのバージョン、言語、特定のファイルの内容、ムーンフェイズなど、多くの要因に本当に依存しています。
しかし、それなしでは、記事は完成しません。 したがって、セクションを追加する必要があります。

私が興味のあるいくつかのエディターで大きなC ++ファイル（364121行）を開き、この表で観察結果を収集しました。

コンポーネントまたはエディター	ファイル全体をハイライトする時間	ブロックGUI	バックライトの問題
Qutepart	44秒	決して	ファイルを3秒開く
ケイトパート	6分後に殺された	表示する必要があるだけ強調表示するまで
QScintilla	3秒	決して	編集中は遅くなります
シンチラ	3秒	決して	編集中は遅くなります
崇高なテキスト	23秒	編集時、変更されたすべてのバックライトを更新するまで
黙想する	8秒	決して	編集中は遅くなります
Qtクリエーター	20秒	編集中、変更されたすべてのバックライトが更新されるまでハングします
忍者IDE	14秒	開くと	最初の51行のみを強調表示しました。 編集時にひどく遅い。
ヴィム	すぐに	決して	途中からファイルを解析し、場合によっては誤った結果を示します。
emacs	すぐに	決して	途中からファイルを解析し、場合によっては誤った結果を示します。 巻き戻すと、約1分間ハングします。

テーブルの詳細バージョン
ご覧のとおり、Qutepartは最もゆっくりとテキストを強調表示します。 これは、インタープリター言語、Python-Qtバンドル、およびXML形式のインタープリター構文定義を使用するため、論理的です。
一方、高レベルの言語とテクノロジーを使用すると、GUIをブロックしたりアーティファクトを表示したりせずに、多くの言語を強調表示できます。
ほとんどの場合、実際のファイルを使用する場合、ファイルは既にハイライト表示されており、ユーザーを編集する場合、バックライトの更新方法は表示されません。 したがって、現状は私に合っており、私はさらなる最適化を拒否しました。

そして何が起こった

Qutepartコードを編集するためのコンポーネントと、それに基づいたテキストエディターEnkiを入手しました。
PyQtとpcreに依存します。 Cで拡張モジュールのアセンブリが必要です。小さなファイルの場合、拡張機能なしで、pcreなしで実行できます。
構文定義ファイルとコードアライメントアルゴリズムは、katepartから借用しました。
katepartと同様に、プロジェクトはLGPLで利用できます。

今日、QutepartとEnkiの最初のバージョンをリリースしました。これは、現在のバージョンがQScintillaのバージョンよりも優れていると判断したためです。 まだ多くの機能はありません。 TODOリストは素晴らしいです。 ユーザーの要望により定期的に補充されますが、機能が追加されたために少なくなりました。

Habrコミュニティからのレビューに喜んでいます！