when two files with dependencies A -> B are open, B is changed, re-link all files inbetween

[kohlhase]

This is a often-occurring problem I am looking at an error in A, then see, that it depends on B which has the actual error, then I correct B, and I directly want to see the consequences in A. So far, I have to manually save all files between (in order from B to A) to get this.

[ghost]

my view on this is as follows, please correct me if i am wrong: all dependencies between the sources are currently handled by rustex and are unknown on scala side. since rustex has no state across multiple compilations, itself should not address this problem imo. in order to build a reliable solution to your problem, rustex could return more of its knowledge about the compiled sources back to scala which in return could handle such cases within the lsp server. the question is, what valuable information do we have on rustex side that are easily serializable.

[Jazzpirate]

all dependencies between the sources are currently handled by rustex and are unknown on scala side.

That is not true - the dependencies that matter to the IDE are exactly those handled by the linter (symdecl, importmodule etc), so the information is in scala.

since rustex has no state across multiple compilations, itself should not address this problem imo.

That is also not entirely true - when used via the JNI, rustex allows for keeping state across runt. That's why recompiling the same file twice to HTML in the IDE is significantly faster the second time around than the first time, because rustex remembers all the dependencies ;)

[ghost]

That is not true - the dependencies that matter to the IDE are exactly those handled by the linter (symdecl, importmodule etc), so the information is in scala.

is that also the case for error states? i mean i know that there is information on scala side, but we are talking about edge cases here...

That is also not entirely true - when used via the JNI, rustex allows for keeping state across runt. That's why recompiling the same file twice to HTML in the IDE is significantly faster the second time around than the first time, because rustex remembers all the dependencies ;)

how would that work? i thought the reason here is that there is state saved in some rustex/latex in-between compiled helper files.

[Jazzpirate]

is that also the case for error states? i mean i know that there is information on scala side, but we are talking about edge cases here...

It is true for the errors generated by the linter - which, ideally, should be all of them. But the errors that Michael is talking about are the ones generated by the linter.

how would that work? i thought the reason here is that there is state saved in some rustex/latex in-between compiled helper files.

rustexbridge copies a list of macro definitions after each run and adds them to the background state, a copy of which is used for every subsequent run. For sTeX, it's all macros that start with "c_stex_module", which preserves exactly all modules :)