Mute your speakers at the start of the macro, then unmute as part of the Q-key processing?
That's the easiest way, but perhaps you like to listen to music while triaging your email...
As I understand it (and I'd love to be told different!), when an app's window is frontmost KM only "swallows" hotkey triggers -- everything else is passed on to the application, even if (as here) a KM macro is "using" it first. So the System beep is Mail.app informing you that the esc key is not a valid keystroke in the current situation.
The only way I know round that would be to have it be a hotkey trigger, so KM swallowed it whole. That could be done, but introduces more complexity (that's the problem with single-key hotkeys) -- you'd need another Macro Group for "temporary" Mail macros which contained a macro that handles your "key interrupts", one hotkey trigger per action you want to take. Your "main" macro would then simply enable the "temporary" Macro Group, your q action would disable it.
It also reduces complexity -- there's no need for a loop if everything's based on hotkeys! But I'm going to use one anyway, to flash a notification that the processing macro is enabled.
This is just another level in the "If/Else" construct:
if the key is ESC then
delete the email
open the next
else
if the key is k then
keep the email
open the next
else
end the macros
end if
end if
You could probably also do this with a "Switch/Case" action based on the Trigger Clipboard value, and that would be clearer if you started adding more key, but I've stuck with the "If Then Else" actions so you can see the evolution of the macro.
There's also the problem of "next email". By default, where the message list is sorted with newest at the top, "next" is the "next one down" -- so that's the way I've set this up.
Mail Processing Controller.kmmacros (3.1 KB)
Mail Processor.kmmacros (14.9 KB)
I'm sure this could be done better, but hopefully it'll give you something to start from.