[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31104: 26.1; Undo limits
From: |
Stefan Kangas |
Subject: |
bug#31104: 26.1; Undo limits |
Date: |
Thu, 8 Aug 2019 14:26:47 +0200 |
Noam Postavsky <npostavs@gmail.com> writes:
> tags 31104 + wontfix
> quit
>
> Nick Helm <nick@tenpoint.co.nz> writes:
>
>> I keep bumping into Emacs's undo limits.
>
>> I know I can change the undo-*-limit variables to improve this
>> situation, but I don't think users should have to do this.
>>
>> Bit of further navel-gazing...
>>
>> Simply raising the default undo limits (or advising users to raise it in
>> their config) has problems too. Given a large enough edit, I've had the
>> same issue reappear. I find it difficult to work out how an undo limit
>> set in bytes translates into real-world editing behaviour.
>>
>> Perhaps a byte size is not the best way to specify undo limits, at least
>> not for user-facing settings? Instead, could Emacs guarantee a minimum
>> number of undo steps, say the 20 most recent, regardless of the amount
>> of data it consumes?
>
> I don't see how Emacs can do better here (except maybe we should
> consider just bumping up the default limits so that users are less
> likely to hit them), since a single command can take an arbitrary amount
> of data, and there is only a finite amount of memory.
The last change here was in:
commit 2159bd065212117a6aff538a69d5ac1864dcd134
Author: Chong Yidong <cyd@stupidchicken.com>
Date: Tue Jan 27 20:57:47 2009 +0000
(undo_limit, undo_strong_limit, Vundo_outer_limit): Quadruple undo
limits (bug#1501).
Since then, the current defaults are:
undo-limit 80000
undo-strong-limit 120000
undo-outer-limit 12000000
Maybe it's time to quadruple (or double) these numbers again?
Is there any reason not to do that for 27.1?
Best regards,
Stefan Kangas
- bug#31104: 26.1; Undo limits,
Stefan Kangas <=