mIRC Home    About    Download    Register    News    Help

Print Thread
Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
Do we want line separators between successive notices within the Status Window?
Or should they be removed if a series of notices come from the same person or bot?
(That is, don't add a line separator until something different happens.)

Yes, keep the poor line separators. We've had the forever!

No, get rid of them! They make my status window so messy!!

Code:
-
[12:34] -NickServ- ***** NickServ Help *****
-
[12:34] -NickServ- NickServ allows users to 'register' a nickname, and stop
-
[12:34] -NickServ- others from using that nick. NickServ allows the owner of a
-
[12:34] -NickServ- nickname to disconnect a user from the network that is using
-
[12:34] -NickServ- their nickname.
-
[12:34] -NickServ-  
-
[12:34] -NickServ- For more information on a command, type:
-
[12:34] -NickServ- /msg NickServ help <command>
-
[12:34] -NickServ- For a verbose listing of all commands, type:
-
[12:34] -NickServ- /msg NickServ help commands
-
[12:34] -NickServ-  
-
[12:34] -NickServ- The following commands are available:
-
[12:34] -NickServ- GHOST           Reclaims use of a nickname.
-
[12:34] -NickServ- GROUP           Adds a nickname to your account.
-
[12:34] -NickServ- IDENTIFY        Identifies to services for a nickname.
-
[12:34] -NickServ- INFO            Displays information on registrations.
-
[12:34] -NickServ- LISTCHANS       Lists channels that you have access to.
-
[12:34] -NickServ- REGISTER        Registers a nickname.
-
[12:34] -NickServ- RELEASE         Releases a services enforcer.
-
[12:34] -NickServ- SENDPASS        Email registration passwords.
-
[12:34] -NickServ- SET             Sets various control flags.
-
[12:34] -NickServ- UNGROUP         Removes a nickname from your account.
-
[12:34] -NickServ-  
-
[12:34] -NickServ- Other commands: ACC, ACCESS, CERT, DROP, HELP, LISTLOGINS, 
-
[12:34] -NickServ-                 LISTOWNMAIL, LOGOUT, REGAIN, SETPASS, STATUS, 
-
[12:34] -NickServ-                 TAXONOMY, VACATION, VERIFY
-
[12:34] -NickServ- ***** End of Help *****
-


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Dec 2008
Posts: 1,515
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2008
Posts: 1,515
Yes keep them, also you have the scripting option to remove them.


Need Online mIRC help or an mIRC Scripting Freelancer? -> https://irc.chathub.org <-
Joined: Jul 2006
Posts: 4,145
W
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 4,145

I don't want them removed, you clearly do, if everyone don't want them, you dont get the feature and you're screwed. I think you should rather ask for an option to do it, this way the feature does not depend on others.


#mircscripting @ irc.swiftirc.net == the best mIRC help channel
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
I deleted the hyphen in the linesep box so I don't have it between any status window messages at all.

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
westor: I'm not sure what the scripting options are available to remove them, without halting the default notices and echoing my own, which come with clear disadvantages.

Why would anyone want to preserve the line separator between two successive notices from the same sender? The linesep could be added if the sender's name changes, or when some different data needs to be printed to the status window. We enjoy /motd and /whois and other large outputs without them being interlaced, and while technically different, I don't believe each individual /notice needs to be encapsulated between seps.

On a slightly separate(pun) topic, it might also be really cool to timestamp all the error messages that are currently not timestamped in the status window. It seems to be willy nilly which messages get timestamps and which do not. It'd be nice to know exactly when an error occurred.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Jan 2004
Posts: 2,127
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 2,127
You could delete the linesep char, then have an ON NOTICE event that chips in with a linesep when ($nick != %prev.nick), after figuring out whether the output goes to Status Window. Since this isn't halting the event, it lets the other scripts modifying event messages to do their own. As long as your EVENT is at the top of the scripts list, it shouldn't be appearing between the 1st and 2nd scripted echo.

Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Raccoon
No, get rid of them! They make my status window so messy!!

+1, this has always been annoying--also for people who don't know anything about scripting, btw. In fact I'd be curious if anyone here can come up with a reason in favor of keeping those particular separators, other than "at this point I am used to it"..


Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
I am not going anywhere near changing how separators work :-) If you do not like them, you can disable them by entering an empty character in the separator box in the Options dialog. That is what it was designed for.

