Leerzeichen farbig darstellen möglich ?

Begonnen von TomLee, 24 August 2020, 19:08:18

Vorheriges Thema - Nächstes Thema

TomLee

Hallo,

kann man ein einzelnes Leerzeichen, etwas genauer: ein Leerzeichen nach einem Komma, im Wiki farbig darstellen ?

Wenn ja, wie ?

Gruß

Thomas

ph1959de

Da das FHEM Wiki auf MediaWiki basiert, sollte das hier funktionieren:
<span style="background:yellow"> </span>

Siehe hier: Hilfe:Farbe
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

TomLee

Ok, Danke.

Das klappt in Fließtext und in code-Tags:
:<code>bla<span style="background:yellow">&nbsp;</span>bla</code>

Bekommt man es irgendwie auch im syntaxhighlight-Tag hin, das klappt nämlich nicht.
<syntaxhighlight lang="perl">bla<span style="background:yellow">&nbsp;</span>bla</syntaxhighlight>

ph1959de

Da hab ich auf die Schnelle nichts gefunden (gesucht habe ich hier). Schon möglich, dass Syntaxhighlight die alleinige Kontrolle über die Formatierung haben möchte ... das "highlight=..." Attribut liefert vermutlich nicht das gewünschte Ergebnis?
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

TomLee

Habs jetzt einfach mit der um ein Leerzeichen eingerückten Variante umgesetzt.

* die mehrzeilige Definition mehrerer UserReadings setzt ein Leerzeichen nach dem Komma voraus
myreading {my $v = ReadingsVal($name,"actuation","error")+62;
fhem("set PID desired $v");
$v;},<span style="background:grey">&nbsp;</span>
myreading2 {my $v = ReadingsVal($name,"actuation","error")+62;
fhem("set PID2 desired $v");
$v;}

Beta-User

Hmm, ist zwar etwas OT, aber generell mal meine _Meinung_ zu diesem Artikel:
- die Beispiele sind fast alle ohne trigger, das ist "suboptimal"...
- In dem userReadings-Code noch was anderes zu machen (fhem("set <anderes Device>...")) ist weder erklärt noch optimal (das sollte man durch einen separaten Event-Handler erledigen lassen),
- eigentlich ist es auch kein positives Beispiel, userReadings zur Formatierung zu verwenden. Das sind Sonderfälle, oder täuscht mich das?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

ph1959de

Die eigentliche Frage ist wohl eigentlich erledigt, aber ich lasse hier noch mal "offen" für die von Beta-User angestoßene Diskussion.
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

TomLee

Ein Beispiel ergänzen wie man mehrere mehrzeilige Userreadings definiert bekommt wollt ich ergänzen mehr nicht, nicht den ganzen Artikel aktualisieren.

Dachte ich bleib bei dem Beispiel der Übersicht wegen, vor hatte ich eigentlich eines von mir zu verwenden, mich aber dann umentschieden.

Zitat- eigentlich ist es auch kein positives Beispiel, userReadings zur Formatierung zu verwenden. Das sind Sonderfälle, oder täuscht mich das?

Versteh ich nicht, wo wird hier was formatiert.
Sehe ein ReadingsVal statt ReadingsNum mit einer Addition, deinen angesprochenen nicht optimalen set-Befehl und die Angabe einer Variable. Formatiert ?

Deinetwegen ersetz ich das Beispiel auch durch ein komplexeres (längeres), korrektes (mit Trigger) userReadings, welches mich erst auf das Problem bei einem fehlenden Leerzeichen gebracht hat, wenn ich verstanden habe was du mit formatieren meinst.

Beta-User

Das war zum einen ausdrücklich nicht als Kritik an der Idee zu verstehen, den Artikel zu verbessern, und sei es nur in Details!

Grundsätzlich halte ich es auch für sinnvoll, ins Wiki auch nur Dinge zu übernehmen, von denen man (am besten aus eigener Verwendung) weiß, dass die funktionieren (genau aus dem Grund habe ich diesen Artikel - und manches andere - bisher nicht angefaßt... ich finde userReadings grundsätzlich sehr zweischneidig und aus gutem Grund ist das auch in den attrTemplates eher die Ausnahme, dass da überhaupt was vergeben wird. Aber genau vor dem Hintergrund sehe ich eben manches kritisch, was da heute steht und würde gerne dazu beitragen, dass wir möglichst auch an der Stelle "best practices" verbreiten und keine Dinge, über deren Sinn und Zweck man ggf. bei näherer Betrachtung unterschiedlicher Meinung sein kann).

Der Hinweis betr. Formatierung bezog sich auf das unveränderte Beispiel "Umrechnung der Temperatur (durch 10 geteilt) und Einheit [°C] angehängt", das war also ausdrücklich nichts, was aktuell "verschlimmbessert" worden wäre!

@TomLee: Vielleicht magst du dir das nochmal im Gesamtkontext durchsehen und ggf. dann einfach "erprobte" Dinge aus der attrTemplate-File übernehmen? V.a. die Shelly-pm-Geräte könnten eine ergiebige Quelle sein? (Es wäre auch ok, das Temperatur-Beispiel da mit Formatierung zu belassen, aber mir fehlt zumindest der Hinweis, dass man sowas (besser?) mit stateFormat lösen sollte (?); ich würde auch nicht mal ausschließen wollen, dass dabei auch suboptimale Dinge aus der attrTemplate-File zutage kämen - ich lerne auch immer mal wieder noch was dazu ;) ... Und es eilt auch nicht!).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files