The LSP should show non-user defined files as read-only editors

[Coffee2Bits]

As we begin to implement LSP features such as go to references or go to definition, we need to be cognizant of the special case that occurs when we take users to the definition/reference of definitions that are sourced from non-user files such as the Core Spec and plugin-provided yaml files. These files that are outside the control of the user should still be incorporated in lookup results, but only as read-only files.

AC:

• [ ] When users are sent to non-user defined files via LSP features those files are presented as read-only

[cvchaparro]

I like where you're heading with this but I'm curious, how are we defining "non-user files" (other than the examples you provided)?

For example, if I'm working on Team A and I have some files that depend on models, etc from Team B, I would think those would qualify as "non-user files" (based on the name) but without packages, or some other way of determining "file ownership" how would we know to open Team B's file as read-only? Are we dictating that if a file is in the AaC python package, it's a "non-user file" and any other file is a "user file"?

[Coffee2Bits]

I like where you're heading with this but I'm curious, how are we defining "non-user files" (other than the examples you provided)?

For example, if I'm working on Team A and I have some files that depend on models, etc from Team B, I would think those would qualify as "non-user files" (based on the name) but without packages, or some other way of determining "file ownership" how would we know to open Team B's file as read-only? Are we dictating that if a file is in the AaC python package, it's a "non-user file" and any other file is a "user file"?

I'm using it to define any files that aren't on the filesystem in the project directory. So, any AaC files that are sourced from the core package, plugins, and eventually shared libraries would be considered a file that isn't defined by the user.

[cvchaparro]

If we approach it like this, I'd say we should have an option to allow users to re-open the file(s) as editable. This extra ability would allow someone to experiment with different designs, etc in a shared library that is being used but isn't directly controlled by them.

An example of this, in action, is our Python virtual environments - the code in those libraries is able to be modified and I've actually used this ability to work around bugs in libraries before (not in Python but in CL systems).

[Coffee2Bits]

That sounds like a separate, complex user feature since we would have to tell the active context lifecycle manager to:

1. Extract the contents of those contextual files to the filesystem
2. Source from those local filesystem AaC files instead of from the various registered providers

Which is doable, but I think that's a separate issue/user feature.