From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 08 19:15:41 2018 Received: (at submit) by debbugs.gnu.org; 8 Apr 2018 23:15:41 +0000 Received: from localhost ([127.0.0.1]:42930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f5JXA-0006OF-VE for submit@debbugs.gnu.org; Sun, 08 Apr 2018 19:15:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:49390) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f5JX7-0006O1-Rg for submit@debbugs.gnu.org; Sun, 08 Apr 2018 19:15:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f5JX1-0000g2-1j for submit@debbugs.gnu.org; Sun, 08 Apr 2018 19:15:32 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: *** X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_50, RECEIVED_FROM_WINDOWS_HOST,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:55507) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f5JX0-0000fw-UA for submit@debbugs.gnu.org; Sun, 08 Apr 2018 19:15:30 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40340) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f5JWz-0001hq-Ch for bug-gnu-emacs@gnu.org; Sun, 08 Apr 2018 19:15:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f5JWu-0000ee-DP for bug-gnu-emacs@gnu.org; Sun, 08 Apr 2018 19:15:29 -0400 Received: from mail-sy3aus01on0105.outbound.protection.outlook.com ([104.47.117.105]:32256 helo=AUS01-SY3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1f5JWt-0000ck-CH for bug-gnu-emacs@gnu.org; Sun, 08 Apr 2018 19:15:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenpointcomms.onmicrosoft.com; s=selector1-tenpoint-co-nz; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6DQhLjvNCbIFRmXifylwWaNXrHBMBpqjZ5/eteB06nw=; b=hu1pnPTP3N7w7uHOU0qC5JAljDCfqFSYysFWbYICvE7te9/VdXgvmgpP+9puug7JdJKHwnB/e426ZHdFB9fJJC4EK/1FYSdw17p1dBNZ+CjJGTlePfAP6lCsScrN22mo6swHoRtpMckJBV4AFLLcFoZilxjMPz6wclJ8kZK6CHc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=nick@tenpoint.co.nz; Received: from oberon.local (125.239.174.80) by ME2PR01MB2900.ausprd01.prod.outlook.com (2603:10c6:201:22::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.653.12; Sun, 8 Apr 2018 23:15:15 +0000 From: Nick Helm To: bug-gnu-emacs@gnu.org Subject: 26.1; Undo limits Date: Mon, 09 Apr 2018 11:15:12 +1200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [125.239.174.80] X-ClientProxiedBy: SY3PR01CA0118.ausprd01.prod.outlook.com (2603:10c6:0:1a::27) To ME2PR01MB2900.ausprd01.prod.outlook.com (2603:10c6:201:22::17) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3a254b11-14f0-403b-97fb-08d59da69695 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(2017052603328)(7153060)(7193020); SRVR:ME2PR01MB2900; X-Microsoft-Exchange-Diagnostics: 1; ME2PR01MB2900; 3:tXKGnVatn5YTbbOshgAzdsdYWzxG/NjUrFKcj/6h5PCguOKWtjt3UPnN+a10MhY921c0ebZFdpw6pEYARw1ciBQZdViv7Ja9LzixeQpdMHBNXlGc0Di1OSduSVwUhRtE3i8lR2AEFz0szmRjJToG1u0KPnqkD9sfekGf7WN5HZBWj68h8U1xD6v4JM7Uyl7v0bkYSruFauIv947J3UJYH1+y0Ueq6T1BplrTJ+OSzpxvv0mjwMPPFNNMWpoD0c0z; 25:qhw2yaGSsRnhH3r3WV6HdQMFXeNqxQko8hvHaVFweuqcrik3KaHLfWYxPIOhLnTos0KPh8hnN22tj20e+Ko3/Yig8I156CINg1qLo9XAijNqz2EuTLSmhnnEiPF3hUku+RMbOXLcU1gUBDQlAthI8ab4eAbBY+Cdn5E2+m4qAAgKlZ8JUdRNyFb25EvcMtG0l+e9e+7v8SlQrh+gZQnxC1Up5v/JLWt17GQccrwPSsWBLsFqrdAg+wcoR/X4n4RfTUv7yqo06T9Q4ERoAbDhKlW5oyZI8pH+dbocHV6V6w471o6RjLgax9K9+SY7w9jALxU/UQmPS2IkTjHPhiPenA==; 31:7bSBW+bPJKGHITdUqcisImYwIWHpMDBAy3R0c08kJ+LKGdOBEUsijk7qltSGAsI/YVXIu5cIF5rq2YWQc0BrUEw2E1wd9yZ0BGYX1bZ0IJ6Gg33Bu00CVmlXuSq06LwU4n3tcn/DojQCTdKR33yZMaa13hFTTPXyOJ53GfvV2JdxI0dztcy2ic5gDd8QQAzGDvQFnCgvIuw9sql6aqgXgcBx4qcUAG9NUAZi1ZcYd0E= X-MS-TrafficTypeDiagnostic: ME2PR01MB2900: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(265634631926514)(788757137089); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231221)(944501327)(52105095)(6041310)(20161123562045)(2016111802025)(20161123558120)(20161123564045)(20161123560045)(6072148)(6043046)(201708071742011); SRVR:ME2PR01MB2900; BCL:0; PCL:0; RULEID:; SRVR:ME2PR01MB2900; X-Microsoft-Exchange-Diagnostics: 1; ME2PR01MB2900; 4:d1PZdaKoyYZA3BQwnFmdNbShJpXivLJEMxMBHO87KUZ+WedyD56edmKIJmFKjuzxrKyFE0OfY+3avVS15DSz3O982qe666vZ5YG/3ahlrdQZfcIm19dPkzGP0uWPKVl+MHnp+iXNhla48LMFNaYsWtxcnnBZzi09z8SZbBHAJa88351vVTFRzCbs/VL3lRP5IDuGXdgGbyaaR5Nvz0tMh2FIu+QGVNQ/QUzH41PvHkhCXM+tduAwMVIq10DY9gM7IfUpBZQX1WlcskOfS+XT4YoZUAfLBwzjPwfXtBxQ5YYtqU7vA34kkBLEJ3U1358JXvnytwRCI8RKE5pbsF9XVBYacYZKNCBKvevrGqd5VxcaZdttoxojK+5E6+zBBFLD X-Forefront-PRVS: 0636271852 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39830400003)(39380400002)(376002)(366004)(396003)(346002)(377424004)(189003)(199004)(2616005)(97736004)(47776003)(45080400002)(486006)(68736007)(316002)(50466002)(105586002)(48376002)(26005)(551544002)(106356001)(25786009)(66066001)(74482002)(36756003)(6116002)(3846002)(86362001)(478600001)(476003)(956004)(6506007)(386003)(59450400001)(52116002)(51416003)(7116003)(7736002)(5660300001)(58126008)(2906002)(2351001)(16586007)(6666003)(81156014)(6486002)(16526019)(186003)(2361001)(6916009)(81166006)(6512007)(305945005)(53936002)(8676002)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:ME2PR01MB2900; H:oberon.local; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; Received-SPF: None (protection.outlook.com: tenpoint.co.nz does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; ME2PR01MB2900; 23:8yogAgue9SR0PcFxQ4txs22JDEY6e0vL6EuWmplB7?= =?us-ascii?Q?Tjn8Cf+l9TLXJsNDVat02DaoYeqxXXFYBQ9v2PhKOa5Zo1tA3ElL6fkt1U+Z?= =?us-ascii?Q?EXQaA7U9mKCSvMqeiuW+zGcYOASlPrBvlKfpolJD7lnaj34bjSPU/p6HIySo?= =?us-ascii?Q?OpsLxf2NiWDIQse4i7hqhW5GOOKRaz9OpT6IUE5c0sP4cy12MMcW/rO/jaae?= =?us-ascii?Q?V/1ciTWJITdpBUUahZNvWf5j0ss5hhEHFpZlCAcwLFuwwEW6njs3RwcgnIac?= =?us-ascii?Q?hFv7nHRxbb+SHV8iz8SZZ/fqv1sshx0sddjwTcx1oQe2ewqdS1FBR+fyPGe5?= =?us-ascii?Q?6Rfej1Lkzw/eOYnVslgftHq+jdy2YJz0KtNevHcmJzlNgBX+EDZ8QCDVmNdz?= =?us-ascii?Q?N92sHgC7KRCxa+OKPch46Nt90Z5PepOFMAX9t22BQQ0hXfZ1VW7RzMnCy9Hf?= =?us-ascii?Q?o5XhzrZIi95Pf0BM0UvhdBp2TIiXVLAGrTKxKA8e8hIhALhBH8UGjDA+VTU6?= =?us-ascii?Q?qf3HlGMfmFqhDzVHiV1cpX4rpUyRl2d4s8mG2Bjf6xwA0TW6Xj6Kn/HDidat?= =?us-ascii?Q?QhBWHgx8eUZQnLT2vEl/QX4OdlOWKSpa437VQ5btNv6sVOFNL85vhy2ZgBq3?= =?us-ascii?Q?PvAioyDA8ezKVhTApHsFiDH1xDxtJA6cOvxK/DtVa2Y3xDexu3SPHHSdLiCY?= =?us-ascii?Q?PMfbg9mWozmg2g7LB2smLL3Uz67cfVWjEhKeM76ZyLQupdMCKdEUpiiO95Ro?= =?us-ascii?Q?O2rxp+U9MZieMCrIysNL9RLApprjkUZZiSaVxX0A5XECXxSfKBaeJWMtnY4F?= =?us-ascii?Q?io/Zv3nUGXOzspPf5UB+BZbVGqhW2/3w2jKmD11U0onVzfqnsAVLjM2e4TJ1?= =?us-ascii?Q?PepBYD4nzK/tSUe9Z0YRZjyxL4B5KdZ1nxeqfTU7EnYC3mTg9dRKmbccCkcR?= =?us-ascii?Q?M0C3GH2NlhNujvyBVNRq7usPsCXQU6JyJjYcqLEwUojwcP+zR+qdWJwoBs3U?= =?us-ascii?Q?pVGvHsgxWV/5R3oykaDT1VzHdW7ydShWHhqUibTIs7caMQA6e/cMIAUTe2Zw?= =?us-ascii?Q?0al1g2wo1nxXv/3v+x52zONRIObxgvx5tMB1oh9DQdtZD47X8VY9746KuJYX?= =?us-ascii?Q?GV9VIIXg7sGsfaAq2ymP8CnctEwc0dCjsrYO4SU+4NDy5RgXBUpuFpeJgkb5?= =?us-ascii?Q?EYzUqumk+LQJ1/9qw+LraB3UeqnRPEaVmAL5ruRekXjI6Tj+jcHHac8bGCKv?= =?us-ascii?Q?4OssiUujSnvFHI0IQ8YyPl2Z3bl2PRYLfQdIR/P78jtdPoCQi8bnCmz7KpU4?= =?us-ascii?B?QT09?= X-Microsoft-Antispam-Message-Info: w4mcCkskq2suhMhVcT+viKnNzV5MQ6/EpYQpUlYcPPHcRm6tR48lcCaFKf5kB+JFErXc+76eYG2tPmFrKAWydQZ/WXLez6HpYZ+pwxYrBq1AG4pNn3Ik2BLh+muyRDZMmXnTBYeQYNGmdB3HP6x9guifR8jFpYdp9JKfIf6XAfEG3Olyn1Mj8JDOS9h05ndu X-Microsoft-Exchange-Diagnostics: 1; ME2PR01MB2900; 6:EK99uJLMVDDGwzewC/6uINJKDlkyPOIlXDpf6bx1bBXmVxX7yTNIwrCLavSZmnSe9dGZ2dftoIZE33biJXF2XnXs0Zs3kMxh6L+aBO1y7WxluFnr/7fOwURD9GyCA1Hj4Vhhm77XHWSVcUvC4Jl+aQKcF3twp/6JhQCHVKC7bkDY9TxU64UslMRvQTaGQaqdNMlZ+dgtBryP/nuD8fjWJMhc6W3SvLt/KYejDzZ2jYE8IdpWC3BQQLwEmfh3oRKVuNH4Qh3QFtj2mfTGrxfxTiUuksCfprYb4FQfySofuqJIr1aOl7/ohTiCHc/nrSxpN83BrchMHIF/P+h5w1h2U2EWAl7ExL5UBcO+yhDaNerTOqXwIjr9OfOrPfWtsENcv3KPqrahO4WR7zniRzSfqgiU+MhrXYy7sR+h78lxmN7EFDKEszHgOBOuCRBAhDvUpaMrjOkWz8l57q4Ka5EGDw==; 5:hbXZhsMlvT+7RIiDOb8dr/i8ZE36FqX/ifhpvRsBWw+8QjYqZFMHIgvKsm/rPl7MuD1xZ504Pb7032fhd1QcSpATlQQt2Qu8AY54uz57G7W8vZQF9RRnSrJVXIIQua2AD2+CCtZYU9SMw3evcm3PgxnvHgLHozMnbroYd3xrfTM=; 24:ObPIIcD+jsVBDcLGoRFUy7TiGo31+41M1hFe1g2nVQs5b4EXwf22P1hUxjFtWs2wQjtoGz/PiirAweLagTwg/dEzQm+c4T2UOEt6X8OCvf0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; ME2PR01MB2900; 7:nFdXoEq2wjbpu0vh6e4EhOScmDeSDRw5BM8P7AAwzMPNMg7XuFrjDk6FnjbZejAziMY5DUyf0wABdtKUrdHhHzzxvHx3sal5sTi31jdOkt09ZwB4X0nw9dC1kDBoJV7wyejtZpdEd36NCjvOfPb9DeCESEt74AocIQVD5PzUD1L5Pyk/d5e9AgJgyB2cL+R4mX/Z27IgtR2/V1wX69uW97QnexYlNthKIp8JOHKX0GSrm+hnMqmwFDUCKGNjNfE0 X-OriginatorOrg: tenpoint.co.nz X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2018 23:15:15.7280 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3a254b11-14f0-403b-97fb-08d59da69695 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: ed686f26-19e8-407b-91d0-7364c1c6f5cf X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME2PR01MB2900 X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.1 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.1 (-----) 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- ;delete Column One M-S- ;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)) From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 17 19:56:42 2019 Received: (at 31104) by debbugs.gnu.org; 17 Apr 2019 23:56:42 +0000 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 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 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) 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) From: Noam Postavsky To: Nick Helm Subject: Re: bug#31104: 26.1; Undo limits References: Date: Wed, 17 Apr 2019 19:56:32 -0400 In-Reply-To: (Nick Helm's message of "Mon, 09 Apr 2018 11:15:12 +1200") Message-ID: <87ftqgw5hr.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 31104 Cc: 31104@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 08 08:27:06 2019 Received: (at 31104) by debbugs.gnu.org; 8 Aug 2019 12:27:06 +0000 Received: from localhost ([127.0.0.1]:40098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hvhVZ-0001EV-Ly for submit@debbugs.gnu.org; Thu, 08 Aug 2019 08:27:05 -0400 Received: from mail-pl1-f178.google.com ([209.85.214.178]:35896) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hvhVY-0001E1-A6 for 31104@debbugs.gnu.org; Thu, 08 Aug 2019 08:27:04 -0400 Received: by mail-pl1-f178.google.com with SMTP id k8so43497506plt.3 for <31104@debbugs.gnu.org>; Thu, 08 Aug 2019 05:27:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Vzkum6iBpZZGen7q07gjorLOk1wqNo7Heur/wfZB97g=; b=JewQ37687BQdjFQpefkG6n8M56poIxpN7F0QRTrgOb6/d9VdPLlYYA1gmizmNe7vdW 6ki5I3mpGH4lZa1Kzfb0mzAheZkyOd1BdZkHfP2t6DG63gvqZ9DJnBKfVQvLBzwq+Pqu FoIdNZkpt0+y2dOPu2WmcS1gED1dyDlPHVw6zPwkvesc2hMIK68xlsRkncuD5mMo0PC0 xhi2rMvYFLI20ldHszQKAzjBSd6nFFk7AdSlKxEJZR9AGL4qjimkGXN9lOvrZSstU7MQ J3uRAoRMiKgJUA/bWOBW9JNcRsZACOBCgk1/lbZfyRw4eo9gv7T1PrTnA8fys6XRVBi2 R3Fw== X-Gm-Message-State: APjAAAXbUN01SYtgCuFJAyZtq6FEhgOwEznP0HKpui4ZUFLS2C4l/Axj v4qfP76QLC9s1H6eggAfLpygCYbUTkr0ogu8JfM= X-Google-Smtp-Source: APXvYqy1GzzAGsvTMeSmCeN9Tlju4E6CZWz/d6k8MZinK5zhOKvyNTms1EmsvTP+kZyZQpK4nakvm03+NP+CaPshA+g= X-Received: by 2002:a17:902:d70a:: with SMTP id w10mr12715492ply.251.1565267218462; Thu, 08 Aug 2019 05:26:58 -0700 (PDT) MIME-Version: 1.0 From: Stefan Kangas Date: Thu, 8 Aug 2019 14:26:47 +0200 Message-ID: Subject: Re: bug#31104: 26.1; Undo limits To: Noam Postavsky Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31104 Cc: 31104@debbugs.gnu.org, Nick Helm X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) Noam Postavsky writes: > 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. The last change here was in: commit 2159bd065212117a6aff538a69d5ac1864dcd134 Author: Chong Yidong 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 10 05:25:24 2019 Received: (at 31104) by debbugs.gnu.org; 10 Aug 2019 09:25:24 +0000 Received: from localhost ([127.0.0.1]:43467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwNcq-0006gR-AL for submit@debbugs.gnu.org; Sat, 10 Aug 2019 05:25:24 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51138) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwNcn-0006gD-SU for 31104@debbugs.gnu.org; Sat, 10 Aug 2019 05:25:22 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:51359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hwNcf-0003UK-PC; Sat, 10 Aug 2019 05:25:14 -0400 Received: from [176.228.60.248] (port=3902 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hwNcb-0007D1-KI; Sat, 10 Aug 2019 05:25:10 -0400 Date: Sat, 10 Aug 2019 12:25:04 +0300 Message-Id: <83r25t8j9r.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-reply-to: (message from Stefan Kangas on Thu, 8 Aug 2019 14:26:47 +0200) Subject: Re: bug#31104: 26.1; Undo limits References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 31104 Cc: 31104@debbugs.gnu.org, nick@tenpoint.co.nz, npostavs@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Thu, 8 Aug 2019 14:26:47 +0200 > Cc: 31104@debbugs.gnu.org, Nick Helm > > The last change here was in: > > commit 2159bd065212117a6aff538a69d5ac1864dcd134 > Author: Chong Yidong > 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 10 14:30:07 2019 Received: (at 31104) by debbugs.gnu.org; 10 Aug 2019 18:30:07 +0000 Received: from localhost ([127.0.0.1]:44436 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwW7z-0005F8-5D for submit@debbugs.gnu.org; Sat, 10 Aug 2019 14:30:07 -0400 Received: from mail-pl1-f180.google.com ([209.85.214.180]:41204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwW7x-0005E7-K0 for 31104@debbugs.gnu.org; Sat, 10 Aug 2019 14:30:06 -0400 Received: by mail-pl1-f180.google.com with SMTP id m9so46096754pls.8 for <31104@debbugs.gnu.org>; Sat, 10 Aug 2019 11:30:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=njZ2UspvgB12P5iMm/0YNYRuBlrWXYJ30aXuwE6yBSM=; b=op8h4IIHo3p51jZdNa+UYaDre/tbcn3OH8qvydR4sf7dmDFmOHC05Gm5fX0H2vOVWp +IaIkSib0xqNdM+HxEvUM9czu0JlFvKRMNdYhlNtd1HWbjf/xP/gjofohRBHOYmRKdIN ns+L3AfGLnAqVIQKgjO1QdVK6zRTvzduc48btfh8XCoyondd5fa6rZ2MeW90qyYkLHTB Ajl77q2+2Dn+rwFl7LfV0JTSq84Vgtk+I9hKkFKBGPDC0Iy4IcENr3+YfbU7SBcg3zkr eYmO62zDwhmTcVbgW/4DltM+44ImYmKmELSafWbbaAm7yNQOGREgTIRrsBOQaINjNaxT /bSQ== X-Gm-Message-State: APjAAAXnrh4iGQsGV/CqJ4NzYzS1k3D+Y4KA6xSR2mNuzbe+A5K2WayT ZIRfgeVYnGtA4KMk5PyMOVnChH0QVRf+dPlFqpI= X-Google-Smtp-Source: APXvYqxidwqBAXWdojX0smY02hlo7fcLsvuX16MGYr3J8dvG1L8A33hboHLqBCi0uMvQM4JioMVySSjHU87VAJjIms0= X-Received: by 2002:a17:902:b702:: with SMTP id d2mr26001454pls.259.1565461799859; Sat, 10 Aug 2019 11:29:59 -0700 (PDT) MIME-Version: 1.0 References: <83r25t8j9r.fsf@gnu.org> In-Reply-To: <83r25t8j9r.fsf@gnu.org> From: Stefan Kangas Date: Sat, 10 Aug 2019 20:29:48 +0200 Message-ID: Subject: Re: bug#31104: 26.1; Undo limits To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-Debbugs-Envelope-To: 31104 Cc: 31104@debbugs.gnu.org, Nick Helm , Noam Postavsky X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) tags 31104 fixed close 31104 27.1 quit Eli Zaretskii 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 From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 10 14:34:19 2019 Received: (at control) by debbugs.gnu.org; 10 Aug 2019 18:34:19 +0000 Received: from localhost ([127.0.0.1]:44446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwWC2-0005Na-2E for submit@debbugs.gnu.org; Sat, 10 Aug 2019 14:34:19 -0400 Received: from mail-pf1-f178.google.com ([209.85.210.178]:46242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hwWC0-0005NM-07 for control@debbugs.gnu.org; Sat, 10 Aug 2019 14:34:16 -0400 Received: by mail-pf1-f178.google.com with SMTP id c3so24584150pfa.13 for ; Sat, 10 Aug 2019 11:34:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6EJtuRKserX5JeB3g2o7HjV8DeRCqME2gyN0J7R1cRs=; b=INIGZiUyighki18VZU1rg0QT+lb/QoNnw5GjIFELgfX8iEvNoGThA/opw2Sqo5baPZ zvPoNF5Tw2KssbxbF8cduAIrnQLA4C0pg5Ws6dDzikGixf9dDpZN3tMZaz0TJkca4ytx r3/FosxlQRNSvV3epELgqeyvbXQQSYyx/ZGPTyisJeRhqnftz2liZdwPhsFbmk585GIm aVzXf96pq8+YZzCgiJjCxPDkilR7oEzdlEaR9KPTVxZVBeTEUsEV5JGFqDyN0Ap6Uzq9 JGz+9kbH9sW2z6h7ca1t1bjRCWQhhfUxaXlkyDARBbbYNumKzbf+gB3q2l7dAUs/8m8z yfVw== X-Gm-Message-State: APjAAAWWEum9CDRX4Nrd0eBQzmSBCPz5J2Izr6CSeLwGTYkBsZP/XNL+ 4FvK/zstFPvbvLOv9Qfwm1lUFZ9PErtRAIwOhwqG292f X-Google-Smtp-Source: APXvYqyMwZc7Qx3/IWd62ClqN4+1FSnQZJlSJrWLk9PJ/rROT9lpS5X+Q+SPt3pTRCpg9R77PFUzRdgZYa6dbiNxCGI= X-Received: by 2002:a65:53cb:: with SMTP id z11mr21179472pgr.200.1565462049993; Sat, 10 Aug 2019 11:34:09 -0700 (PDT) MIME-Version: 1.0 From: Stefan Kangas Date: Sat, 10 Aug 2019 20:33:58 +0200 Message-ID: Subject: To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 31104 - wontfix quit Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.210.178 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 BLANK_SUBJECT Subject is present but empty 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 31104 - wontfix quit Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.210.178 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.2 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 2.0 BLANK_SUBJECT Subject is present but empty 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager tags 31104 - wontfix quit From unknown Sat Jun 21 05:17:09 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 08 Sep 2019 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator