openHAB VS Code Extension 0.4.1-beta

I am bit confused. I have tried to reproduce this problem but I don’t see these commands in my context menu for items or sitemap files. Also, I can’t see definitions for these commands in the extension definition file.

What exactly should this do anyway? If you’re right-clicking on the item in the items file or sitemap, aren’t you already looking at the item or sitemap definition?

BTW, there are some real issues with path mapping between the client where VS Code runs and the server where openHAB/LSP runs. I tried to fix one of them here, but there are still issues.

Yes, I tried it there. This is how the menu looks in my installation:


I have seen those two commands in editors for Typescript and Go but never in the openHAB editors.

Maybe these commands were provided by another extension.

If you don’t know what it’s supposed to do, then why are you clicking on it? :wink:

Reminds me of the old saying “Patient: Doctor, it hurts when I do that. Doctor: Then, don’t do that”. LOL

Can you check your key bindings definition, e.g. the definition for F12. In my installation it looks like this:

{ "key": "f12",                   "command": "editor.action.goToDeclaration",
                                     "when": "editorHasDefinitionProvider && editorTextFocus && !isInEmbeddedEditor" },

Maybe it’s different from the standard.

any selection of the first 4 options cause the error
the first 2 options produce the error and close the file
the second 2 options leave the file open but produce the same error and no results

As far as I understand the extension’s code these 4 options should not be visible when editing .items or .sitemap files because there are no definitions for these options.

I think functions like “Find/List all References” would also be interesting for the openHAB extension, e.g. to find references to items in sitemaps.

1 Like

Uninstalled all, wiped clean all VSC related settings…
Installed clean again… can’t reproduce it (right click menu doesn’t show these first options anymore)

forget about it… i don’t know what the heck was wrong… I really had no customizations done to VSC in the past.
Only 2 extensions on top of OH (Debugger for Chrome and Powershell)

Now it’s getting interesting: I have created a fresh VSCode installation on a Ubuntu VM machine and now I can see this menu items (with version 0.4.0 …).

It seems that these options have to do with the LSP. If LSP is disabled the options are not visible but if I activate the LSP then these options will appear not immediately but some time later. It seems that VSCode activates these options automatically as soon as it gets a certain value back from the LSP server.

somehow the Linux path is visible to VSC and I can’t figure out how/where to change this…

I always see the share that I am using. Which openHAB version are you using?

OH2.4.0.S1454
looks like you found something
ehm… with all settings clear I don’t see the menus under 0.4.1-b

the settings that I removed during the cleanup operation are:

{
    "openhab.username": "",
    "openhab.port": 8081,
    "openhab.password": "",
    "openhab.host": "homer",
    "openhab.lspEnabled": true,
    "openhab.useRestApi": true,
    "openhab.paperPath": "paperui",
    "openhab.restCompletions": true,
    "openhab.sitemapPreviewUI": "basicui"
}

I will try to put them back now

yup… confirmed.
with the minimum settings:

{
    "openhab.host": "homer",
    "openhab.lspEnabled": true,
}

the bogus menu options re-appear.

Yes that’s it :-). But it only happens if the LSP really can parse the file. If it can’t get it because of the share definitions (see https://github.com/eclipse/smarthome/issues/6611) the menu options don’t appear (that’s why I was not able to reproduce it in my first tries).

We should disable these function if there is no working implemention. Will try to figure out whether we can do it in the extension or whether the LSP itself must do it.

1 Like

you are correct.
Even on 0.4.0 these menu options appear
The difference in my 2 screenshots here is that the first one had no settings applied on settings.json
Since the default is: "openhab.lspEnabled": true
the setting that is affecting this is the "openhab.host": "homer" (without this, my local VSC on windows cannot connect to the remote Linux machine running OH2 and to the default LSP port)

edit

edit

The mapping happens here. It’s passed to the client in the JSON.

1 Like

edit

Based on my rather limited understanding (LSP is complex and not well documented), it may not work the way you want.

1 Like

It seems that the discussion is getting a bit off-topic :-). A new thread would be better …

I have created an issue for this problem: https://github.com/eclipse/smarthome/issues/6654 . The XTEXT-based LSP server sets nearly all LSP capabilities to “enabled” even if they are not implemented. We probably would have to override the server implementation and set only the currently supported capabilities to “true”.

1 Like

Hi all,

It seems that the extension works basically, which was the main point i wanted to check before i will push my first release to the marketplace.

I will add the simple mode check for the “Show in Paper UI”-Command and then update the marketplace version.

LSP improvements are already under work and we will have a solution for the topic that was discussed her too in the nearer future hopefully.

2 Likes

Confirmed!

1 Like