This is a bit fluffy, here is an example. In the demo UI all text changes update the state of Yode. Code gets parsed which takes time, for example. Integrated into an editor there are more "states", I think. A user can edit a file as normal without any function buffers open associated to that file. If this is the case, Yode should not update its state, till it is needed. Probably it exists even a dedicated "Yode Mode".
Also some kind of subscription could be done like:
when user issues an action like "open function under cursor" Yode starts tracking the file
when last function buffer is closed, Yode stops tracking the file
for one time actions Yode could parse the file once, output things and don't track the file at all. E.g. "show me the function hierarchy of that file"
Yode has already the "is buffer visible" logic. This can be probably expanded, like checking for real visibility like "does the user really sees this". Also some edits like vim has this "hidden buffer" thing.
This ticket is more of a reminder to look into this kind of performance enhancement when there is a workflow we can align it to.
This is a bit fluffy, here is an example. In the demo UI all text changes update the state of Yode. Code gets parsed which takes time, for example. Integrated into an editor there are more "states", I think. A user can edit a file as normal without any function buffers open associated to that file. If this is the case, Yode should not update its state, till it is needed. Probably it exists even a dedicated "Yode Mode".
Also some kind of subscription could be done like:
Yode has already the "is buffer visible" logic. This can be probably expanded, like checking for real visibility like "does the user really sees this". Also some edits like vim has this "hidden buffer" thing.
This ticket is more of a reminder to look into this kind of performance enhancement when there is a workflow we can align it to.