> On Nov 13, 2022, at 5:26 PM, Dmitry Gutov <dgutov@yandex.ru> wrote: > > On 14.11.2022 02:22, Yuan Fu wrote: >> So if we want the warning face to automatically disappear, we need to record >> these warning faces and remember to come back to refontify them later. We >> need to know when to refontify them, and know when to stop trying to >> refontify them (maybe the error isnât transient). For now I think itâs best >> to just not fontify the error nodes. > > I'm guessing the situation could be the reverse as well: after the user > typing some chars, the warning would need to be *added* rather than removed, > in some cases. Thatâs a good perspective. But from what I see I think itâs best not to fontify these âerrorsâ, at least for C and C++. Because a lot of things could be marked âerrorâ in a C file, like stuff around macros. And in extreme cases the whole file is marked âerrorâ, even though if we ignore the error everything is parsed fine. I guess tree-sitter isnât happy about some tiny thing in that file but never the less can parse everything correctly. I attached that file below. > Any chance tree-sitter gives you some info/callbacks to convey the earliest > node (closes to bob) which has changed after the most recent buffer > modification? So we'd refontify starting with its beginning position. Yes and no, I explained in more detail in another message.
subtree.h
Description: Binary data
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4