> On Nov 14, 2022, at 11:54 AM, Dmitry Gutov <dgutov@yandex.ru> wrote: > > On 14.11.2022 10:35, Yuan Fu wrote: >>> 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. > > Perhaps not in C/C++, but other langs could use them. > > Also (and here I'm really guessing, not sure what the limitations/benefits of > TS grammars are) there might be other nodes which could change due to the > user writing or deleting code on subsequent lines. Yes, this is common for comments and multi-line strings. And we can correctly handle them now, yay (see my other message.) > >>> 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. > > If you're referring to this grandparent message: > > > jit-lock doesnât know it needs to be refontified > > ...then I suppose it's a matter of letting it know somehow. I haven't read > the TS integration code yet, so I'm not sure at which level it integrates > with jit-lock. It plugs into font-lock, but it also secretly knows about jit-lock⦠We now can tell what parts of the buffer are affected/changed, and we set fontified to nil in those areas so redisplay will refontify them. > > But jit-lock-functions are allowed to fontify more than the passed in > boundaries, for example. Yuan
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