Specify read-only locations

[kjeremy]

It would be nice to provide a hint that locations (Location, LocationLink) could be read-only. For instance: if performing a find usages or a go to definition on a symbol that ends up in a third party library (crates, npm packages, disassembled .NET DLLs) you may not want that source to be editable at that location and could open up a document in read-only mode.

rust-lang/rust-analyzer#6623

[dbaeumer]

@kjeremy I looked into this (and the PR) and I am not sure if this is the right approach. Whether something can / should be read only depends on the file system. I am not sure if we should let servers decide on this.

[bjorn3]

If a goto reference goes to the source of a third party library, the file should be opened as read-only, even if the file system allows it. The build system may depend on them not changing even if the filesystem permissions allow it. For example cargo won't rebuild anything when the source of dependencies from crates.io are changed because it expects them to be immutable. Cargo doesn't set the filesystem permissions to readonly. Doing so would probably be a breaking change as some people incorrectly generate files into the source directory. Even if the build system can handle it perfectly fine, it is unlikely that a user meant to modify the source of a third party library. I have on multiple occasions accidentally modified the source of a third party library. AFAIK in all cases I did notice it in time, but it is possible that I didn't notice it once and that this modification will cause issues in the future. In addition it is not always possible to mark a file as read-only. For example in case of a vendored copy of a library inside a git repo. Git will automatically reset the file permissions to user writable every time it needs to change it due to switching between commits.

[rchl]

I don't agree that the server should restrict me from editing any file.

Also, depending on how you open the file, you could edit it or not, which could be viewed as inconsistent.

I, for example, do sometimes modify stuff in node_modules to test things quickly or insert a log and would not want that to be more difficult.

But if anything like that is to be added, a "readonly" flag seems too specific. The server could instead notify the client about given file being an "internal library" or similar, and it would be up to editor to interpret that how it wants (maybe differently depending on the server also).

[bjorn3]

But if anything like that is to be added, a "readonly" flag seems too specific. The server could instead notify the client about given file being an "internal library" or similar, and it would be up to editor to interpret that how it wants (maybe differently depending on the server also).

That would be an option. I guess the editor could then also show an option to make the file writable if it choses to open it readonly by default.