语法突出显示：Eclipse如何做得如此之快？ [英] Syntax Highlighting: How Does Eclipse Do It So Fast?
问题描述
所以我已经开发了一个用于Android的Java语法荧光笔，它的工作正常，但是问题是大文件可能很慢。想知道Eclipse和Gedit（Ubuntu）等源代码编辑器如何突出显示您刚才写的内容。例如，如果您在编写HTML标签时输入结尾大于符号，则会立即突出显示该标记。
即使是大文件，如何快速？有没有一个特定的方式去做，或者他们只是执行语法突出显示你所在的行？
谢谢，
Alex
我不能说Gedit，但在Eclipse中，我们欺骗： - ）
如果你看起来非常仔细，你可以看到Java中的结构化语言的语法着色是两阶段的过程。
首先，演示调和器运行做非常基本的语法着色。这是在编辑器文档的更改中立即触发的，预计会非常快。它实际上不是基于语法的着色，而是实际上是基于词法的着色。所以重点放在诸如字符串，关键字，单词，数字，评论等的标记上 - 所有可以基于简单字符表或类似功能轻松识别的令牌。因此，即使最终颜色不同，类名，变量名或静态方法名称也没有区别。
对于许多语言，这是完成的唯一着色。
接下来，运行语法协调器来构建文档的抽象语法树（AST），或者尽可能靠近语法错误或语义错误。这是由定时器触发的，对于某些语言，尝试只是进行AST的部分更新（不容易）。然后使用完成的AST来更新轮廓视图，然后根据附加信息进行附加的语法着色。静态方法名称。 （AST通常用于许多其他事情，例如悬停信息，折叠，超链接等。
对于初始表示协调器和基于语法的调和器，一些相当精细的逻辑决定了必须解析的文档的一个区域的大小。对于演示文稿协调器，决策可以基于任何现有的着色，而对于基于语法的着色，运行中的单独的损坏/修复阶段来确定该区域。
一些极端的例子总是使事情变得复杂的是在添加或删除块注释时。
a = b / * c + 1 / *记住偏移量* /;
如果第一个斜线被删除或添加，则表示调和器必须处理一个比可以天真预期的更大的区域...
I've developed a syntax highlighter in Java for Android and it's working well, but the problem is it can be slow with big files.
So I'm wondering how source code editors like Eclipse and Gedit (Ubuntu) highlight what you've just wrote so quickly. For example, if you enter the ending greater than symbol when writing a HTML tag, it highlights the tag instantly.
How is it so quick, even with big files? Is there a specific way they go about doing it or do they just perform the syntax highlighting for the line you're on?
Thanks, Alex
I cannot talk for Gedit, but in Eclipse, we cheat :-)
If you look very carefully, you can actually see that syntax coloring for structured languages like Java is a two-phase process.
First, a presentation reconciler is run to do very basic syntax coloring. This is done immediately triggered on changes in the document of the editor and is expected to be extremely fast. It is really not syntax-based coloring, but actually lexically-based coloring. So the focus is on tokens like strings, keywords, words, numbers, comments, etc - all tokens that can be recognized easily based on simple character tables or similar. Thus there are no difference between a class name, a variable name or a static method name, even though they may be colored different in the end. For many languages, this is the only coloring done.
Next, a syntax reconciler is run to build an abstract syntax tree (AST) for the document - or as near as you can get in the face of syntax errors or semantic errors. This is triggered by a timer and for some languages an attempt is made to just do a partial update of the AST (not easy). The completed AST is then used to update the outline view and then do additional syntax coloring based on the additional information - e.g. static method name. (The AST is often used for many other things, like hover information, folding, hyperlinking, etc.
Both for the initial presentation reconciler and the later syntax based reconciler, some rather elaborate logic determines just how big a region of the document that must be parsed. For the presentation reconciler the decision can be based on any existing coloring, whereas for the syntax based coloring a separate damage/repair phase in run to determine the size of the region.
Some extreme examples that always complicate matters are when block comments are added or removed
a = b /* c + 1 /* remember the offset! */;
If the first slash is removed or added, the presentation reconciler must process a larger area, than what can be naively expected...
这篇关于语法突出显示：Eclipse如何做得如此之快？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
