Open bradyt opened 2 years ago
Converting to markdown would be a sensible fallback for +c
channels, for non-+c
I think it makes sense to keep it the way it is.
I just assumed that the bridge would send plaintext only (i.e., send the raw markdown as text). That seems like the most sensible thing. I don't want to assume any capabilities on the primitive IRC end of the bridge. :-)
I don't really understand why the bridge is working with HTML in the first place. Wouldn't the plaintext version of the message be a safer starting point?
A setting to always send raw Markdown would be nice as there are IRC clients that understand it.
Which ones?
Convos for example and also most XMPP clients connected to IRC channels via Biboumi. But there are probably also others that support basic markdown.
For
#emacs:libera.chat
, the channel mode contains+c
.Currently, user does not have an easy way in desktop Element to always rely on message being sent as plain text. See https://github.com/vector-im/element-web/issues/20321#issuecomment-1086967468.
Underscores are silently converted to html italics,
> a quote
is silently converted to blockquote html. IRC bridge silently converts these to control codes or ASCII text, the Element/Matrix user is not aware of this. If the IRC channel silently drops control codes, but not the>
character, user may not be aware of what actually is received at other end. This can be unfortunate if these characters are part of a syntax under discussion on IRC channel, or is being used to interact with a channel bot.In particular,
_underscored text_
is silently received asunderscored text
on+c
channels.As long as Element, arguably the flagship Matrix client, is not facilitating sending non-html text converted from markdown, I would suggest that italics and bold text are not converted to control codes by IRC bridge.
I understand the likelihood that this project will decide to not avoid control codes. I hope such an explicit stance hopes to further motivate the issue at Element for desktop.