bug#31658: 25.2; Number of changes undone should be controlled by a variable

bug#31658: 25.2; Number of changes undone should be controlled by a variable

[Ruy Exel]

After I updated Emacs to the latest version I noticed that the behavior
of the undo command has changed in the sense that a single invocation of
undo effectively undoes many more recent changes than it used to and I
often find myself having to re-do the changes and reentering the whole
information again rather than taking advantage of the undo command.

After a little fiddling I realized that this feature is controlled by
the function 'undo-auto-amalgamate' which contains the line

  (< last-amalgamating-count 20)

apparently bundling up to 20 recent changes for the next invocation of
undo.

My solution was simply to edit that function, replacing 20 by zero, and
the old behavior, which I am used to, was restored.

The purpose of this bug-report/feature-request is to suggest that
instead of hard coding a fixed number, such as 20, the number of changes
bundled together should be determined by a variable which the user could
customize if desired.

In GNU Emacs 25.2.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.24.23)
 of 2017-12-09 built on tictoc
Windowing system distributor 'The X.Org Foundation', version 11.0.11501000
System Description:    Ubuntu 14.04.5 LTS

bug#31658: 25.2; Number of changes undone should be controlled by a variable

[Lars Ingebrigtsen]

Ruy Exel <ruyexel@gmail.com> writes:

> After I updated Emacs to the latest version I noticed that the behavior
> of the undo command has changed in the sense that a single invocation of
> undo effectively undoes many more recent changes than it used to and I
> often find myself having to re-do the changes and reentering the whole
> information again rather than taking advantage of the undo command.
>
> After a little fiddling I realized that this feature is controlled by
> the function 'undo-auto-amalgamate' which contains the line
>
>   (< last-amalgamating-count 20)
>
> apparently bundling up to 20 recent changes for the next invocation of
> undo.
>
> My solution was simply to edit that function, replacing 20 by zero, and
> the old behavior, which I am used to, was restored.
>
> The purpose of this bug-report/feature-request is to suggest that
> instead of hard coding a fixed number, such as 20, the number of changes
> bundled together should be determined by a variable which the user could
> customize if desired.

I think that sounds like a reasonable (and useful) request.  Does
anybody object to adding such a defcustom?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#31658: 25.2; Number of changes undone should be controlled by a variable

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 09 Oct 2019 23:58:55 +0200
> Cc: 31658@debbugs.gnu.org
> 
> > The purpose of this bug-report/feature-request is to suggest that
> > instead of hard coding a fixed number, such as 20, the number of changes
> > bundled together should be determined by a variable which the user could
> > customize if desired.
> 
> I think that sounds like a reasonable (and useful) request.  Does
> anybody object to adding such a defcustom?

Let's begin with defvar, please.  I'm not sure I like exposing the
bowels of undo to users, there be dragons.

bug#31658: 25.2; Number of changes undone should be controlled by a variable

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think that sounds like a reasonable (and useful) request.  Does
>> anybody object to adding such a defcustom?
>
> Let's begin with defvar, please.  I'm not sure I like exposing the
> bowels of undo to users, there be dragons.

OK; done.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no