From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 57266@debbugs.gnu.org
Subject: bug#57266: Maintaining the base_line_number cache
Date: Mon, 22 Aug 2022 14:02:44 -0400 [thread overview]
Message-ID: <jwvk070qi54.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <83edx89rl4.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 22 Aug 2022 19:21:43 +0300")
>> >> > I didn't just mean just_this_one_p thingy, I meant all the changes
>> >> > that attempt to somehow "clean up" the use of the line-number cache.
>> >> > Why do we have to do that at all? This stuff is not too complex, and
>> >> > it works for ages! Isn't the fact that we find more and more small
>> >> > issues with the changes telling you something?
>> >>
>> >> Yes, it's telling me that the code is a mess and I'm trying to fix it by
>> >> documenting what is actually needed.
>> >
>> > It's fine to fix and enhance the documentation, but please don't fix
>> > the code that works.
>>
>> If the code doesn't match the doc, then we'll never know if the doc
>> is wrong.
>
> Which is why I'm perfectly OK with documenting what the code does.
But I'm not. Because I don't really know what the code does.
The doc I wrote documents the design I came up with based on my
understanding of what the code does.
I went through the trouble of figuring out a design of how things
*should* work, document it, and adjust the code to match the design.
So I'm not interested in pushing some half-assed version of it that
documents a design that doesn't match the reality, nor pushing partial
fixes/workarounds (for borderline cases that noone ever bumped into
anyway) while keeping the mess of unexplained hacks.
> Please! I hope my requests mean something, given that I'm the only
> one who works on bugs in these areas, and probably will keep doing
> that for the observable future.
Indeed, my proposed patch is not a bug fix.
It's a code-maintenance patch. It's meant to improve the code, not
the behavior.
[ I do think it will improve the behavior in some cases (by fixing a few
corner case bugs, and more importantly by improving performance when
displaying a buffer is several windows), but that is not the
motivation, and there is undoubtedly the risk that it will introduce
regressions (which will help us better understand the code). ]
Stefan
next prev parent reply other threads:[~2022-08-22 18:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-17 21:18 bug#57266: Maintaining the base_line_number cache Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <handler.57266.B.166077115022973.ack@debbugs.gnu.org>
2022-08-17 21:39 ` bug#57266: Acknowledgement (Maintaining the base_line_number cache) Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-18 6:03 ` bug#57266: Maintaining the base_line_number cache Eli Zaretskii
2022-08-22 4:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-22 12:11 ` Eli Zaretskii
2022-08-22 12:41 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-22 13:07 ` Eli Zaretskii
2022-08-22 13:32 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-22 16:21 ` Eli Zaretskii
2022-08-22 18:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2022-08-22 18:35 ` Eli Zaretskii
2022-08-22 19:57 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-23 14:21 ` Lars Ingebrigtsen
2022-08-23 14:40 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-08-23 15:56 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvk070qi54.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=57266@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.