I think this feature is useful and would help alot. Which we can handle the result and get out from the -k property. The examples tells alot..

/filter -gff [+f flag] file nul .+
The flag feature is optional.

on *:filter:{
if $fflag == test {
if $fevent == filter {
echo -a $fresult which is it the $1 in the -k property
}
elseif $fevent == filtered {
echo -a finished filtering - $filtered
}
}
}

This sounds like a good idea to me. I think it might be better (required) if there were a 'name' given in the filter command which corresponds to the name in the on FILTER event. The events could allow wildcards to match multiple names (like socket events do). There could also be a separate event for filter done (if this is even necessary). Sometimes parameters would need to be passed to the event, so a 'mark' command like sockmark could be used instead of global variables.

/filtermark NAME $nick $chan $etc
/filter -ff NAME infile outfile search

on *:FILTER:NAME:{
;The result should be in $1- like other events
echo -a $fname result: $1-
echo -a Filtermarks: $fmark(NAME,1-)
}

on*:FILTERDONE:NAME*:{
echo -a Finished Filtering $fname
;Filtermarks are destroyed in the FILTERDONE event
echo -a Filtermarks: $fmark(NAME,1-)
}

-genius_at_work

Since events dont happen untill the currently running script completes, these events would no occur straight away, should they occur straight away, I see nothing they do here, that would lead me to believe it couldnt be done using a filter -k and a command following it (to do the $fevent == filtered section), should there be a large number of filters to do in your script, and thus reproduction of the same following command over and over, then filter and following command could be grouped into an alias and called from the script.

alias filter_flag {
filter $1-
if ($filtered) { echo -a finished filtering - $filtered }
:error
}

your script contains the commands such as filter_flag -fk file.txt somealiasname *fred*

* please note i havent tested any of that, but i dont see a logical problem.

on SIGNAL events can trigger in the middle of a routine, if that routine calls /signal -n. So I can't think of anything that a combination of signals and /filter -k cannot do but on FILTER could. Signals were added so that you can make your own events and this is exactly the type of event that should be left to signals imo.

Agreed, i knew of signals tripping imediately, i just didnt want to confuse my point by saying since i dont even see the need for an event (On SIGNAL or ON FILTER).

I have actually asked this before, and while answered, i didnt really see a valid purpose to them, What is the point of doing a signal event?
The only practicle use I can see for it is if you are trying to write completely compartmentalised code, that triggers events and IF the script files that react to that event are loaded then and only then well they trigger. (of course an event does have the advantage that it might trip off in 3 sepearte script files, but i done really see the point to that in ON FILTER, like when you ever going to Filter something and want multiple scripts going off dependent ofn your results..... hmmm now that i say that i can start to think of abstarct ideas where that might be used.

Still a ON SIGNAL would be fine for it.

Yeah the main purpose of signals is modularity, especially the fact that different scripters can write modules for a 'core' script that includes a predefined set of /signal commands.