Question
Peter Steiwer · 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.

0
0 1,109
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.

Another possible issue is that it comes from the Language Server, you may temporarily disable that extension if it's installed and active to see if it's changed (reload is required). And if the issue disappears I would suggest installing the latest beta version of Language Server. And fill the issue in the repo, if it's still happens.

I looked into these suggestions, but I still can't make it work. I see that when I am editing a file and I hover over the name on the tab at the top, it says "C:\Users\....\PivotSubscriptions\Subscription.cls". After using "Go To Definition", the new class opens with the path of "/PivotSubscriptions/EventLog.cls"

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.

When using 1.1.6 and 1.0.11, I am still getting a read only copy when I use Go to Definition. Are there any settings that need to be configured in a specific way?

Do you have the file exported to your local file system already? If not, then you'll have to set the serverSideEditing setting to true for the server copy that gets opened to be editable.

Yes, the second class is in the same project as the first and both exist locally on the file system

This now works after modifying my objectscript.export "folder" setting. It was previously "src" and is now "".

I still get the read only mode, even after setting the "objectscript.export" "folder" setting to null. What might I be missing?

@Michael Hampton 
I need more info about your exact setup to answer your question. What were your export settings previously? What folder within your workspace are your InterSystems files in? Are you sure that the file that contains the definition has a 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.

I didn't do the export, the repository was setup by our operations guys, so I don't know about it. I have those 3 settings as you describe but it still opens in read only mode.

Which folder do you have open as the root of your workspace?

That's the problem. The folder setting is relative to your workspace root. Since you have repos open, you want it to be "PATS\Server\Namespaces\AXIS".

That works! Thanks!

It was not clear to me the Folder setting was supposed to be relative. 

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