From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Noam Postavsky Newsgroups: gmane.emacs.bugs Subject: bug#31104: 26.1; Undo limits Date: Wed, 17 Apr 2019 19:56:32 -0400 Message-ID: <87ftqgw5hr.fsf@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="203087"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) Cc: 31104@debbugs.gnu.org To: Nick Helm Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Apr 18 01:57:19 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hGuQW-000qhr-9f for geb-bug-gnu-emacs@m.gmane.org; Thu, 18 Apr 2019 01:57:16 +0200 Original-Received: from localhost ([127.0.0.1]:33107 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGuQV-0002TF-70 for geb-bug-gnu-emacs@m.gmane.org; Wed, 17 Apr 2019 19:57:15 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hGuQK-0002T7-Jv for bug-gnu-emacs@gnu.org; Wed, 17 Apr 2019 19:57:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hGuQI-0000RF-VD for bug-gnu-emacs@gnu.org; Wed, 17 Apr 2019 19:57:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55743) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hGuQI-0000Qh-IW for bug-gnu-emacs@gnu.org; Wed, 17 Apr 2019 19:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hGuQI-0002E9-Ga for bug-gnu-emacs@gnu.org; Wed, 17 Apr 2019 19:57:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 17 Apr 2019 23:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 31104 X-GNU-PR-Package: emacs Original-Received: via spool by 31104-submit@debbugs.gnu.org id=B31104.15555454028531 (code B ref 31104); Wed, 17 Apr 2019 23:57:02 +0000 Original-Received: (at 31104) by debbugs.gnu.org; 17 Apr 2019 23:56:42 +0000 Original-Received: from localhost ([127.0.0.1]:41054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hGuPy-0002DS-CS for submit@debbugs.gnu.org; Wed, 17 Apr 2019 19:56:42 -0400 Original-Received: from mail-qk1-f176.google.com ([209.85.222.176]:41955) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hGuPv-0002D8-JH; Wed, 17 Apr 2019 19:56:40 -0400 Original-Received: by mail-qk1-f176.google.com with SMTP id p185so45198qkb.8; Wed, 17 Apr 2019 16:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=PPdlKS9Xpu5RzCSfZeUnXIYESGlVxjZIArIb/+z7lrw=; b=IWqYW9fhmszD4WCZtcIpMPnNTvOj/RDuvxYSU9UdcY6Dq2vVhUZxt0b+TAzKHdzfd3 O958pggyry/RwjmjLbF/tfnzdG5clbzUArV1duxTlwo7k0GFvv+CDuf14dWZjj/Og44t +8mxOuPMWQlM0xzAqL4gpsFzj3yl62RMab5O6wGcMXHA11OgVR4Z5jCJ26Vu6m36Jxmz +LuCMbhOuJWryGoa43xA6XYijH/MLvHMDR/Ne/9gR5iyXoYiBVdK0nzD44lQfmFHSLit jwSKRDHR/Xgbv1OYz0zegoQLfLRVw9kAE1bHdnFaOdYxMZO0IDQQyExlCh54EjgS4eYr QwFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=PPdlKS9Xpu5RzCSfZeUnXIYESGlVxjZIArIb/+z7lrw=; b=ZI17ZseBSaIbL8xWm2G/Svo0TBlNuKKvYQb+zKivL/d2C+0pz/9283DMBz4eG5KQ0I tZEvap0zu4WJet8umCG4WcX9FDqZ9gkoNIevTS6uRjS7wCWOkG+IfjIYxqJkmIEQwJYQ AlZ+/cjTEGYMvRpycnI5SVyH2345GoovE+GTB8CxpTNGsW7SAraHRmQfiITnyHm0D6Ux eM2YZQfrPdbQAAF/AwUVJ5tqbuB+Pq2BA6Hsxnb3Q+kQ+Af7c45/fjoxy8ozCRAUSNr/ zsAlxLIaS/L+dUE2TdXNId7oG686rHhtA0JPoQZASuFCZXIzdG+1ikWL0VAm6sfhOOIQ BdpQ== X-Gm-Message-State: APjAAAUYEiwyumzWZEixUFQ5WP5PoWdfyRdJnetcsbzwJi89VyNSH4Sl v+ZdKzcDc3Yo/fWzsLdzZ9g9JpZP X-Google-Smtp-Source: APXvYqwvp15RiEWTAveQhsbAVlfkYJemFvWY0+f8Bs6r/qR5XiH6VtfjTgs+dvbwZFldbcXFzTGnOA== X-Received: by 2002:a37:4ad4:: with SMTP id x203mr71890926qka.21.1555545393763; Wed, 17 Apr 2019 16:56:33 -0700 (PDT) Original-Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.googlemail.com with ESMTPSA id h13sm114769qkj.96.2019.04.17.16.56.32 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 17 Apr 2019 16:56:32 -0700 (PDT) In-Reply-To: (Nick Helm's message of "Mon, 09 Apr 2018 11:15:12 +1200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:157787 Archived-At: tags 31104 + wontfix quit Nick Helm 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.