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: Tue, 09 Apr 2024 07:10:24 +0300 Message-ID: <8634rvxjkf.fsf@gnu.org> References: <86frvy51af.fsf@gnu.org> <86msq3yhot.fsf@gnu.org> <86il0rya4m.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30449"; 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 Tue Apr 09 06:11:20 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 1ru2pL-0007j3-U3 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Apr 2024 06:11:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ru2oy-0002xs-2I; Tue, 09 Apr 2024 00:10:56 -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 1ru2ox-0002xi-EO for bug-gnu-emacs@gnu.org; Tue, 09 Apr 2024 00:10:55 -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 1ru2ox-0005Ke-6U for bug-gnu-emacs@gnu.org; Tue, 09 Apr 2024 00:10:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ru2p4-00011x-UN for bug-gnu-emacs@gnu.org; Tue, 09 Apr 2024 00:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Apr 2024 04:11:02 +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.17126358433849 (code B ref 70077); Tue, 09 Apr 2024 04:11:02 +0000 Original-Received: (at 70077) by debbugs.gnu.org; 9 Apr 2024 04:10:43 +0000 Original-Received: from localhost ([127.0.0.1]:48010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ru2ol-000101-Ac for submit@debbugs.gnu.org; Tue, 09 Apr 2024 00:10:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35114) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ru2oi-0000zJ-7e for 70077@debbugs.gnu.org; Tue, 09 Apr 2024 00:10:41 -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 1ru2oU-0005HJ-C2; Tue, 09 Apr 2024 00:10:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=WCA57+P3kprMjiAG7gbx8DsAKJGtYDWba/KZEYEvWZo=; b=Dt9rPV7dQyJV MNy3+8wSPDPMtXPrK5H8UlyX/m/q07sbzn+iNVp+ZHUhJ8+7Rrl1ge6peTrWzzwIR879WuuDCvNW0 WY+2DvqE4nLZfWvb351M28TP5sxglQXT3fiu1CuduP0sVvmD27THcYVjPy+ztaOAzWPB1tJ5arVTb Wru5EQNXX3zC4PvJLXdlVI1jU/Zyp7+EjGT4BYcoj0u9qPv6+yEcHsd/AKY1kL7FFTys8v79bbj7+ zGnPEqL26GcHE32YAmSGjbDYZDfUB+qvraxt0HsprB8zcCql5DDpkBZL4kUlCB0BpfHeDLQn7i91N 6XHRH7FT9unueXLa+jZKhQ==; In-Reply-To: (message from Stefan Monnier on Mon, 08 Apr 2024 16:57:11 -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:282963 Archived-At: > From: Stefan Monnier > Cc: 70077@debbugs.gnu.org, acm@muc.de, yantar92@posteo.net > Date: Mon, 08 Apr 2024 16:57:11 -0400 > > > If this indicates that the slots are of built-in-class type, why do we > > show the cryptic t there? > > No, what it's saying is that these slots can contain values of any type > (since any type is a subtype of t). > This `Type` information is a way to document what kind of values can be > found in those slots. Very often we don't bother specifying it, in > which case `t` is used as a default. Then maybe show "Any" or even "N/A". t is simply not informative at all. Actually, it is counter-productive: it makes a simple issue look complex and strange. > >> > 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? > > Yes. What makes you think it will be false? If it should always be true, why have it there? > >> 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? > > But `track-changes--clean-state` is not a function to "clean up > the mess" any more than, say, `track-changes-fetch` or > `track-changes--before`. I give up (but I don't give 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." > > I disagree with the goal, tho. > If you want, I can add something like "--Stef" at the end to clarify who > is this "I", tho nowadays I tend to rely on `C-x v h` to find that kind > of information. Yes, adding somee ID of "I" would be the least I'd like to have there. > The text there is just recording my thoughts about this part of the > design of the API. The rewording to avoid saying "I" is very simple, but I won't insist.