Re: How to add pseudo vector types

[Yuan Fu]

> 
>>>> 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