(1)

instead of requiring @ (or other items in $prefix) to be followed by another character, have @<tab><tab> be sufficient to cycle through all the @Ops. Ditto for +<tab> etc.

(2)

Though tab-complete looks at $prefix to see which strings can be auto-completed to include the channel name, it currently doesn't include the % for halfops when that's in $prefix, such as at Rizon. Use case:

/notice @#<tab_complete> message
/notice %#<tab_complete> message

A work-around is to set this next global variable then after %# you can press <tab> twice:

/set %# $active

If backwards compatibility needs to support auto-complete for a global variable, then have the $prefix setting be a fall-back before do-nothing.

operator: iscm, and case-mapping switch for $ial and possibly $ialchan and others

Just as $sorttok offers a 'c' sort method which acts differently based on the value of the $prefix identifier, it can be difficult to accurately match $banmask or identify which nicks in the IAL match a specific mask, without functions which recognize case-insensitivity the same way the server does.

Apparently the creators of rfc1459 decided that it was useful to have a weird definition of what "case-insensitive" means. For most servers, the 005 numeric contains CASEMAPPING=rfc1459 which, in addition to treating the A-Z and a-z ranges as upper/lower case equivalent nicks, thinks there are now extra case-insensitive upper/lower pairs:

123 { 91 [
124 | 92 \
125 } 93 ]
126 ~ 94 ^

There apparently is also a "strict-rfc1459" which recognizes all the pairs except for the 126/94 match.

For scripts trying to see which nicks match a new $banmask being added or deleted, the script can return the wrong results if the $banmask contains contains any of these 8 (or 6) characters and there are nicks which are using the opposite character of that pair.

For example, a script like this should remove a new banmask if it matches yourself:



For the most part it would work, however, if I change my nick and someone sets a banmask:

/nick maroon{
/mode #channelname +b maroon[!*@*

... the script doesn't think that $banmask matches $address($me,5), because it doesn't match me in the real world.

//echo -a $ial(maroon[!*@*,0)

Likewise, if the script were to loop through the IAL checking to see how many nicks match this $banmask, the answer would be zero because $ial is using the real-world definition of case-insensitive instead of looking at CASEMAPPING= and acting accordingly. It would be zero because using the { prevents anyone else from using the maroon[ nick.

/kick #channelname maroon[

This kick, using a fake case-insensitive match, matches against maroon{ and it kicks maroon{ from channel. And because the { and [ are also matched by the channel in evaluating the +b modes, it blocks the maroon{ nick from re-entering too.

This has the potential to affect people using "normal" nicks, because - unless it's a bug that is going to be fixed - freenode makes the abnormal case-insensitive matches in the userid too. The +b banmask matches the ~ in nick!~userid@host, where the ~ is assigned to nicks which didn't answer the identd check at port 59.

/mode #channelname +b *!^*@*

This means that the above mask bans everyone who did not answer the identd handshake, and it would be easy for scripts to not notice that this ban was affecting a lot of people. I wasn't able to find any @vhosts containing any of these 8 characters, so I don't know whether the definition extends to the entire address, or whether this was supposed to be applying only to the $nick.

CASEMAPPING=ascii
CASEMAPPING=rfc1459
CASEMAPPING=strict-rfc1459

I'm assuming that there's only 3 possible strings for CASEMAPPING=, and there shouldn't be a need for $ial() and $ialchan() to *not* behaves according to the CASEMAPPING= setting. If there's no such keyword found, or it's some unknown new string, I'm thinking it should retain the current =ascii behavior.

It's possible this may also need to affect $level /auser /ruser etc, except those have the potential to affect nicks at all networks regardless where the mask was created.

some kind of iswmCM or isCM identifier would avoid corrupting the current "iswm" identifier which should not see this weird definition of case-insensitive, but that's the only place I can think of which normally does NOT need to see the altered settings, unless there are scripts needing to check "if (maroon} == maroon])".

Most networks I checked use the CASEMAPPING=rfc1459 setting, with the exception being SwiftIRC which has CASEMAPPING=ascii

https://tools.ietf.org/id/draft-hardy-irc-isupport-00.txt
section 4.1

https://forums.mirc.com/ubbthreads.php/topics/267312/min-max
https://forums.mirc.com/ubbthreads.php/topics/265240/need-code-help

These threads related to the issue of collision between existing alias names and new identifiers. A possible solution would be if the installer's process would include an $isalias check to match against any new identifier added in that specific version, and possibly including a check against those added in versions released a short time earlier. It would simply be an FYI alert so people could either take steps to rename their existing alias or ask questions to the person who wrote that script, in case the alias is needed by other scripts.

Possibly also include alerts for collision with new /commands created too, but definitely not including a cross-check for all built-in commands because there are many users of 'theme' scripts which have aliases to handle things like /msg /me /notice etc and they would be confused by the new alerts if they don't understand what the theme script is doing under the hood.

Probably shouldn't need to be checking against new identifiers in versions released more than 1 year prior to that version, so currently that would be...

v7.64 $ticksqpc
v7.62 $min $max /donotdisturb

-r or -c switch to remove/clear the current topic. Once a topic has been created, there's not an obvious way for a script to remove it, though it's possible to do it manually from the channel-central dialog. In order to allow a script to clear the topic, I had to create a /debug window to see what happened from using channel central, finding out it was doing the same as:

/!raw TOPIC #channelname :

Dear Khaled,

I really need to find a solution that allows me to edit the multi-line contents of a multi-line editbox. This is currently unsupported by the /editbox command as it will not handle $cr or $lf characters.

Thanks.

I have been looking around for a project like this so many times. And the most projects is outdated.
So now I have been learning c++ just for this.

My project is named Spoton and can be found as open source on Github
I have also made the DLL-File Downloadable on Github if people don't know how to compile the c++ project.

How to use the DLL-File in mIRC
A script is also made for mIRC, a simple alias to write out the song. I didn't want to make something big, just basic.

An example how it looks like when just echo out the song in active window: