|
From: | 조성빈 |
Subject: | Re: Reliable after-change-functions (via: Using incremental parsing in Emacs) |
Date: | Fri, 3 Apr 2020 03:03:32 +0900 |
2020. 4. 2. 오후 11:10, Eli Zaretskii <address@hidden> 작성: Cc: address@hidden, address@hidden, address@hidden, address@hidden, address@hidden From: Dmitry Gutov <address@hidden> Date: Thu, 2 Apr 2020 00:21:36 +0300If by TreeSitter you mean the parser (not the Emacs package which interfaces it), then what I proposed is not against their design, AFAIU. They provide an API through which we can let the parser access the buffer text directly, and they explicitly say that the parser is tolerant to invalid/incomplete syntax trees. And I don't see how it could be any different, since when you start writing code, it takes quite some time before it becomes syntactically complete and valid.That makes sense, at least in theory. But I'd rather not break the usage assumptions of the authors of this library right away.From what I could glean by reading the documentation, the above is not necessarily against the assumptions of the tree-sitter developers. I saw nothing that would indicate the initial full parse is a must. That such full parse is unnecessary is what I would expect, because of the use case that I start writing a source file from scratch.
The situation of a new user creating a new buffer is very different from parsing code with only a peephole, because users don’t generally expect unfinished code to be exactly highlighted, while users do expect finished code to have exact highlighting. Maybe it’s just because I got lost through a lot of emails, and Mail.app doesn't really thread these emails properly, but I can’t understand the resistance of the front-up parsing. The current shipping CC-Mode is parsing most of the code front-up, and clearly tree sitter will be faster than that. AFAIU parsing code only by only looking through a peephole is super hard except for some languages that are designed for peephole processing - and that makes it only hard, not super hard.
And we'll likely want to adopt existing addons which use the result of the parse, which likely depend on the same assumptions.Those other addons must also support the "write from scratch" use case, right? Then they should also support passing only part of the buffer, since it could be that this is all I have in the buffer right now.Anyway, here's a (short) discussion on the topic of large files: https://github.com/tree-sitter/tree-sitter/issues/222Thanks. This was long ago, though, so I'm not sure what became of that (and Stefan's comment didn't yet get any responses to indicate that this is a solved problem).
[Prev in Thread] | Current Thread | [Next in Thread] |