構文強調表示：Eclipseはどのように高速化するのですか？

Question

私はAndroid用Javaでシンタックスハイライターを開発しましたが、うまくいきましたが、問題は大きなファイルでは遅くなる可能性があることです。

EclipseとGedit（Ubuntu）のようなソースコードエディタが、あなたが書いたことをどのように素早く書いているのかが不思議です。たとえば、HTMLタグを書き込むときに、より大きい末尾の記号を入力すると、タグが即座に強調表示されます。

大きなファイルの場合でも、どのようにすばらしいのですか？彼らはそれをやり遂げるための具体的な方法があるのでしょうか、あるいはあなたが行っている行の構文強調表示を実行するだけですか？

おかげで、 アレックス

Answer 1

は私がGeditのために話をすることはできませんが、Eclipseで、我​​々はあなたが非常に注意深く見ると、Javaがあるように、あなたが実際に構造化された言語のためにその構文の色分けを見ることができます:-)

カンニング二相プロセス。

まず、非常に基本的な構文の色付けを行うためにプレゼンテーション調整が実行されます。これは、エディタの文書の変更に即座にトリガされ、非常に高速になると予想されます。実際にはの構文に基づいていませんが、実際にはにはベースの着色が使用されています。つまり、文字列、キーワード、単語、数字、コメントなどのトークンに焦点を当てます。単純な文字表などに基づいて簡単に認識できるすべてのトークンです。したがって、最終的に異なる色になっていても、クラス名、変数名、または静的メソッド名には違いはありません。 多くの言語で、これが唯一の色付けです。

次に、構文リコンシュータを実行して、ドキュメントの抽象構文ツリー（AST）を構築します。構文エラーや意味的なエラーが発生した場合には、できるだけ近くで構築します。これはタイマーによってトリガーされ、いくつかの言語ではにちょうど（部分的にはASTの部分的な更新）を試みます。完成したASTを使用してアウトラインビューを更新し、追加情報に基づいて追加の構文カラーリングを行います。静的メソッド名。 （ASTは、ホバー情報、折り畳み、ハイパーリンクなど、他の多くのものによく使用されます。

最初のプレゼンテーション調整と後の構文ベースの調整の両方について、どちらかといえば精巧なロジックによって、プレゼンテーションリコンサイルの場合は、既存の任意の色に基づいて決定することができますが、構文ベースの色付けでは、領域のサイズを決定するために別のダメージ/修復フェーズを実行して領域のサイズを決定します。ブロックコメントが追加または削除されるときは常に問題を複雑にします。

a = b /* c + 1 /* remember the offset! */; 

最初のスラッシュが削除または追加された場合、プレゼンテーション調整担当者は、純然たる予想以上に大きな領域を処理する必要があります。