Question
· Apr 9, 2021

VSCode "Go To Definition" opens in Read Only mode

As the title says, when I use the "Go To Definition (F12)" option, it opens the definition in read only mode. Is there some way to either directly make the go to option editable or can i turn the read only version into an editable version? I end up needing to open the file directly and then manually going to the method definition myself.

Discussion (21)3
Log in or sign up to continue

The issue is probably in export settings, which used to find a real file for resources on server. You can check it by opening ObjectScript Explorer, when you dive to your classes/routines, it should show an icon next to the name, the same as in File Explorer. So, it's mean that it's linked correctly. If not. you have to look at "objectscript.export" settings, you may find some useful info about this here.

Sounds like you are using the client-side editing paradigm. As Dmitry says, unless you haven't installed Language Server it will be LS that initially handles your "Go to Definition" request. But I think LS then calls an API entrypoint named serverDocumentUriForUri in the main ObjectScript extension (OS) to find out where the target document should be fetched from. As the API name indicates, this returns a uri (a document reference) that always fetches code from the server. And since you are using the client-side editing paradigm the fetched code cannot be edited.

Please open an issue on the repo at https://github.com/intersystems-community/vscode-objectscript/issues where it can be tracked and managed better than in this DC post.

I think John is basically correct, but I don't see this as an issue.  When you are doing client-side editing, which is what I normally do, you need to export code to your project to edit it.  This is an action you need to perform as every definition you look at should not necessarily become part of your project.  When you choose to 'Go To Definition' the InterSystems extension looks to see if it's local and opens that if it is, local meaning client-side.  If not it opens it from the server which is always read-only when working in client-side editing.  To edit export it then open the local copy.

All files have local copies. I can open and edit them just fine, but using the "Go to Definition" always opens it in read only mode.

The folder setting was previously "src" I guess by default. I've tried null and various forms of the path for the "folder" setting.

Our Git repository is d:\Repos

The atelier setting is true

The path for an example class I have open is

d:\Repos\PATS\Server\Namespaces\AXIS\Axis\Pat\Display.cls

If I use F12 (Go to Definition) on the following I get the file in read only mode:

##class(Axis.Pat.Lib).PatKeyToPatNum(Pat)

Even though the file exists as:

d:\Repos\PATS\Server\Namespaces\AXIS\Axis\Pat\Lib.cls

That is, they are both in same directory.

It is unclear how much of the path should be in the "folder" setting.

Should I just call Support?

Did you export those files using the VS Code extension? The extension uses its export settings to determine where it will look for local copies. For example, if you have the AXIS folder open in VS Code you would need the following export settings to reflect the existing folder structure that you have: objectscript.export.folder setting equal to "", objectscript.export.atelier setting set to true, and objectscript.export.addCategory setting set to false.

Careful with the 'objectscript.export' folder setting.  This needs to match where, under the root of your VScode project, your source lives.  For example my settings are:

        "folder": "iris/image/iris_src/dev",
        "addCategory": true,

So under my VScode project folder I have the path indicated in Folder.  This is how my git repository is setup.  Now my 'addCategory' is also true.  Therefore under that /dev folder I have sub-folders for 'cls' and 'rtn'.  All my classes should be under the 'cls' folder and any routines are under 'rtn'.  There are other sub folder too for other elements, but you should get the idea.

To add to the puzzle there is also the setting "objectscript.export.atelier".  With this setting true the plug in expects each package and sub-package to be a separate directory.  So if I have a class Example.code.test what you will end up with is a path, given my setup above, under vs code that looks like this.

iris/image/iris_src/dev/cls/Example/code/test.cls

If the file whose definition you are trying to get to is not in the right place it will open it in read-only mode from the server when using Client-side editing