Simply because you know a way to solve such a scenario, doesn't mean that is enough. By which, I only mean to point out that this IS a consistency request, and not a "broke, so fix it".
Need I quote the help file?:
on 1:CLOSE:@:/echo -s Just closed $target custom window
That line has been there for years.
That event is going to be triggered when $target is closed.
The only difference between /close and that X is the involvement of GUI activity. The [X] is, effectively, calling an internal variety of /close... I wouldn't even be surprised if its roughly the same chunk of code.
I know a current scripted sollution to this. One does something like (off my head-top):
alias window.close {
if ($window(@window)) { close -@ @window }
unset %window.*
}
on *:close:@window: {
window.close
}
And it's done.
I'd be interested to know what very good reasons you reference for NOT having ON CLOSE do what its name clearly suggests it does, though. I see not one good reason that /close should be named /close and not trigger the ON CLOSE event.
Script interpreters change all the time, and I see this change being not only minor (to function), but logical.
An -x exception switch would also be logical.
