GNU bug report logs - #49536
28.0.50; Confusing dolist-with-progress-reporter behaviour

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 49536 <at> debbugs.gnu.org
Subject: bug#49536: 28.0.50; Confusing dolist-with-progress-reporter behaviour
Date: Tue, 13 Jul 2021 03:18:20 +0200

Philip Kaludercic <philipk <at> posteo.net> writes:

> I am not sure if this is intentional

Looks more like a typical problem with counting...

> but in case it is no, the following patch should fix it:
>
> From f7da2585886bd4fd795713a605ff6bd17a4c337a Mon Sep 17 00:00:00 2001
> From: Philip Kaludercic <philipk <at> posteo.net>
> Date: Mon, 12 Jul 2021 17:26:43 +0200
> Subject: [PATCH] Fix dolist-with-progress-reporter behaviour
>
> * subr.el (dolist-with-progress-reporter): Use the length of list
>   argument as maximal value the reporter with reach
> ---
>  lisp/subr.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index e49c277335..20f40be40d 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -5880,7 +5880,7 @@ dolist-with-progress-reporter
>             (,count 0)
>             (,list ,(cadr spec)))
>         (when (stringp ,prep)
> -         (setq ,prep (make-progress-reporter ,prep 0 (1- (length ,list)))))
> +         (setq ,prep (make-progress-reporter ,prep 0 (length ,list))))

I think this patch is correct: 0 stands for 0% finished, and we have
finished after processing 100% of the list's elements, whose number is
(length list).  With other words: we have (+ 1 (length list)) steps: one
after having processed each element, plus the one before having started.

Are you able to install the patch, or does someone else have to do it?


Thanks,

Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.