Re: Reliable after-change-functions (via: Using incremental parsing in Emacs)

[조성빈]

> 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 +0300
> >
> > > If 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/222
>
> Thanks.  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).