Re: Emacs 31.0.50 (2f1052d9b0de) will line-number in some buffers which shouldn't show it, is there some changed in recent master branch related to display-line-number

[Konstantin Kharlamov <Hi-Angel@yandex.ru>]

On Fri, 2025-01-03 at 13:50 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Date: Fri, 03 Jan 2025 12:31:23 +0300
> > 
> > On Fri, 2025-01-03 at 03:21 -0600, Stefan Kangas wrote:
> > > Konstantin Kharlamov <Hi-Angel@yandex.ru> writes:
> > > 
> > > > On Fri, 2025-01-03 at 13:45 +0800, Eval EXEC wrote:
> > > > > Hello, I am building Emacs from source, and I’ve noticed
> > > > > something
> > > > > unusual. Line numbers appear in my rg and xref buffers, but
> > > > > they
> > > > > disappear after approximately 100ms. This happens even though
> > > > > I’ve
> > > > > only
> > > > > configured display-line-number-mode to be enabled in prog-
> > > > > mode
> > > > > via an
> > > > > add-hook.
> > > > > 
> > > > > Has there been any recent change in the code related to
> > > > > display-
> > > > > line-
> > > > > number-mode that might explain this behavior?
> > > > > 
> > > > > Thank you for your help!
> > > > 
> > > > FWIW, I just tried building Emacs from latest commit to look at
> > > > it,
> > > > but
> > > > it doesn't even build with `Error: void-function (rx)`.
> > > > 
> > > > Now, I know Emacs build system has some controversial design
> > > > decisions
> > > > that were discussed a few months ago (which basically lead to
> > > > errors
> > > > like that), so I tried removing `build/` dir completely and
> > > > `find -
> > > > type
> > > > f -name "*.elc" -delete` but it didn't help. 🤷
> > > 
> > > Did you try make bootstrap?
> > 
> > Nope.
> 
> Why not?

Just did, worked out fine, thanks.

The reason was that I didn't remember what `make bootstrap` does. Over
a year I contribute to dozens of unrelated projects in different langs
and with different build systems. So understandably after some time I
forget things I worked on. E.g. I remember what change-log-mode is
about after sending an email that I don't get what it does, but it took
some time for memories of working with it to flow up.

> > I think if I remove the repo completely, the error will go away,
> > because that's how it usually works with that kind of errors. But
> > IMO
> > this is a bug in build system, because build system should handle
> > rebuilds without any kind of cleaning or removing specific files.
> 
> As already abundantly explained in the past, there are valid reasons
> for us not to reach that ideal in 100% of cases.  That's why when a
> build fails, the Makefile suggests "make bootstrap".  To make
> shortcuts, you need to know many intimate details of how Emacs is
> built and how it works, and we don't expect that from casual
> builders.

Based on past discussions I don't think I could convince you, but IMO
making sure build system works is more important than its performance.
The case we discuss here is a perfect example: I tried to help someone,
so was going to check on the problem and maybe try to bisect. But I
only have so much motivation. I don't want to fight build system. I
want to just be able to build (and before you say "use bootstrap", as I
mentioned in prev. paragraph, I need to remember the workaround when I
stumble upon the problem). So after I saw Emacs is unbuildable again,
and I tried a few workarounds I remember and it didn't work, wouldn't I
have sent the letter to ML, I'd have just dropped the ball.

It's not just me, that's how people work. You have some motivation +
spare time, and both get reduced with each problem you stumble upon.
For any project ecosystem it is important to reduce such unexpected
problems for contributors as much as possible. I'm certain Emacs may be
missing hundreds of improvements for the decades of its existence, that
people would've sent, but didn't because some similarly unrelated to
hacking problem was the last straw (build system is not the only
example, I can give others).

Regarding Makeilfes, I have some anecdotal experience: there's a
proprietary project I was working on as part of my job. Before me it
was using Makefiles, and despite people's efforts we frequently were
getting sporadic builds. Sometimes deps were executed in the wrong
order due to `-jX` (and we had a lot of them). Other times
removing/renaming a file would result in error about not having the
source file for `.o` one. This was coming up in CI, on local systems,
in chats… I think that took a lot of shared human-hours. Then I rewrote
it to Meson, and for the next 2 years can't remember even a single
build-system related failure (well, besides one, but not because of
Meson but because of mixed artifacts from makefile times). So much
saved human-hours in the years that passed and ones that to come…