GNU bug report logs - #70077
An easier way to track buffer changes

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Fri, 29 Mar 2024 16:17:01 UTC

Severity: normal

Tags: patch

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: acm <at> muc.de, yantar92 <at> posteo.net, 70077 <at> debbugs.gnu.org
Subject: bug#70077: An easier way to track buffer changes
Date: Tue, 09 Apr 2024 07:10:24 +0300
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 70077 <at> debbugs.gnu.org,  acm <at> muc.de,  yantar92 <at> 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.




This bug report was last modified 1 year and 99 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.