Forums Bug Reports /filter -kg & $regml

when using the -g switch, $regml() isn't getting filled:

It's not really a bug since the help file specifically says it is only filled after a $regex or $regsub call, but I can see the merit in such a suggestion. I wonder if there are any complications that would arise from making $regml available in each _exmp alias call. Of course, you can just run the line through $regex from within _exmp to get the same result, but it would be less efficient.

Several others place in mIRC (different than $regex and $regsub) where regex are involved fill $regml, this is a bug imo, the help file is just misleading.

It still sounds more like a missing feature than a bug. Unless Khaled meant it to work in /filter like that, then it's not a bug (something not working as intended). Instead, it's just a missing feature where he has added support for $regml in other location than just the original locations mentioned in the help file but hasn't added it here yet.

But regardless of what anyone wants to call it (it doesn't really matter what it's called), it's a good suggestion to add support to /filter.

The help file is not misleading, it is simply not defining behaviour in all cases; in other words, filling $regml outside of $regex is undefined-- and you should not expect behaviour to exist when it is undefined. The fact that $regml is filled in certain other cases (ON TEXT for example) is not necessarily a feature that should be relied on, but rather a side effect. We had this same conversation in your /filter -k & $v1 "bug" report. In both cases, you seem to be expecting behaviour that is not explicitly defined to work the way you want it to. I see nothing that implies we should be expecting $regml() to be filled here. Depending on other identifiers is really not a valid argument, as the behaviour of other identifiers does a specification make.

That said, I'd be for making it a feature, but until it is explicitly supported, I see this as a missing feature, not an incorrectly implemented one.

A while ago, I reported a problem with $hfind not filling $regml() correctly, the problem has been fixed but you don't see the change in /help $regml(), still, I'm clearly expecting $hfind to fill $regml() if regex are involved.
The help file isn't saying that $regml() is filled after a call to $regsubex, so you are saying I shouldn't expect $regml() to be filled after a call to $regsubex? This is ridiculous.
There's no side effect here, it's quite easy to notice that any function involving regex fills $regml(), I'm not expecting something from an undefined behavior, stop acting as though mIRC was C++, "undefined" is a concept that does not really exist in mIRC, people that care know about things, you even suggested me to use an undocumented (so undefined right?) feature and now I should not expect behavior that are undefined, you can't play both cards can you?
Filling $regml() outside of $regex might be "undefined", the fact is that $regml() is filled outside of $regex, the help file is misleading and needs an update.

"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.