Multiline messages

[highflyer77]

CAP multi-line
This is only an incomplete example of how it could work, syntax or method to impliment would vary.

would mark the new line (or whatever char. to be determined).
would mark end of message, same as irc now uses.

• Raw message sent by user with multi-line support enabled:

<myNick>    This is my message I want to send. <lf>
            This would be line 2, I want to keep it intact with the first line. <lf>
            line 3 and end of the message. <crlf>

• How message "is" shown with "no" multi-line support:

<myNick> This is my message I want to send. This would be line 2, I want to keep it intact with the first line. line 3 and end of the message.

• How message should be shown with multi-line support:

<myNick>    This is my message I want to send.
            This would be line 2, I want to keep it intact with the first line.
            line 3 and end of the message.
<OtherNick> Yeah cool.

• multi-line support would be usefull for pretty printing short code examples too.

<myNick>    #! /bin/bash
            echo "my cool script"
            if [ -n "$result" ] ; then
                echo "$result"
                exit 0
            else
                echo "File pattern not found"
                exit 1
            fi
<OtherNick> Nice code dude!

• The benefit is: new lines are kept together without splitting up the message format.

I know some channels would have a limit or ban, but others could enjoy the multi-line support.
The 512 character limit would still apply to the message with multi-line support including the and characters

Please comment and let me know if this is feasible,
Thank you.

[RyanSquared]

As I said on IRC, I think this would be better implemented via BATCH.

[dwfreed]

This wouldn't work in a lot of IRCds as they're currently implemented, because they accept LF from clients to mean the same thing as CRLF.

[RyanSquared]

This wouldn't work in a lot of IRCds as they're currently implemented, because they accept LF from clients to mean the same thing as CRLF.

I know that, using cqueues for example, would not allow this; LF is automatically translated whether it be CRLF or LF coming in from the server.

[highflyer77]

This wouldn't work in a lot of IRCds as they're currently implemented, because they accept LF from clients to mean the same thing as CRLF.

I sorta already knew that, that's why it says at the top: " (or whatever char. to be determined). "

1. This was not meant to be used "as currently implemented" that's why it's being proposed.
2. If it's not implimented then they could just send multible messages, or ignore the LF, it's still not a deal breaker.
3. A CAP may not even be nessesary to impliment this.

It was only used for an example, to get the conversation started. :-)

[kaniini]

Not ever happening in Charybdis. Seriously, this is an over my dead body thing.

edit: To clarify, what I mean here is the <lf>/<crlf> behaviour. Hacking our linebuf code to support this proposal is simply not happening.

[MrBenC]

From IRC:
<MrC> Other than spamming or ASCII art (both of which gets you banned and quickly in most places) I don't see it being that useful. The code snippet example, really should be on a paste bin service. I for one would not really enjoy having it scroll up as I'm trying to study it.
<MrC> And yes, consecutive lines by the same user could be displayed that way. Think some clients actually do that. But that should probably be up to the client.

I'm sorry, but I really can't think of any actual legitimate use for it; the downsides aren't worth it. To me this is just a means to prevent race conditions that may break up spam or ASCII art.

In the case of spam, could this prevent modes and kicks from say, a channel operator or bot that wants the spam to cease? This doesn't seem like a good idea at all.

Ben

[jwheare]

The request here is entirely reasonable, the implementation can be figured out, probably using BATCH, it will need to be specified properly.

[dequis]

I think the main problem is that we'd like to have both multi-line messages and long payloads (#197), and both issues sound like they could be solved with BATCH but they overlap:

• If you have long messages as a batch that just concatenates them, you can't have multiple lines
• If you have a batch that makes each line a new line, you're still limited by (512-prefixes) for each message

[jwheare]

Long lines could perhaps be solved by a continuation tag. I don't see the conflict.

[jwheare]

I guess by "continuation tag" I just mean a different BATCH type. You can nest BATCH, e.g.

:irc.host BATCH +multi123 multiline
@batch=multi123 :nick!user@host PRIVMSG #channel :Line 1
@batch=multi123 :irc.host BATCH +cont123 continuation
@batch=cont123 :nick!user@host PRIVMSG #channel :Line 2...512 limit reached
@batch=cont123 :nick!user@host PRIVMSG #channel :Line 2 continued
@batch=multi123 :irc.host BATCH -cont123
@batch=multi123 :nick!user@host PRIVMSG #channel :Line 3
:irc.host BATCH -multi123

[RyanSquared]

@dequis The point of this is that you don't have to worry about the 512 limit except for how normal lines work, which makes it entirely compatible with non-IRCv3. @jwheare's example explains this better, I guess.

[sadiepowell]

👎 for introducing special message parsing rules but 👍 for making it a batch type.

[RyanSquared]

I believe we can uniformly agree against special message parsing rules.

[highflyer77]

I can't see any harm with parsing rules.

1. If the existing clients that don't support it, would just simply just ignore it, no problems for anyone.
   Or
2. Would just simply just create multiple messages, still no problems.

Only the clients that support it would benefit.
But # 1. and # 2. would depend on how the parsing rules are implimented.

• This is easier to implement, it has lower overhead required compared to sending batch especially for simple short text.

It would also co-exist with batch, so having the best of both could be possible.

[RyanSquared]

• BATCH exists.
• BATCH works.
• BATCH would require no further work implementing parsing rules.