Forums Feature Suggestions Unnecessary Linesep between Notices

Long-time annoyance, but I'm of the mind that everyone agrees.

Can we please remove the linesep from between multiple sequential Notices within the Status window?
This will require remembering that the previous line was a Notice and that a linesep should be added when the next line is not a Notice.

Currently:



Ideally:

mIRC could easily fail in looking for current notice line in the window because a script echoed a line between the two fast notice, possibly a line that has the format of a mIRC's notice.
The scripting language was created for this, use it.
Regardless, I think most people annoyed by the linesep, myself included, have linesep = $null in options.

If I understand you correctly, you do not like the set "‒" separator between lines in certain messages with information, but at the same time, in all other windows and messages, it must be present to separate lines of text.
In this case, with all the capabilities of the user when working with the client, I see only one solution, this is to disable the separator in the mIRC options: Other -> Line separator -> (leave the field blank)

And for the necessary places and windows, create text event handlers in the scripts where you will need to add a line separator. For instance:

And so on for all types of messages...

Perhaps this option will suit you and will help you customize the display of messages in the desired form.

Another one option is to highlight specific service nicknames that send notices. For such messages, do not make a separator between the lines, but for all other messages do:

And you can even catch notification lines, start and end, to stop setting the line separator:

Or even this option, perhaps the most suitable for your question:

It's can also be done for "WHOIS" messages if needed.

I've deleted the linesep character, so this issue won't affect me. However, there's a larger grab-bag of things currently using the linesep, so if you delete it so you can selectively add it back in, you'd also need to trap other things, including DCC SEND/GET FAIL/COMPLETE, blue scripting errors, identifier warnings, ping/pong, ctcp, etc.

Also, while your usage of $count will work almost all the time, it's possible for a false match if the nick is asdfBotServ etc. A more precise way is

$istok(NickServ ChanServ MemoServ BotServ HostServ OperServ,$nick,32)

I do believe you've requested this before :-]

Alas, it is not as simple as it sounds.

There are currently 500+ calls to the linesep routine to print a linesep to a window, called by different features, eg. events, numerics, commands, identifiers, error messages, etc. Some of these calls are context-aware, eg. some numerics can appear both in groups and alone and need to be surrounded by lineseps in both cases.

There are 1000+ calls to the routine that prints a line to a window, without lineseps, and with no awareness of lineseps.

The only practical way to implement this, that I can see, is to continue to have a linesep printed after each notice but if the next added line is a notice from the same user, to insert the new notice before the linesep at the bottom. This will essentially group all consecutive notices from the same user together, even if they are replies to several different requests. This will also be backward-compatible with all other features that have no awareness of lineseps.

I have tested this out on different networks, eg. GameSurge sends the MOTD as notices, and, to be honest, I found it harder to read multiple long notices that are stuck together. But it can improve the readiblity of eg. /nickserv replies.

There is no way to use lineseps to group separate /nickserv replies without scanning for words that demarcate the beginning and ending of a group of messages. As I have mentioned before, I am no longer doing this because these words vary across ircds, networks, and languages and are not a reliable basis for changing client behaviour.

<3

Thanks Khaled!

27.Changed how notices are displayed so that consecutive notices from the same user are now grouped together.

This change seems to have effected channel messages by adding line separators to only my channel messages, and not others. This happens regardless of the spacing setting. Actions don't seem to be effected. Also this...

[09:56] * Now talking in #chan
-
[09:56] * Topic is 'Topic'
-
[09:56] * Set by RoCk on Sat Nov 21 09:54:28 2020
-
[09:56] * ChanServ sets mode: +o r0ck
-
[09:57] * r0ck is now known as RoCk

Thanks this is actually due to a different change where I was trying to standardize the way separators are used across routines. It looks like this won't work in many contexts, so I will be reverting the extra separator change in the next beta.