bug#57266: Maintaining the base_line_number cache

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> >> > 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