Note - The original post incorrectly diagnosed this as a terminal issue. Further testing showed this not to be the case - the issue is a race condition in the alert package. I've crossed-out the now irrelevent bits of the post, and I've provided a partial answer in the update below. I intend to provide a full programatical solution and will answer the question properly once I've done this. The workaround below works fine in mintty and iTerm, and I'm sure it will work fine in other terminal emulators too.
Using the alert pacakge I've configured weechat package to display the start of a message in the mini-buffer and also change the colour of the mode-line for 10 seconds.
'(alert-fade-time 10)
'(alert-user-configuration
(quote
((((:category . "chat"))
message
((:continue . t)))
(((:category . "chat"))
mode-line
((:continue . t))))))
I'm constrained to using terminal emacs over ssh.
This isn't a problem in Konsole on Kubuntu 17.10 that faithfully renders the mode-line to green and then back to it's initial state.
However other terminal consoles I try have all resulted in the mode-line transitioning to green, and then staying like that forever.
Windows (mintty, putty, conemu, or bitvise) and MacOS (terminal or iTerm) all display this behaviour.
For this to be useful to me I have to get it working at least in a Windows environment.
Can anyone either:
a) Recommend a Windows terminal emulator which handles this?
and/or
b) Recommend a way to programatically force the mode-line to refresh in a way that works well from the terminal?
UPDATE
This may be a more interesting problem then I had first thought.
The issue is not perhaps not terminal rendering. The code for the alert library either has a race condition (I think), or my definition of the notification above, allows a race condition and needs to be changed.
For now I can at least solve the race condition issue, somewhat manually, by clearing any stagnant modification of the mode-line myself using the below function. It might be able to pull the original model line from elsewhere, rather than having the colours hardcoded - in the example below it resets to the default Prelude scheme.
The proper solution is likely to be to add a locking mechanism to the alerts library so that duplicate alerts cannot run in tandem. A fancy solution might even queue alerts. I will have a look at this when I have a bit more time.
;; There is a race condition possible with alerts
;; flashing the mode-line.
;; If a second alert arrives before the first clears
;; It will copy the first alert's changed mode-line
;; into alert-saved-mode-line-face.
;; With both the mode-line and saved mode line
;; being identical, we will never restore
;; the original model line.
(defun clear-mode-line ()
"Revert the mode-line colour scheme"
(interactive)
(set-face-background 'mode-line "#2B2B2B")
(set-face-foreground 'mode-line "#8FB28F")
;; This should be taken care of next time
;; we call alert-mode-line-notify().
;; But for tidiness we set it back to the default mode line
(copy-face 'mode-line 'alert-saved-mode-line-face))
(key-chord-define-global "££" 'clear-mode-line)
