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.

--

Originally Posted By: Khaled
$$identifier does is stop a command from being executed if $$identifier is empty. It has no idea about events, other scripts, return/halt, etc.


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.

Quote:
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.


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.

Code:
ON *:TEXT:test *:#:{
  if ($2 == event) echo # $~event should not be null if message is in a #channel because $ $+ event is: $event
  if ($2 == event) echo # $$event prevents this line from showing even though $event is not null
  echo $target this line should not be prevented from echoing
}


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.

Code:
ON *:INPUT:*:{
  if (#* !iswm $active) return
  if ($2 == event)  echo $target $~event should not be null if input is in a #channel because $ $+ event is: $event
  if ($2 == event)  echo $target $$event prevents this line from showing even though $event is not null
  echo $target this line should not be prevented from echoing if a #channel editbox
}


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.

Code:
alias event return fake-event


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

Last edited by maroon; 24/05/19 10:04 PM.