Tested on Linux.
Please verify it is fine on Windows and macOS

Thank you!

This needs changes on the client and server side? How do we ensure that users don’t get confused why it "doesn’t work" because a server is not up to date?

This needs changes on the client and server side? How do we ensure that users don’t get confused why it "doesn’t work" because a server is not up to date?

On an old server, the multiline messages with be merged into a single line
see: #1021 (comment)
Do you have an idea how to handle this / or accept it?

Either the client gives a warning (as placeholder text (?)) or we leave it like that.

I could add something like this to the placeholder text:

WDYT?

The client knows the server version. It shouldn't be operating in this mode unless the server is offering the feature. It should revert to the existing behaviour. It should only offer this if requested, too (so a client settings entry is needed). The server should also need configuring to offer it, perhaps - not sure on whether that's really needed, though.

@pljones The chat window will start with the existing behavior:

The new input mode can then be selected via the menu or by keyboard shortcut (Ctrl+M):

The client knows the server version. It shouldn't be operating in this mode unless the server is offering the feature.
The server should also need configuring to offer it, perhaps - not sure on whether that's really needed, though.

Note that this doesn't really change what a client is sending to the server. You can actually already enter multiline messages in the single-line input field by just copying&pasting them from somewhere. The 2nd input mode just makes this easier.
A multiline message sent to an old server is getting merged into a single line, just like it is already happening when you paste a multiline message into the input field.
Because of that, I would prefer to keep it simple and to not add an extra server option for this.

Btw. I had described how I wanted to implement this and asked for feedback here #1021 (comment) . You probably just missed that - but not having got any objections I proceeded.
I'd like to contribute to the project more often when the time allows, but would really favor to be able to agree on a feature before starting to implement.

Sorry, missed the link in the top post of the PR, yes!

Having the option on the chat window is good, the short cut is even better. I'd still like the client to check the server version and only "make it easy" when it's going to actually work. I'm not particularly fussed about the server side option, to be honest, so long as it's not opening things up. Work was done to cut down what text was allowed through the server at one point. That part looks fine.

I'd still like the client to check the server version and only "make it easy" when it's going to actually work

I'm not sure about this. Right now the chat dialog even allows for sending a message even you are not connected to a server (it will just disappear then). So disallowing multiline messages on older servers will need quite some extra code / additional complexity, especially when you want to react to switching from a new server to an old server.

1. Permitting the feature even if the server does not handle it in the best way, may be confusing or lead to the conclusion that the feature is broken
2. Enabling/disabling the option depending on the server version may be equally confusing when switching servers and seeing it work / stop working.

Given that both options have downsides, I'd go for the technically simpler option 1 of offering this feature unconditionally (and maybe outlining the requirement in the changelog).

I'd rather not make this server-configurable unless there are specific reasons to do that.

(Haven't looked at the code in detail yet)

I can't see anything on the server side that would need to be configurable - it maintains the safety, just adds the <pre> tags if it spots the \n character.

Having broken things not get improved because they're already broken isn't a good argument, in my view. It generally means people don't make things better.

Just to add

Enabling/disabling the option depending on the server version may be equally confusing when switching servers and seeing it work / stop working.

What, more confusing that having no indication that it's not going to work until after you've spent time formatting the input, only to lose your effort when the server doesn't add the tags?

Closing as this needs more alignment: #1021 (reply in thread)

Thanks for the effort so far and the explanation in the discussion of where we've got to, @passing.