When I first started working on mIRC, I went through a huge amount of effort to display incoming information in a clear way. Most IRC clients at the time displayed all lines one after another and it was almost impossible to distinguish one event from another. The separator helped group different events. Unfortunately, it became an endless and almost impossible task. I had to add increasing numbers of exceptions and internal states throughout the code for different combinations of events across different networks. I am no longer doing that.

What you are seeing with these notices is really a server design issue. Server coders should never have used notices to display large amount of information to users. It shows how disconnected some server coders are from how GUI clients work. Prior to this, a notice had always been used to indicate a special message that was meant to alert a user to a particular event or important information. That is why a notice was assigned a special sound in mIRC. And why a notice is always surrounded by two separators. It had never been used to display streams of information to users and probably was never intended for that.

The worst example of this is IRCnets use of notices to send the /squery alis list * channels list. This makes it impossible to parse or display the list in a usable way without checking for english language combinations of text to determine the start and end of a list, set internal states, and so on. This method completely undermines the purpose and utility of using numerics, which make it clear to clients what a server message represents, when a group of messages start, and when they end.

Joined: Feb 2003
Posts: 2,812
Raccoon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Feb 2003
Posts: 2,812
I agree that it's a pretty terrible way to communicate large amounts of data, but aside from reusing MOTD or creating a new general-purpose messaging numeric or whisper... NOTICE is what we have to work with. Alis is still used and heavily promoted on many networks, like Freenode, said to be somehow better than /list (i happily disagree), and looks stunningly awful even today in 1200p.

But, now that the seed has been planted, admit that you're kind of curious what the linesep code looks like after 20 years of neglect smile

I would remove the linesep character, but I prefer keeping it for everything else that isn't a sequence of bot notices.


Well. At least I won lunch.
Good philosophy, see good in bad, I like!
Joined: Apr 2004
Posts: 871
Sat Offline
Hoopy frood
Offline
Hoopy frood
Joined: Apr 2004
Posts: 871
Originally Posted By: Khaled
What you are seeing with these notices is really a server design issue. Server coders should never have used notices to display large amount of information to users. It shows how disconnected some server coders are from how GUI clients work. Prior to this, a notice had always been used to indicate a special message that was meant to alert a user to a particular event or important information. That is why a notice was assigned a special sound in mIRC. And why a notice is always surrounded by two separators. It had never been used to display streams of information to users and probably was never intended for that.

Even though the whole issue is not very important, I do not agree that this in particular is a fair view.

When I started using mIRC on a daily basis, early 1997, notices were widely used for the purpose of communicating fairly large amounts of data at once--due to, in particular, the prevalence of eggdrop bots. As such, back then, having a sound assigned to notices was already a default that was quite frankly out of touch. Notices were and always have been the way to send information from an automated system: that is what they were specifically designed to do, as stated and explained in RFC 1459 (which I believe was around before mIRC's development started; otherwise it wasn't long after). The volume of information sent from that automated system was never a factor, and thus, there was nothing that would suggest that (say) eggdrops should use PRIVMSG rather than NOTICE for large streams of information--quite the opposite, in fact. Thus, I believe the middle portion of what I quoted above is either an idealized version of the past, or based on input at the time that was too limited.

As for notices coming from services, that is a somewhat different issue, and one that is relevant for the separators more than the sounds. I do not know what considerations went into using notices rather than numeric replies for service information, but I strongly suspect it has its roots in the original versions of services being clients rather than servers. In that case, the use of notices was a perfectly reasonable approach, being the standard and RFC-approved way for automated (non-server) processes to send textual information. Either way, by the time I started using mIRC, such services were already around. As such, I think your above view is opposing something that has been a done deal for at least 21 years (i.e., over 85% of mIRC's lifetime so far), and cannot reasonably be used anymore to defend what is effectively a (small but) solvable client-side annoyance.

Edit: removed silly ending, thanks Raccoon

Last edited by Sat; 08/10/18 07:39 PM.

Saturn, QuakeNet staff
Joined: Dec 2002
Posts: 5,411
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 5,411
Very well, we will have to agree to disagree. Thanks for your comments everyone.


Link Copied to Clipboard