openHAB VS Code Extension 0.4.1-beta

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

0.4.1 is in the marketplace already (simple mode check included)

It generates a warning message and prevents vscode from opening the browser if simple mode is activated and the user tries to open an item.

For things it opens the browser anyway.

1 Like

Thank you very much for your work! I just tested it but I have a problem when editing .rules-files. I always get a queer error message like this:

Regardless which .rules-file I open I get this message with thename of the .rules-file.

I am running VSCode on Windows as well as my OH installation (OH 2.4 Snapshot 1407).

Hey @vossivossi,

Does the error only appear or do you have “real problems” in your environment too?
I am really not into that lsp stuff currently and we are refactoring the whole system anyway, so i cant tell you much about it.

If there is just the “duplicate file” error without affecting your system, i would like to leave it for now and see if we can already solve that with the upcoming new implementation.

BR
Jerome

I have seen this message before but this happened when I had two files with nearly similar file names in the rules folder (xxx.1.rules and xxx.rules).
I also can remember that I saw this message one time in my Windows environment
As far as I can see the message comes directly from the LSP. So I don’t think that it is caused by the extension.

Well, I am not sure if this is related to the duplicate file error message but it is also not possible in rules-files to click on a problem in order to get the line of code with the problem. If I click on a problem then I get the next error message that the file cannot be found (although it is open in this very moment and I clicked on a problem message within that file). And with the next mouse click VSCode closes the open rules-File without warning and I am not able to edit it:

So it is not really possible to detect a problem, click on it and edit the problem code. The file will be closed before you can correct it. That is not really expected system behaviour.
However the other functions have improved significantly and I could live with the workaround to not click on problems in the near future…

Yeah, there are many open topics about code validation, syntax checking and code completion currently.
That’s exactly the reason why we decided to give a completely new implementation a try.

This is a really fresh topic and so its under big changes currently but hopefully this will bring us a stable and expandable solution for the future.

Another workaround would be to simply disable the current code checking with the openhab.lspEnabled setting.
Since you are facing problems anyway, maybe it doesn’t hurt to disable it completely for now.