multiline: Specify behavior with respect to formatting.

[progval]

This is the only way to format the fallback for multiline-unaware clients
the same way as for multiline-aware clients

[slingamn]

lgtm

[jwheare]

I'm not sure. This puts a significant burden on clients when interpreting user input and composing a multiline message.

[progval]

So currently, if someone sends this:

BATCH +123 draft/multiline #channel
@batch=123 PRIVMSG #channel :not-bold <0x02>bold
@batch=123 PRIVMSG #channel :unclear
BATCH -123

then irccloud and the current weechat master will display it like this, because they don't implement this PR:

not-bold bold
unclear

and assuming servers don't do any reformatting, then every client not supporting multiline will get this:

PRIVMSG #channel :not-bold <0x02>bold
PRIVMSG #channel :unclear

so they will display it like this:

not-bold bold
unclear

I understand this can be annoying to implement, but we need to either:

1. accept this solution
2. propose a different solution
3. decide it's not a problem

Could we resolve this before weechat ships version 4.0 with draft/multiline support?

[progval]

Update: weechat released v4.0 without changing its behavior with respect to formatting.

[progval]

@flashcode As implementer of the multiline spec, could you weigh in on this question?

[JustAnotherArchivist]

This has been stalled for some time.

I agree that this is the only sensible way of doing it. Any other approach has no sane fallback mechanism.

There is however one complication that hasn't been addressed: the current draft says says this about fallback clients:

When delivering multiline batches to clients that have not negotiated the multiline capability, [...]

Servers SHOULD maintain the line composition sent by the client instead of combining to a normalised form before re-splitting. This ensures that steps taken to split long lines appropriately are preserved.

If the servers don't maintain the lines as sent, this would again lead to different formatting between multiline and non-multiline clients. The only sensible approach to me here seems to be to turn that recommendation into a requirement, i.e. change the 'SHOULD' into a 'MUST'.

[JustAnotherArchivist]

Actually, the above would apply not only to fallback clients but also to multiline-capable ones; their representation would also change if the server didn't maintain what the author client sent.

[progval]

And that's fine. Servers have always been allowed to tamper with the text and color codes if they want to.

[JustAnotherArchivist]

I suppose so. Would a recommendation to insert formatting reset codes during such rearrangements (if needed) be reasonable?