私はAndroid用のJavaでシンタックスハイライトを開発しましたが、それはうまく機能していますが、問題は大きなファイルでは遅くなる可能性があることです。
ですから、EclipseやGedit（Ubuntu）のようなソースコードエディタが、あなたが今書いたものをどのようにすばやく強調するのか疑問に思います。たとえば、HTMLタグを作成するときに大なり記号の末尾を入力すると、タグが即座に強調表示されます。
大きなファイルであっても、どのように高速ですか？彼らがそれを行う特定の方法はありますか、それともあなたがいる行の構文の強調表示を実行するだけですか？
ありがとう、アレックス
Gedit について話すことはできませんが、Eclipse ではごまかしています :-)
注意深く見ると、Java のような構造化言語の構文カラーリングが 2 フェーズのプロセスであることが実際にわかります。
最初に、非常に基本的な構文の色分けを行うためにプレゼンテーション調整プログラムが実行されます。これは、エディターのドキュメントに変更が加えられるとすぐに実行され、非常に高速であることが期待されます。これは実際には構文ベースのカラーリングではなく、語彙ベースのカラーリングです。そのため、文字列、キーワード、単語、数字、コメントなどのトークンに焦点を当てています。すべてのトークンは、単純な文字テーブルなどに基づいて簡単に認識できます。したがって、クラス名、変数名、または静的メソッド名には、最終的に異なる色が付けられる場合でも、違いはありません。多くの言語では、これが唯一のカラーリングです。
次に、構文調整ツールが実行されて、ドキュメントの抽象構文ツリー (AST) が構築されます。構文エラーやセマンティック エラーが発生した場合は、可能な限り近い形で構築されます。これはタイマーによってトリガーされ、一部の言語では AST の部分的な更新のみを実行しようとします (簡単ではありません) 。次に、完成した AST を使用してアウトライン ビューを更新し、追加情報 (静的メソッド名など) に基づいて追加の構文の色分けを行います。(AST は、ホバー情報、折りたたみ、ハイパーリンクなど、他の多くのことによく使用されます。
最初のプレゼンテーション リコンサイラーとその後の構文ベースのリコンサイラーの両方で、かなり精巧なロジックによって、解析する必要があるドキュメントの領域の大きさが決定されます。プレゼンテーション調整プログラムの場合、決定は既存のカラーリングに基づくことができますが、構文ベースのカラーリングの場合、領域のサイズを決定するために別の損傷/修復フェーズが実行されます。
常に問題を複雑にする極端な例は、ブロック コメントが追加または削除された場合です。
a = b /* c + 1 /* remember the offset! */;
最初のスラッシュが削除または追加された場合、プレゼンテーション調整プログラムは単純に予想できるよりも大きな領域を処理する必要があります...