Forums Bug Reports $$local_identifier within :EVENT: handlers

Within an ON:EVENT: handler, the $$identifier behavior has been to mimic /return instead of /halt. It doesn't halt another event handler in a different script from being seen, doesn't halt the message or input from being processed, and it doesn't trigger the & prefix of another handler as if the event had been halted.

However I'm not seeing consistent behavior for $$local_identifier, even where $chan is defined.

In ON:TEXT, $$chan triggers the /return behavior due to being $$null even within a #channel, unless you remove the semi-colon from the 'alias chan', in which case the not-null allows the :TEXT: handler to continue.

In ON:INPUT, $$chan triggers the identifier warning unless you enable 'alias chan'

Triggering the bug involves doing any of the following 3, before/after removing the semicolons from within double_dollar_test or from 'alias chan'.

1. correct behavior from: //double_dollar_test | echo -a success while test2 and test5 are commented

2. incorrect behavior from typing anything in any editbox, within :INPUT: $$chan generates identifier warning

3. incorrect /return due to $$chan being seen as $null within :TEXT:, even within a #channel when the message is seen: test <anything>. I would expect the /return from $$chan only outside #channel, such as in /query window or in status window.

Thanks for your bug report. I tested your script and it seemed fine? Was I meant to be looking for return/halt values/behaviour? Identifier warnings? Commands not being halted? Events not being halted? A combination of all of the above?

Please provide one script that reproduces one issue. If there are multiple issues, please provide one script per issue. I do not want to be adding/removing semicolons from different parts of a script in the hope that I can reproduce what I think you are seeing :-]

On further testing, the $$local_identifier failure issue seems related to an issue where $~local_identifier is always no-such-identifier, even when the local identifier is defined as a not-null string. With the above script loaded, type the command:

/double_dollar test event

It executes the alias twice, first within input where event=input, then again where event=$null as part of the editbox command. In both cases, $$event generates the no-such-identifier warning, even though it is defined within INPUT. The message above the error line falsely reports $event is $null within INPUT because that line is using single dollar for $~event and I can't find a local identifier where the local identifier has a string value and the $~ form is the same value.

$$event should generate the identifier warning error only for the 2nd execution that's outside the INPUT event, where $event doesn't exist as an identifier.

--

Now have 2 clients in a channel using the example code, and have one of them paste these 2 commands into #channel:

test chan
test nick

For the typist, 'test chan' and 'test nick' within ON INPUT both generate the identifier warning for $$chan and $$nick respectively

For the viewer, both commands within ON TEXT generates a /return and not an identifier warning, as if $chan and $nick exist but both have $null string value.

It's correct for the typist to get an identifier warning for $$nick since that local identifier isn't defined for the INPUT event.

Within INPUT, the typist should not get an identifier warning for $$chan unless typed somewhere like the status window or a query window where $chan isn't a valid identifier. Because $chan is defined in a #channel editbox, $$chan should not /return or generate a warning.

For the viewer, neither of these commands should generate that /return and should continue to echoing the red message last line of the alias. $chan and $nick are both defined in ON TEXT, so $$chan and $$nick should both be the same values as $chan and $nick. ON TEXT should trigger the /return for $$chan only within the viewer's query window event where $chan is $null.

After enabling the 2nd alias with: //enable #double_dollar_chan | saveini

... the identifier warning does not get triggered for either the typist or viewer, and the typist correctly has the fake_chan value returned if they type a command in the status window or a query window. However for both typist's INPUT and viewer's TEXT events within a channel window, $$chan is incorrectly seeing 'alias chan' instead of using the actual value of $chan. Within TEXT, the presence of 'alias chan' within the viewer's script changes the behavior of $$chan from being an internal identifier defined as $null generating /return instead of an identifier warning, into now being not an internal identifier and instead allowing the viewer's client to see 'alias chan'.

I appreciate the script but it's still too complicated. There is so much going on in the script that it would be impossible for me to narrow it down to one specific issue.

I think you may be expecting too much of $$identifier. All $$identifier does is stop a command from being executed if $$identifier is empty. It has no idea about events, other scripts, return/halt, etc.

If what you are saying is that an empty $$identifier is not stopping a command from being executed, or is incorrectly stopping a command, please show me the simplest possible script that reproduces this.

That's indeed what we expect as well (except that I would not say 'command').
So, inside the on input event, if the active window is a channel window, then $chan is filled with the value of that channel. $$chan should return that value as well but it's not. Instead, it's looking for custom aliases named 'chan' and if one is found, that alias is called, if no alias is found, you get the warning (if you have that option set only, btw) about $$chan not existing, rather than $chan not existing, that's totally incorrect then, $$chan should return the correct value here, and it should halt the script if the on input is triggered when the active window is not a channel.

I have found a bug, probably as old as $$ itself, where event-specific identifiers are not being seen if they are $$ prefixed. Is this the issue you are referring to? If I remember correctly, the $$ prefix was originally added for use in aliases and popup menus, so it has never worked in remote events. But it should be possible to extend it to do so, unless anyone can see any side-effects that could affect existing scripts.

As for $chan: unlike most identifiers, it has special-case handling in several places that depends on context. That is because it was designed to be valid in both events and non-events. Outside of events, it represents the active channel window. Inside events, it represents the channel name for a channel-related server message (ctcp, action, join, etc). If it is any other event, it returns an empty string. It really should have been given a different name inside events. This is made more complicated because of the discussions we have had in the past about the value of $active inside events, where it defaults to the status window for most events. As discussed before, changing this would break scripts. And without changing this, there is no way to set $chan correctly.

