Closed kape1395 closed 9 months ago
@lemmy, what do you think of this plan:
I have to solve this for the TLAPS integration, because it will fail if some non-TLAPS-stdlib modules are used in a spec. Also, I have to use these paths if I want to integrate the SANY parser in the TLAPS LSP server for better error messages.
Sounds good to me assuming you are proposing to let the extension be the "facilitator of paths" between the various tools. How the tools make use of the path information is then up to the tool. For example, TLAPS adds its path information to the extension, and TLC is given this information when it launches.
What are the precedence rules WRT a tool's default lookup path and the extension's configuration property?
What are the precedence rules WRT a tool's default lookup path and the extension's configuration property?
I think the tool should prioritize its internal library (e.g., the TLC prioritizes the modules contained in tlatools.jar). Other paths are passed as additional search paths. Hopefully, that will not be a problem when some TLAPS modules are moved to the community modules repo.
This might require tool changes as, IIRC, a library path that is passed to TLC takes precedence over TLC's internal library path.
The TLAPS LSP server should support path sharing both ways:
Maybe related to: