Discourse plugin for openHAB Community


( ) #1

Hey guys,
following up on an idea discussed with @teichsta at the new forum announcement (Discourse) I have spent a few hours on creating a plugin for Discourse, which adds additional openHAB syntax buttons to the composer toolbar.

The plugin, documentation and all future updates can be found here: https://github.com/ThomDietrich/discourse-plugin-code-fences-buttons

For now, the plugin is not that special. The button “openHAB *.rules code fences” will input markup text for code with php highlighting, which does the trick for now. Implementing the DSL syntax of openHAB into discourse syntax highlighting is another task and everybody is invited to dig into that :wink:


openHAB now has its own fully fledged discussion forum!
openHAB now has its own fully fledged discussion forum!
How to use code fences
(Kai Kreuzer) #3

This plugin is activated now!

Next I would like to see some more specific syntax coloring instead of treating openHAB stuff as php files :sunglasses:


(John Cocula) #4

Just giving a code fence without specifying a language, like:

```
code
```

It would be nice to have a perfectly matching syntax highlighter, but that’s probably more effort than it’s worth. Your solution works great – thanks for providing it.


(Kai Kreuzer) #5

This is the 5th button with the tooltip “code fences”.


(John Cocula) #6

Yes indeed, but my point was regarding using the csv syntax highlighter for items files, and the php syntax highlighter for rules and sitemap files, where those highlighters do not match the syntax, and could (possibly) add confusion. But it’s not unreasonable, either. :slight_smile:


( ) #7

First to make that clear. I also think someone should work on providing openhab syntax highlighting for highlight.js. My plugin can then be adopted to use these new languages! https://highlightjs.readthedocs.io/en/latest/language-guide.html
Volunteers?

I get what you are saying. You are right with items. csv isn’t perfect (wrong formatting of “String” for example), do you know of a better language to use?
With rules, i still think php is a good choice. I can’t tell you why I didn’t select java, seems to work out too and makes way more sense I guess.

Here is the critical part: When using default, so when not explicitly defining a language to highlight, highlight.js will select one itself. The autodetection process is however a bit tricky with unknown syntax, while testing just now the highlighting of the first block switched from one not so good fit to another just while I was typing. That’s why I think default is not a secure option.

Random example (not a real rule):

DEFAULT (bash autodetected):

import org.openhab.core.library.types.*
//import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
//import org.joda.time.*

rule "Test"
when
    Item BD_Heizung_Preset received command
then {
    //logInfo("RULE", rulename + "Schnellauswahl")
    // Wenn Auswahl auf "F" und update auf "A" 
    if (BD_Heizung_SetMode.state == 4 && BD_Heizung_Mode.state == 0) {
        switch (receivedCommand){
            case 0: BD_Heizung_Lowering.sendCommand(ON)
            case 1: BD_Heizung_Comfort.sendCommand(ON)
        }   
        createTimer(now.plusSeconds(1)) [|
            BD_Heizung_Preset.postUpdate(-1)
        ]
    }
}
end

PHP:

import org.openhab.core.library.types.*
//import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
//import org.joda.time.*

rule "Test"
when
    Item BD_Heizung_Preset received command
then {
    //logInfo("RULE", rulename + "Schnellauswahl")
    // Wenn Auswahl auf "F" und update auf "A"
    if (BD_Heizung_SetMode.state == 4 && BD_Heizung_Mode.state == 0) {
        switch (receivedCommand){
            case 0: BD_Heizung_Lowering.sendCommand(ON)
            case 1: BD_Heizung_Comfort.sendCommand(ON)
        }
        createTimer(now.plusSeconds(1)) [|
            BD_Heizung_Preset.postUpdate(-1)
        ]
    }
}
end

Java:

import org.openhab.core.library.types.*
//import org.openhab.core.persistence.*
import org.openhab.model.script.actions.*
//import org.joda.time.*

rule "Test"
when
    Item BD_Heizung_Preset received command
then {
    //logInfo("RULE", rulename + "Schnellauswahl")
    // Wenn Auswahl auf "F" und update auf "A"
    if (BD_Heizung_SetMode.state == 4 && BD_Heizung_Mode.state == 0) {
        switch (receivedCommand){
            case 0: BD_Heizung_Lowering.sendCommand(ON)
            case 1: BD_Heizung_Comfort.sendCommand(ON)
        }
        createTimer(now.plusSeconds(1)) [|
            BD_Heizung_Preset.postUpdate(-1)
        ]
    }
}
end

(John Cocula) #8

That makes perfect sense and you have dug deep into it. One last thing I can think of would be to go ahead and generate

```items
your items
```

```rules
your rules
```

```sitemap
your sitemap
```

and then co-opt the closest ones that currently exist and name them items, rules and sitemap. Later someone can actually write proper syntax highlighters for the real languages, and all the old MarkDown will suddenly look better!


( ) #9

“later someone can” :slight_smile:
That’s a good idea. As far as I see it, we would just need to copy one language definition and rename and start to modify it. Afterwards we can build our own highlight.js and bind it with the openhab discourse setup. Done.

What I don’t like about this solution is, that it seems like there is no way, we can contribute openhab-items-syntax into highlight.js and smuggle it into discourse this way. Therefore these modifications in our own fork of highlight.js will always be detached and a hack that @teichsta needs to apply after each discourse upgrade… (i.e. replace a file, possible compatibility problems?)

If you guys think that’s acceptable, I can probably look into the process the next few weeks.