From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#1501: Emacs 22 loses undo buffer Date: Tue, 19 Oct 2021 18:01:43 -0700 Message-ID: References: <85k1b7k763.fsf@gmail.com> <87ef1engij.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="00000000000063cfd205cebe524c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26263"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Emerick Rogul , 1501@debbugs.gnu.org, Chong Yidong To: Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Oct 20 03:02:13 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mczzh-0006dw-JH for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 20 Oct 2021 03:02:13 +0200 Original-Received: from localhost ([::1]:46778 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mczzf-0007io-Ip for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 19 Oct 2021 21:02:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54320) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mczzX-0007iH-07 for bug-gnu-emacs@gnu.org; Tue, 19 Oct 2021 21:02:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40770) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mczzW-00039X-Lh for bug-gnu-emacs@gnu.org; Tue, 19 Oct 2021 21:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mczzW-0006OS-Fg for bug-gnu-emacs@gnu.org; Tue, 19 Oct 2021 21:02:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 20 Oct 2021 01:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 1501 X-GNU-PR-Package: emacs Original-Received: via spool by 1501-submit@debbugs.gnu.org id=B1501.163469171324551 (code B ref 1501); Wed, 20 Oct 2021 01:02:02 +0000 Original-Received: (at 1501) by debbugs.gnu.org; 20 Oct 2021 01:01:53 +0000 Original-Received: from localhost ([127.0.0.1]:52314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mczzM-0006Nu-R3 for submit@debbugs.gnu.org; Tue, 19 Oct 2021 21:01:53 -0400 Original-Received: from mail-pl1-f181.google.com ([209.85.214.181]:35751) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mczzK-0006NX-Rj for 1501@debbugs.gnu.org; Tue, 19 Oct 2021 21:01:51 -0400 Original-Received: by mail-pl1-f181.google.com with SMTP id b14so5151897plg.2 for <1501@debbugs.gnu.org>; Tue, 19 Oct 2021 18:01:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=V1uT8TK31jAD0X8tzIVhFKqrAV9GWZ6V9/DUFmshnTw=; b=0318T4DvgZXN95B0aBnUDtYIEpZfJgehKtoM89cVlMdDCrav+s60n+6Tzz1uyd4BLY I+YepdGfrtsC+FsrUWjaqqzkAu2TGFGEDBJ3bx2R12+azeUsUSJzZNp0S9NKx3e76O2L ANCgEqos6Jm2BnFLs5P38OU9evWanyyQp6AeTKmri6TGpnIlHw8k/9VKEYHDMXtUy/pp YRJc7SPS9+ZB5sJ0JTNDK7+8SLuoaAMB/vkoqo4F1iuGy/LUWPQvTU79o4AUTpKJ8+8d Ol/LCexH/P/11nkB2XTLdbZ7U3R2b5Qvd/DR7rTQ6bHVvNK73T9XZsrlXLgBmqMjTLM4 PTfQ== X-Gm-Message-State: AOAM533w/1sRsIetI9BxzTUjDd9M3upNOltELGGLVS/A8j4dLXL4md1H b5E58/Ku7UeycJVFSaJQ9muXdIi1vxkWvwquiig= X-Google-Smtp-Source: ABdhPJy8e8C9pM8QIm5I5gYNn2R+IA6DB4p/+BAYPeToAh2kTgWxxoLn5QuDj1CQ4MMmjCsYhwQ0i80CIRR5OLkeE18= X-Received: by 2002:a17:90b:17d2:: with SMTP id me18mr3708909pjb.132.1634691704928; Tue, 19 Oct 2021 18:01:44 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 19 Oct 2021 18:01:43 -0700 In-Reply-To: <87ef1engij.fsf@gmail.com> (Noam Postavsky's message of "Wed, 21 Aug 2019 21:19:32 -0400") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:217621 Archived-At: --00000000000063cfd205cebe524c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable tags 1501 + patch thanks Noam Postavsky writes: > Stefan Kangas writes: > >> Noam Postavsky writes: >> >>> Stefan Kangas writes: >>> >>> > increase in the memory usage of each undo record, especially when >>> > using font-lock-mode. I'm not sure that is a serious problem, since >>> > memory is only getting cheaper, but it might be worth investigating. >>> > On the other hand, we could just decide that this is not worth the >>> > effort and close this as wontfix. >>> >>> Hmm, it sounds like the problem might just be due to saving text >>> properties in the undo records? If so, maybe a simple fix is to just >>> drop them (or drop only face and font-lock-face properties). >> >> Is it not worth saving also that information? > > Definitely not face, since it's overwritten as soon as font-lock runs. > It's true font-lock-face can sometimes be set manually, though usually > it's computed by font-lock rules. This would be fairly simple to do, as in the attached patch. But I'm not sure that we should make this change, since both `face' and `font-lock-face' could be used by a major mode at various times, without getting automatically re-added by font-lock. >From (info "(elisp) Precalculated Fontification"): But if the mode does not use the normal Font Lock machinery, it should not set the variable =E2=80=98font-lock-defaults=E2=80=99. In t= his case the =E2=80=98face=E2=80=99 property will not be overridden, so using the = =E2=80=98face=E2=80=99 property could work too. IOW, I'm not sure that the proposed change won't introduce subtle bugs. Other than that, we have doubled all undo limits in Emacs 27.1, so maybe that's enough of a fix for now? Any other opinions? --00000000000063cfd205cebe524c Content-Type: text/x-diff; charset="US-ASCII"; name="0001-Decrease-size-of-undo-entries.patch" Content-Disposition: attachment; filename="0001-Decrease-size-of-undo-entries.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: 83095a7432305b3f_0.1 RnJvbSA3YjBmZWE0MmY3OTNkN2I3ZjlmYTk5MzhiM2M5OWIxZjI4MzIzNTMxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTdGVmYW4gS2FuZ2FzIDxzdGVmYW5AbWFyeGlzdC5zZT4KRGF0 ZTogV2VkLCAyMCBPY3QgMjAyMSAwMjo0MjozMSArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIERlY3Jl YXNlIHNpemUgb2YgdW5kbyBlbnRyaWVzCgoqIHNyYy91bmRvLmMgKHJlY29yZF9kZWxldGUpOiBS ZW1vdmUgdGhlICdmYWNlJyBwcm9wZXJ0eSBmcm9tIHVuZG8KZW50cmllcyB0byBzYXZlIHNwYWNl LiAgKEJ1ZzE1MDEpCi0tLQogc3JjL3VuZG8uYyB8IDcgKysrKysrKwogMSBmaWxlIGNoYW5nZWQs IDcgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3NyYy91bmRvLmMgYi9zcmMvdW5kby5jCmlu ZGV4IDJkYjQwMWViYzcuLjI2MGNmNzkyYzcgMTAwNjQ0Ci0tLSBhL3NyYy91bmRvLmMKKysrIGIv c3JjL3VuZG8uYwpAQCAtMTY0LDYgKzE2NCwxMyBAQCByZWNvcmRfZGVsZXRlIChwdHJkaWZmX3Qg YmVnLCBMaXNwX09iamVjdCBzdHJpbmcsIGJvb2wgcmVjb3JkX21hcmtlcnMpCiB7CiAgIExpc3Bf T2JqZWN0IHNiZWc7CiAKKyAgLyogUmVtb3ZlIHRoZSBgZmFjZScgcHJvcGVydHkgdG8gc2F2ZSBz cGFjZS4gIChCdWcxNTAxKSAgKi8KKyAgaWYgKCFOSUxQIChzdHJpbmcpKQorICAgIEZyZW1vdmVf bGlzdF9vZl90ZXh0X3Byb3BlcnRpZXMgKG1ha2VfZml4bnVtICgwKSwKKwkJCQkgICAgIG1ha2Vf Zml4bnVtIChTQ0hBUlMgKHN0cmluZykpLAorCQkJCSAgICAgQ0FMTE4gKEZsaXN0LCBRZmFjZSks CisJCQkJICAgICBzdHJpbmcpOworCiAgIGlmIChFUSAoQlZBUiAoY3VycmVudF9idWZmZXIsIHVu ZG9fbGlzdCksIFF0KSkKICAgICByZXR1cm47CiAKLS0gCjIuMzAuMgoK --00000000000063cfd205cebe524c--