Re: How to add pseudo vector types

[Yuan Fu <casouri@gmail.com>]

> 
>>>> unless the narrowing is for multi-major-mode.
>>> 
>>> And what would you do in that case, if you allow TS to look beyond the
>>> restriction?
>> 
>> In the multi-major-mode case, there is a separate parser for each
>> language, and each sub-mode region in the text would get its own parser
>> tree (ie, it acts like a separate file), and that parser tree is only
>> told about changes to those regions. So the parser will never try to
>> look outside the region; it doesn't need to know about narrowing.
> 
> Once again, we are talking about the function used by TS to read
> buffer text.  Not about the parser or its caller.  Low-level code,
> which knows nothing about the context, should never look beyond the
> restriction.

It doesn’t harm for tree-sitter to see the rest of the buffer, it doesn’t modify anything, all it does it reading the text. OTOH, restricting tree-sitter to the bounds of narrows adds complexity for no benefit (as far as I can see). Maybe narrowing is the context that low level code should ignore, or at least tree-sitter should ignore. The only benefit that I can think of is “we firmly adhere to the ‘contract’ that no one can look beyond the narrowed region”, but is it a good contract? Is there really a contract in the first place? IMO, narrowing acts like masking tapes over the rest of the buffer, so that user edits like re-replace wouldn’t spill out. Demanding everything in Emacs to not have access to the rest of the buffer is dogmatic (in the sense that it is too rigid and is simply following the doctrine blindly). 

And about language definitions and font-locking, I just realized that tree-sitter language definitions provides highlighting patterns, and we only need to minimally modify them to use them for Emacs, so there aren’t much manual effort involved.

Also, anyone have thoughts on how should tree-sitter intergrate with font-lock beyond the current simple interface?

Yuan