On the other hand, on INPUT is one identifer where setting $chan would be possible because it is one of the special cases when it comes to setting $active in the event. So if this issue is about $chan inside on INPUT, it could be fixed, but I am not sure it should be because $chan inside events was not intended for that.

Note: I saw your reply after I had this written up, so I did a quick search/replace of 'chan' for 'event', because I'm not seeing $chan behaving any different than other local identifiers in contexts where $chan is not null.

I'm not talking about changing the behavior of $chan itself, but rather supporting the $$ and $~ forms for local identifiers, not just global identifiers. You're saying that $$ doesn't work in normal remote scripts, but I've never seen $$sha1(abc) behaving any differently in a remote script, such as being treated as an identifier warning - nor have I seen $$left(%no_such_var,99) not halting the script (or doing a /return inside an :EVENT:) due to the $left returning $null. Remote scripts have always been able to use $$1 to abort them if $$1 is $null.

--



And my script was demonstrating that in situations where a local identifier like $event or $chan or $nick was not-null:

* within the INPUT event in a channel editbox, $$chan and $$event were triggering the identifier warning as if $chan and $event didn't exist, when that wasn't true.

* within the TEXT event in a channel, $~event $~chan and $~nick were behaving as if they were identifiers having the $null string when they were not null. Also within the TEXT event, $$event $$chan and $$nick were halting due to being $null, even though $event and $chan and $nick were not null.

* also within the TEXT event, the presence of a custom alias named 'chan' was able to be seen by $~chan even though that local identifier does exist, and even though the $~identifier form should always ignore the presence of custom aliases.



No, i'm saying the complete opposite. $$identifier and $~identifier are incorrectly being set as null. Sometimes $$identifier is incorrectly being empty, causing the event handler to /return instead of continuing to execute the next line. Or, sometimes $$identifier is sometimes incorrectly generating an identifier warning as if $identifier doesn't exist at all, $null or otherwise.

1. Have another client type message into channel "test event". It behaves as if $~event and $$event are both $null.



Correct behavior should be that, when $event is not null, $~event and $$event should be the same as $event.

2. Type "test event" in any channel window. Within the INPUT event, $~event behaves as if $event is null, and $$event falsely generates an identifier warning as if $event doesn't exist. Same thing would happen for $~event or $$event.



Correct behavior should be that, when $event is not null, $~event and $$event should be the same as $event.

As I understand it, even in INPUT event in the status window, $chan should be an existing identifier with the $null string value, rather than a no-such-identifier as the INPUT identifier warning for $$chan implies.

3. After creating the following custom alias, $$event within ON TEXT in example #1 above changes from being an existing built-in identifier with a $null value into not being a built-in identifier at all. Instead, the presence of 'alias event' returns that value for $$event instead of returning null.



Edit: I may have mis-understood 'remote events' as meaning remote scripts. $$identifier has worked in :EVENT: handlers, but not for the local identifiers, but only for the global identifiers with the possible exception of the $chan hybrid.

Edit#2: I should have said that it was $$event changing from $null to seeing the custom alias, not $~event

Yes, event-specific identifiers is what we call local identifiers. As usual, it's possible to create a script that will break if $$ is modified, but the point is moot as that script would not be making any sense, I don't see the point in not fixing it.


While I understand that $chan is not set 'by' the on input event, but that it is 'by' the on text event (if applicable), I don't understand why "there is no way to set $chan correctly".

$chan is actually set correctly as far as the scripter is concerned, even if the name should have been different inside events, practically speaking the functionality is there.

What would having $chan being set by the on input event rather than because it represents the active channel window change compared to the current behavior? As far as I know it would not change anything, so I don't understand why $chan needs to change inside on input.

I'm sorry, I've read the part about $chan carefully and I do not understand why either the difference in 'setting' of $chan (set by the event or not) or the fact that irc events trigger with the status window as the active window for the event would play a role in how $$ can be improved to work with $chan. Once you fix $$ to work inside remote event, why wouldn't $$chan works inside on text or on input?

As long as no one can see an issue with backwards compatibility, the change will be in the next beta.


That's because you can't see the code the I'm seeing. It's my fault for over-explaining the code. Every once in a while, I like to share how the code works but it can be difficult to explain it. Let's just go with the change and see how things turn out.

I notice that you have made several references to $~ in your posts. This is used internally by the script parser and changes how a parameter is parsed in several ways. It should never be used in a script.

Regarding the rest of your post: I will be changing $$ so that it is processed in events. However, it is difficult to predict what the side-effects will be. $$ is an ancient prefix and the scripting language has evolved around it. If the change has negative side-effects, I will be reverting the change.

Just send it over so I can understand

Well we're grateful for getting explanations about how the code works since we usually come up with our own theories.
And this time is no exception, I feel like $$ is using a different routine to get the value of $identifier and with $chan being context dependant, it looks like $$ isn't having access to that context, which feels like it could be fixed.

We're very curious about $~, can you tell us what's the purpose of $~ internally? In which way is it changing the parsing of parameters, is it changing the parsing of parameter of the identifier?

Raccoon approves these changes. The proposed context seems to be the intuitive one. I think it was just never discovered because the $$ prefix isn't that widely used outside of one-line aliases and popups, except by some of us more advanced folk who would use it creatively for halting events, timers and callbacks for brevity.

But I support breaking backward compatibility when it promotes intuitive function, but it also encourages script updates and new community engagement. Most old and ancient scripts are pretty terrible anyway.