GNU bug report logs - #31104
26.1; Undo limits

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 31104 in the body.
You can then email your comments to 31104 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Nick Helm <nick <at> tenpoint.co.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.1; Undo limits
Date: Mon, 09 Apr 2018 11:15:12 +1200

I keep bumping into Emacs's undo limits. 

The recipe below uses an org-table to illustrate the problem. That's
where I encounter it most often, but any command that changes a large
amount of text will do.

Emacs -Q
;make a tall org-table
  M-x org-mode
  "|Column One|Column Two|Column Three|" RET ;enter a table row
  C-p C-k C-k
  C-x ( C-y C-x )
  C-u 1000 C-x e
;delete a couple of columns
  C-a
  M-S-<left> ;delete Column One
  M-S-<left> ;delete Column Two
;undo both deletes
  C-/ ;Column Two reappears
  C-/ ; -> "No further undo information"

In this scenario, Emacs provides just one undo step and Column One is
lost for good. All previous undo information is also silently lost. This
can be troublesome if work is not saved. I expect Emacs to always
remember at least a handful my most recent changes if only to protect me
from bad keystrokes.

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? 



In GNU Emacs 26.1 (build 1, x86_64-apple-darwin17.5.0, NS appkit-1561.40 Version 10.13.4 (Build 17E199))
 of 2018-04-06 built on oberon.local
Windowing system distributor 'Apple', version 10.3.1561
Recent messages:
Opening nnimap server on Office365...
Opening connection to localhost via shell...
Opening connection to localhost...done
Opening nnimap server on Office365...done
Opening nntp server on Gmane...done
No new newsgroups
Checking new news...
Reading active file via nnnil...done
Reading active file via nndraft...done
Checking new news...done

Configured using:
 'configure --with-gnutls=no'

Configured features:
JPEG NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS THREADS LCMS2

Important settings:
  value of $LANG: en_NZ.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-undo-mode: t
  savehist-mode: t
  global-eldoc-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow gnus-cite sort mail-extr nnir emacsbug sendmail gnus-demon
nndraft nnmh cl-extra help-mode utf-7 network-stream nsm auth-source
cl-seq eieio eieio-core cl-macs eieio-loaddefs starttls nnfolder nnnil
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art
mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp gnus-cache
gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap nnmail
mail-source tls gnutls utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range message rmc puny seq byte-opt bytecomp byte-compile cconv
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils
mailheader gnus-win gnus nnheader gnus-util rmail rmail-loaddefs rfc2047
rfc2045 ietf-drums mail-utils mm-util mail-prsvr wid-edit time dired-x
easymenu dired dired-loaddefs pcase savehist easy-mmode iso-transl
edmacro kmacro cl-loaddefs cl-lib gv plain-theme time-date tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/ns-win
ns-win ucs-normalize mule-util term/common-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list replace newcomment text-mode
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow
isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core term/tty-colors frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote kqueue cocoa ns lcms2 multi-tty
make-network-process emacs)

Memory information:
((conses 16 282148 12081)
 (symbols 48 28645 1)
 (miscs 40 58 261)
 (strings 32 54384 1881)
 (string-bytes 1 1609360)
 (vectors 16 43789)
 (vector-slots 8 823332 18900)
 (floats 8 217 315)
 (intervals 56 250 0)
 (buffers 992 17))

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Nick Helm <nick <at> tenpoint.co.nz>
Cc: 31104 <at> debbugs.gnu.org
Subject: Re: bug#31104: 26.1; Undo limits
Date: Wed, 17 Apr 2019 19:56:32 -0400

tags 31104 + wontfix
quit

Nick Helm <nick <at> 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.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 31104 <at> debbugs.gnu.org, Nick Helm <nick <at> tenpoint.co.nz>
Subject: Re: bug#31104: 26.1; Undo limits
Date: Thu, 8 Aug 2019 14:26:47 +0200

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

> tags 31104 + wontfix
> quit
>
> Nick Helm <nick <at> 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 <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 31104 <at> debbugs.gnu.org, nick <at> tenpoint.co.nz, npostavs <at> gmail.com
Subject: Re: bug#31104: 26.1; Undo limits
Date: Sat, 10 Aug 2019 12:25:04 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Thu, 8 Aug 2019 14:26:47 +0200
> Cc: 31104 <at> debbugs.gnu.org, Nick Helm <nick <at> tenpoint.co.nz>
> 
> The last change here was in:
> 
> commit 2159bd065212117a6aff538a69d5ac1864dcd134
> Author: Chong Yidong <cyd <at> 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?

I'm okay with doubling the limits on the master branch.

Thanks.

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 31104 <at> debbugs.gnu.org, Nick Helm <nick <at> tenpoint.co.nz>,
 Noam Postavsky <npostavs <at> gmail.com>
Subject: Re: bug#31104: 26.1; Undo limits
Date: Sat, 10 Aug 2019 20:29:48 +0200

tags 31104 fixed
close 31104 27.1
quit

Eli Zaretskii <eliz <at> gnu.org> writes:

> > 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?
>
> I'm okay with doubling the limits on the master branch.

Thanks for that.

Now fixed on master in commit 9466372.  I don't think there's anything
else to do here, so I'm also closing this bug.

Best regards,
Stefan Kangas

Previous Next

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