Like kameloso.common.expandTags, this adds kameloso.irccolours.expandIRCTags that translates <tags> in outgoing IRC messages and does some string-replacing to translate them to IRCControlCharacters in their appropriate syntaxes.
It doesn't look like much and there are other ways around it, but compared to the previous solution it simplifies supporting both coloured and uncoloured output (to the server). As illustrated above, previously we branched; "if coloured send this, else send that". Now we just have one tagged message string and let expandIRCTags either expand them to colouring/formatting or strip them from the output instead. Messaging functions in kameloso.messaging expand the tags.
One drawback is that it accesses the global kameloso.common.settings to tell if coloured output should be sent, but there is already precedence in this in kameloso.printing, which does the same to tell if there should be coloured (and/or bright) terminal output. Not ideal, but the alternative is to pass the setting as an argument to each and every call, which is even less ideal.
Sort of an abuse of the notion of release candidate to include this now, but I'd very much like to see it in v3.0.0.
Like
kameloso.common.expandTags
, this addskameloso.irccolours.expandIRCTags
that translates<tags>
in outgoing IRC messages and does some string-replacing to translate them toIRCControlCharacter
s in their appropriate syntaxes.It doesn't look like much and there are other ways around it, but compared to the previous solution it simplifies supporting both coloured and uncoloured output (to the server). As illustrated above, previously we branched; "if coloured send this, else send that". Now we just have one tagged message string and let
expandIRCTags
either expand them to colouring/formatting or strip them from the output instead. Messaging functions inkameloso.messaging
expand the tags.One drawback is that it accesses the global
kameloso.common.settings
to tell if coloured output should be sent, but there is already precedence in this inkameloso.printing
, which does the same to tell if there should be coloured (and/or bright) terminal output. Not ideal, but the alternative is to pass the setting as an argument to each and every call, which is even less ideal.Sort of an abuse of the notion of release candidate to include this now, but I'd very much like to see it in v3.0.0.