on *:input:*: {
var %reg = $+(/,^\Q,$readini($mircini,text,commandchar),\E+,(?:(?i)window)) -\w*c\w* (@[^\40]+)/
if ($regex($1-,%reg)) .signal wclose $regml(1)
}
on *:signal:wclose: echo -ag closing window $1 via editboxWould take into account:
- possibly different command char
- possible repetitions of command char (///window -c)
- /window -c vs. /window -C (yes, case is important here
)
- /window -ac (etc.)
And yet you'll miss (examples only):
- /close -@
- //somethingelse | window -c @abc | /window -c @xyz
- //window -c $+(@,$something)
- ...
The code is meant only to show that building your own "parser" to "grab" certain editbox commands isn't that easy (manipulating the /window command will remove some of, but not all the possible pitfalls). For this particular issue, I don't see any use in the attempt at all:
99.99% of custom windows are closed by a user (click on "x", shift-click in treebar, ...) or a script. And, as Wims pointed out, there's no need for events if a script closes the window, because the script "knows" what else to do anyway.
Is there a need to reconfigure/extend the close event, just in case someone prefers to use *script* commands in the editbox? Imho: nope - If you want to close-with-additional-commands via editbox: enter a custom alias that does the trick.
