Just download the build artifact as shown in the screenshot below.
Happy testing and feedback welcome as usual.
If it runs well, i would like to push it to the marketplace by the end of this or the beginning of next week.
One question aside to all who have downloaded already:
I have fixed a bug with syntax highlighting.
Reference:
Would be nice if you check for flaws in syntax highlighting.
-> .persist-Files and .things-Files have a strange look now through this, but i was willed to accept that for now.
persist and things files have quite a different syntax compared to items/rules/sitemaps so they donāt fit into this really well anyway.
Long story short:
If you recognize strange highlighting in those two file types call it āon purposeā.
If you finde some strange highlighting in items/rules/sitemap files, please give me feedback here.
Very Interesting. I checked ALL_UPPERCASE with an underscore in regex 101 for this,
but it seems that vscode handles it different.
But we are on a good direction.
ALLUPPERCASE is recognised but overwritten by a special commands pattern.
-> This is a wontfix from my side. Too much effort needed to catch this up well.
@Confectrician Iāve been running 0.6.0 for a couple days. Looks pretty good so far, but Iām seeing the following, which Iāve never seen before.
When I have VS Code open, Iām seeing some spurious messages in my openhab.log file.
2019-11-07 12:26:42.389 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/actionItem' for the unknown item 'actionItem'.
2019-11-07 12:26:42.898 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/Garage' for the unknown item 'Garage'.
2019-11-07 12:31:13.659 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/0' for the unknown item '0'.
2019-11-07 12:31:27.735 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/0' for the unknown item '0'.
2019-11-07 12:31:28.137 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/0' for the unknown item '0'.
2019-11-07 12:32:26.640 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/command' for the unknown item 'command'.
2019-11-07 12:32:27.670 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/command' for the unknown item 'command'.
2019-11-07 12:32:28.038 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/to' for the unknown item 'to'.
2019-11-07 12:32:29.515 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/Send' for the unknown item 'Send'.
2019-11-07 12:32:29.827 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/Send' for the unknown item 'Send'.
2019-11-07 12:33:01.335 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/door' for the unknown item 'door'.
2019-11-07 12:33:07.438 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/door' for the unknown item 'door'.
2019-11-07 12:33:07.740 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/door' for the unknown item 'door'.
2019-11-07 12:33:31.777 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/door' for the unknown item 'door'.
2019-11-07 12:33:43.995 [INFO ] [rest.core.internal.item.ItemResource] - Received HTTP GET request at 'items/when' for the unknown item 'when'.
Edit: It seems to happen editing a rule when I mouse over something thatās not an item.
First: You won the game.
I was curious how long it takes to report this behavior here.
This is indeed introduced by the new hover provider, which will display item informations on mouseover in the editor.
I have recognized those messages too in my logs.
I have already broken down the algorithm to just send a request to rest api, when a single word was hovered.
But apart from that it is currently a try and error approach.
If rest api responds with an item -> Do the hove effect
If not -> do nothing
I have not yet decided what is the best way of improving this.
We could do a ābigā rest request on startup and fill some kind of storage to lookup all available items.
So we could decide if a hove is valid before making another http request.
I think this is my favourite idea so far.
I have added one really small feature, since i was annoyed from the current situation.
It just adds the already existing docs and insert item from channel commands,
which are usually available via command input or context menu.
Also i am working on a HoverProvider Class, which will load all existing item names from rest api on first need and then check those items for the hovered text.
We will then only ask the rest api for item values if a real item is hovered currently.
And since there are no bigger flaws so far i would then push a new release after a short testing period of this improvements.