GNU bug report logs - #31211
27.0.50; Pruning of command-history in command-execute is off by one

Previous Next

Full log

Message #21 received at 31211 <at> debbugs.gnu.org (full text, mbox):

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31211 <at> debbugs.gnu.org
Subject: Re: bug#31211: 27.0.50;
 Pruning of command-history in command-execute is off by one
Date: Sun, 29 Apr 2018 20:54:56 +0100

[0001-Fix-off-by-one-history-pruning-bug-31211.patch (text/x-diff, attachment)]

[0002-Minor-simple.el-simplifications.patch (text/x-diff, attachment)]

[Message part 3 (text/plain, inline)]

Noam Postavsky <npostavs <at> gmail.com> writes:

> You need to change call-interactively in callint.c in order to fix the
> test case from your OP though, right?  This part:
>
>       /* Don't keep command history around forever.  */
>       if (INTEGERP (Vhistory_length) && XINT (Vhistory_length) > 0)
>         {
>           Lisp_Object teml = Fnthcdr (Vhistory_length, Vcommand_history);
>           if (CONSP (teml))
>             XSETCDR (teml, Qnil);
>         }

Whoops, right you are; I jumped the gun on that one.

Is there any reason why we can't use add-to-history in places like
Fcall_interactively in src/callint.c and read_minibuf in src/minibuf.c,
rather than duplicating its logic and falling into off-by-one traps?

I attach a patch which delegates to add-to-history in various such
places, on the assumption this is kosher.  Please let me know whether
something like this would be acceptable and/or how it can made so. 

The second attachment comprises the same minor lisp/simple.el touch-ups
as in my last email.

Thanks,

-- 
Basil

Previous Next

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