From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Keith David Bershatsky Newsgroups: gmane.emacs.bugs Subject: bug#27214: truncate_undo_list in undo.c: exclusions, warnings, documentation. Date: Sat, 03 Jun 2017 10:49:36 -0700 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: blaine.gmane.org 1496512274 22522 195.159.176.226 (3 Jun 2017 17:51:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 3 Jun 2017 17:51:14 +0000 (UTC) To: 27214@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 03 19:51:10 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHDCf-0005bd-4i for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Jun 2017 19:51:09 +0200 Original-Received: from localhost ([::1]:54421 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHDCk-0001fG-Hu for geb-bug-gnu-emacs@m.gmane.org; Sat, 03 Jun 2017 13:51:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39435) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHDCe-0001f9-AV for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2017 13:51:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHDCZ-0005Om-94 for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2017 13:51:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51410) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dHDCZ-0005Nr-04 for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2017 13:51:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dHDCY-0002Br-Lt for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2017 13:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Keith David Bershatsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 03 Jun 2017 17:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 27214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: Emacs Bug Reports Original-Received: via spool by submit@debbugs.gnu.org id=B.14965122098360 (code B ref -1); Sat, 03 Jun 2017 17:51:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Jun 2017 17:50:09 +0000 Original-Received: from localhost ([127.0.0.1]:54087 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHDBf-0002Ak-Aa for submit@debbugs.gnu.org; Sat, 03 Jun 2017 13:50:08 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:48345) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dHDBd-0002AC-HS for submit@debbugs.gnu.org; Sat, 03 Jun 2017 13:50:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHDBX-0004AB-Fu for submit@debbugs.gnu.org; Sat, 03 Jun 2017 13:50:00 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:41918) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dHDBX-0004A7-CU for submit@debbugs.gnu.org; Sat, 03 Jun 2017 13:49:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dHDBV-0001Yf-PN for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2017 13:49:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dHDBQ-00046a-OT for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2017 13:49:57 -0400 Original-Received: from gateway33.websitewelcome.com ([192.185.146.68]:13630) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dHDBQ-0003sy-Dt for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2017 13:49:52 -0400 Original-Received: from cm3.websitewelcome.com (unknown [108.167.139.23]) by gateway33.websitewelcome.com (Postfix) with ESMTP id EA00B2A97 for ; Sat, 3 Jun 2017 12:49:38 -0500 (CDT) Original-Received: from gator3053.hostgator.com ([50.87.144.69]) by cm3.websitewelcome.com with id UHpd1v00A1W3Awq01HpeWa; Sat, 03 Jun 2017 12:49:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lawlist.com ; s=default; h=Content-Type:MIME-Version:Subject:To:From:Message-ID:Date: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Ottc+Qm1uVQtGsf86/FZpSN3amBSmIn9eKixLwT2dJc=; b=OXns1CTb8NiRZrmm5M2iTB0RNU NGKOp2g1dKhScO5eLqpMiVJGT6yCFSZdKW/ph0XRgSiVrzNWKNNUqURgkUIYugafyJTOWroDVX+Sh BS7RPsecytQqCMDiYCvMY7z6xjVnLdOqDwF6wQ6KITHBjPLL+VBrrsjFZk+oZUT4optazXnx3Ro33 Puu9Zs0NXyUJtG0ksfiijuneq4IsNqnZJ0i9rhJiC2TIwRo6cRerhtYhGyesBb21IC4XuVQQkH/5o WNjG2tPwysRuL9MiBm3zOOdYUcGU9RSqIDCzZI9/m3PHLqoo9Gh+MXFv039slHvQkCYn1KQL8L1hp Unc/z2rw==; Original-Received: from cpe-45-48-239-195.socal.res.rr.com ([45.48.239.195]:50736 helo=server.local) by gator3053.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1dHDBB-0005Mt-0Q for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2017 12:49:37 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3053.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - lawlist.com X-BWhitelist: no X-Source-IP: 45.48.239.195 X-Exim-ID: 1dHDBB-0005Mt-0Q X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: cpe-45-48-239-195.socal.res.rr.com (server.local) [45.48.239.195]:50736 X-Source-Auth: lawlist X-Email-Count: 1 X-Source-Cap: bGF3bGlzdDtsYXdsaXN0O2dhdG9yMzA1My5ob3N0Z2F0b3IuY29t X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x 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: 208.118.235.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:133226 Archived-At: In developing a fork of the popular undo-tree.el library (new features, enhancements, and bug-fixes), I found the following areas in `truncate_undo_list` that could use some improvements: 1. User-defined exclusions; e.g., a list of elements that will not be truncated unless the user has crossed the `undo-outer-limit' threshold. EXAMPLE: (defvar truncate-undo-list-exclusions '(undo-tree-canary) "A list of user defined elements that will not be truncated during garbage collection unless the user has reached the `undo-outer-limit`, in which case ....") 2. User-enabled messages/warnings when truncation is occurring due to the `undo-limit`, or the `undo-strong-limit`, and some type of indication as to what was thrown out. EXAMPLE: (defvar truncate-undo-list-warnings t "When non-nil, the internal function `truncate_undo_list' will generate messages letting the user know that he/she has crossed the `undo-limit` or `undo-strong-limit`, along with a shortened (redacted) list of what is being truncated (mentioning the specific limit crossed).) 3. Some type of documentation system enabling a user to read about `truncate_undo_list'; e.g., consolidate the comments that are presently only visible if the user visits the source-code and add some additional information about the new features mentioned above. BACKGROUND: Here is a reprint of the thread that I launched on emacs.stackexchange.com explaining my use-case and thoughts about a potential workaround: https://emacs.stackexchange.com/q/33248/2287 **Q**: How to preserve the last entry in the `buffer-undo-list` when garbage collection occurs? When using `undo-tree.el`, the library relies upon an `undo-tree-canary` being at the end of the `buffer-undo-list`. Emacs performs garbage collection **before** the Lisp code in `undo-tree` does its thing -- i.e.,`truncate_undo_list` in `undo.c` is activated and sometimes the `undo-tree-canary` is truncated. [A good example of this is where there is a programmatic `delete-region` followed by `insert` of significant amounts of different text, such as sorting certain sections of a buffer by `sort-reorder-buffer`, etc.] The default behavior of `undo-tree` is to begin a new `buffer-undo-tree` when a canary cannot be found -- i.e., the user loses all prior saved history. [See `undo-list-transfer-to-tree`.] In looking at the C-source code in `truncate_undo_list` I see the following relevant section from a `while` loop that goes through the `buffer-undo-list` when figuring out whether to truncate before or after an undo-boundary (which is a `nil` entry): /* When we get to a boundary, decide whether to truncate either before or after it. The lower threshold, undo_limit, tells us to truncate after it. If its size pushes past the higher threshold undo_strong_limit, we truncate before it. */ if (NILP (elt)) { if (size_so_far > undo_strong_limit) break; last_boundary = prev; if (size_so_far > undo_limit) break; } The relevant default values are as follows: `undo-limit`: 80000 `undo-strong-limit`: 120000 `undo-outer-limit`: 12000000 It looks like I may be able to set `undo-limit` to *the same value* as `undo-strong-limit` and thereby force truncation to always occur *before* the undo-boundary, but I'm not 100% certain that is the case. Additionally, I am concerned that if I set `undo-limit` to *the same value* as `undo-strong-limit`, that the earliest entries in the `buffer-undo-list` will always be truncated before subsequent entries. If that is the case, then this *may* be a bad thing .... One drastic solution would be to modify `truncate_undo_list` to look for a `symbol` in the list and preserve it; however, that only benefits me if I run a custom version of Emacs. I'm working on developing a fork of `undo-tree.el`, and I'd like a solution that other people can use with the stock version of Emacs. [*CAVEAT*: It is my assumption that the `buffer-undo-tree` that existed prior to garbage collection truncation as discussed above will still be usable after truncation occurs. I hope this is the case, but if that is a wrong assumption on my part, then please let me know. In my mind, I'm thinking of a major reorganization of the buffer where text is deleted and new text is inserted.]