Subject: Re: bug#50176: [PATCH] 28.0.50; repeat-mode does not clear echo-area after timeout

From: Gabriel <[email-masked]>
Date: Tue, 24 Aug 2021 11:31:30 -0300

Juri Linkov <[email-masked]> writes:

>
> Thanks for the patch.  This is a known problem without a good solution.
> But your patch handles the case much better than before, so pushed now.

Thank you, Juri

Perhaps we could store in a defvar the last message echoed by
repeat-mode to make easier this check?

Today I caught a small problem with the patch I sent. The
'string-prefix-p' and 'string-match-p' handle nil inputs differently:

(string-prefix-p "Repeat with " nil) ;; returns nil
(string-match-p "Repeat with " nil)  ;; throws an error

The problem can be reproduced by writing some elisp code in *scratch*
buffer, putting the cursor in the function definition and invoking the
'other-window' with 'repeat-mode' using my original steps. The
'eldoc-mode' will echo the function name and '(current-message)' will
return nil.

A simple patch:

>From 4e67546e2a9a878418d9dd766d234699fd58da34 Mon Sep 17 00:00:00 2001
From: Gabriel do Nascimento Ribeiro <[email-masked]>
Date: Tue, 24 Aug 2021 11:23:49 -0300
Subject: [PATCH] Handle nil messages in repeat-echo-message.

* lisp/repeat.el (repeat-echo-message): Handle cases where
'current-message' is nil (bug#50176).
---
 lisp/repeat.el | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lisp/repeat.el b/lisp/repeat.el
index e3e7a7568e..3b30ba2a60 100644
--- a/lisp/repeat.el
+++ b/lisp/repeat.el
@@ -474,8 +474,9 @@ repeat-echo-message
         (if (current-message)
             (message "%s [%s]" (current-message) mess)
           (message mess)))
-    (when (string-match-p "Repeat with " (or (current-message) ""))
-      (message nil))))
+    (and (current-message)
+         (string-match-p "Repeat with " (current-message))
+         (message nil))))
 
 (defvar repeat-echo-mode-line-string
   (propertize "[Repeating...] " 'face 'mode-line-emphasis)
-- 
2.32.0

(The call to '(current-message)' does not seem to be expensive;
otherwise, we could store it into a variable to avoid duplicated calls)