Subject: bug#57266: Maintaining the base_line_number cache

From: Eli Zaretskii <[email-masked]>
Date: Tue, 23 Aug 2022 18:56:28 +0300

> From: Lars Ingebrigtsen <[email-masked]>
> Cc: Stefan Monnier <[email-masked]>,  [email-masked]
> Date: Tue, 23 Aug 2022 16:21:55 +0200
> 
> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <[email-masked]> writes:
> 
> > 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.
> 
> My two cents: I was reading through parts of the newline (cache) code
> last week while I was pondering whether to do the `pos-eol' functions or
> not, and I have to say that I found it pretty impregnable.  So in a way
> I'm relieved to learn that it's (partly) because the code doesn't make
> as much sense as it should.  😀
> 
> Apparently Eli is the only person that understands the code at present,
> and I understand his reluctance to change something that works.  But
> making the code easier to understand would enable more people to
> actually handle the code.  So I'm in favour of improving the code.

I'm also in favor of improving the code.  I just disagree with Stefan
about what constitutes "improvement" in this case.

I had my share of "TIL" experiences, where I was positive I knew how
the code should work and wrote or changed something accordingly --
only to discover that some of my concepts were completely wrong or
missed some important aspects which wound up invalidating some of the
code I wrote.  I don't think I'm alone in that.

Breaking things while fixing real bugs is justified.  But this isn't
that case.