From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#70077: An easier way to track buffer changes Date: Mon, 08 Apr 2024 21:36:41 +0300 Message-ID: <86il0rya4m.fsf@gnu.org> References: <86frvy51af.fsf@gnu.org> <86msq3yhot.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19826"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, yantar92@posteo.net, 70077@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 08 20:38:25 2024 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 1rttsv-0004yb-10 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 08 Apr 2024 20:38:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rttsV-0000eF-LR; Mon, 08 Apr 2024 14:37:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rttsS-0000dX-Ma for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 14:37:56 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rttsS-0003K7-E3 for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 14:37:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rttsZ-0004hM-Jz for bug-gnu-emacs@gnu.org; Mon, 08 Apr 2024 14:38:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 08 Apr 2024 18:38:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 70077 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 70077-submit@debbugs.gnu.org id=B70077.171260142617749 (code B ref 70077); Mon, 08 Apr 2024 18:38:03 +0000 Original-Received: (at 70077) by debbugs.gnu.org; 8 Apr 2024 18:37:06 +0000 Original-Received: from localhost ([127.0.0.1]:47616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rttrd-0004cC-70 for submit@debbugs.gnu.org; Mon, 08 Apr 2024 14:37:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44470) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rttrX-0004au-UA for 70077@debbugs.gnu.org; Mon, 08 Apr 2024 14:37:03 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rttrI-0003Fp-Jy; Mon, 08 Apr 2024 14:36:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=F1Wuv5edgL3s0imPNyBoYbOmI1JZHfkG494N5pHsBb8=; b=WK5YhrUU/vmzCnEL7X03 szsTn0d2kSOSN8gQInEyw5YgXbgThxZ3wgAQ8eS+Q2ATgPbDSqAhtA+5UlkmW3ZR8oLwoeb6NTF+B /FZug3I2QaqDR8FL3lup0klf8Crym+PGKGRL0dfB+qHThGDN9BbcOWQoocxpXk98y8unsTfMUx3Jv OelMbwrSpNajX4A1MJWQxhDBaoqcj6lKnKDk0jJk7othXy9/URdCOs6wW5CLLtSveHH3Cqv3gkKmd ejfRsGh2MqO4IPT8E72NoR0SX/VOToMcm9pSwBkcqGkjfI7QxpWdJeWJyeS5vRYhjDzze9IjU0sc3 +vTJslWEu+7zXw==; In-Reply-To: (message from Stefan Monnier on Mon, 08 Apr 2024 13:17:37 -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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282950 Archived-At: > From: Stefan Monnier > Cc: 70077@debbugs.gnu.org, acm@muc.de, yantar92@posteo.net > Date: Mon, 08 Apr 2024 13:17:37 -0400 > > > Name Type Default > > ———— ———— ——————— > > beg t (point-max) > > end t (point-min) > > before t nil > > next t nil > > > > BEG..END is the area that was changed and BEFORE is its previous > > content[...] > > OK, I'll switch the two, thanks. > > > (Btw, those "t" under "Type" are also somewhat mysterious. What do > > they signify?) > > `C-h o t RET` says: > > t’s value is t > > Not documented as a variable. > > Probably introduced at or before Emacs version 16. > > > > t is also a type. > > t is a type (of kind ‘built-in-class’). > Children ‘sequence’, ‘atom’. > > Abstract supertype of everything. > > This is a built-in type. If this indicates that the slots are of built-in-class type, why do we show the cryptic t there? > >> >> +By default SIGNAL is called as soon as convenient after a change, which is > >> > ^^^^^^^^^^^^^^^^^^^^^ > >> > "as soon as it's convenient", I presume? > >> Other than the extra " it's", what is the difference? > > Nothing. I indeed thing "it's" is missing there. > > My local native-English representative says that "both work fine" > (somewhat dismissively, I must add). In that case I'll yield, but do note that it got me stumbled. > > In general, when I want to create a clean slate, I don't care too much > > about the dirt I remove. Why is it important to signal errors because > > a state I am dumping had some errors? > > I don't understand why you think it will signal an error? Doesn't cl-assert signal an error if the condition is false? > More to the point, it should signal an error only if I made a mistake in > `track-changes.el` or if you messed with the internals. I have the latter possibility in mind, yes. Why catch me doing that when I'm cleaning up my mess, _after_ all the damage, such as it is, was already done? > >> >> +;;;; Extra candidates for the API. > >> >> +;; This could be a good alternative to using a temp-buffer like I used in > >> > ^^^^^^ > >> > "I"? > >> Yes, that refers to the code I wrote. > > We don't usually leave such style in long-term comments and > > documentation. > > `grep " I " lisp/**/*.el` suggests otherwise. "A journey of a thousand miles begins with one first step."