"undefined" is not a C++ concept, it's an English word that applies to many different languages and specifications. If you cannot acknowledge that behaviour can be undefined, then nothing is stopping you from reporting a bug for any possible thing that isn't explicitly documented-- to the point where you can end up with contradictory bug reports. For instance, /fopen says nothing about whether it should close the file handle if opening the file fails. Obviously this must be a bug if it does not keep it open! Similarly, it must be a bug if it closes it! Undefined means the behaviour can go either way. Sane people would assume that a failed /fopen would create a handle, but this was in fact not the case until very recently. This is the point about undefined behaviour. You might expect it to do what you think is "the sane thing", but reality might not agree with you. This is evidenced in the recent bug report about
this very issue, which unfortunately required Khaled to revert behaviour in favour of backward compatibility. This is the problem with relying on undefined behaviour-- it stops Khaled from being able to make improvements to functions. Having undefined behaviour in the language is bad-- relying on it is worse.
Note that undocumented functions are different from undefined behaviours. There are certainly things missing from the help file that should be there ($utf*, /setlayer, etc.). However note that these functions are usually documented in
versions.txt if they are missing from the help file. $utfdecode and /setlayer are both documented there, so it is, in fact, documented-- just not properly. This is different from details about functions that are omitted completely in all documentation. There is never any mention that $regml() is meant to be filled in /commands that use regular expressions internally.
So what is "the sane thing" for /
filter? *YOU* think it is "fill $regml()"... but again, reality might differ here. It's simply not defined, so you can't legitimately call this a bug. If the behaviour for /
filter is truly intended, Khaled will (read: should) clarify it. Until then, you can't assume that mIRC is meant to behave in this fashion. Precedent in other commands is not a reason to blame mIRC for lack of functionality in others. In other words, sure, $hfind supports $regml(), but that does not mean /
filter is meant to. All of the scenarios where $regml() is filled are in synchronous identifier or event situations. /
filter, as we previously discussed, seems to be an asynchronous callback that likely creates new unattached script processes. I don't think the documentation for $regml() needs to be updated, because like I said, it is not a guarantee that $regml() should be filled unless Khaled decides to explicitly support this across any command/identifier that makes use of regular expressions internally.
Again, I'd like to see $regml() be filled here too, but I'm not claiming that the current behaviour is a bug. I think it's simply just not supported by design. My guess is /
filter would need some reworking in order to explicitly support things like $v1 and $regml(). On a sidenote, it would also be nice if the [alias] parameter in -k supported $qt() to pass in multiple arguments to the alias (like: /
filter -fk file.txt $qt(foo %somevalue) that called /foo <somevalue> <line>) so that state could be passed on to the callback alias rather than using global variables. But again, I'm not calling this lack of $qt() support a bug, because it's clearly
not defined to work in this fashion, and there's no reason for me to expect this to work.