From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: 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 Date: Fri, 03 Jan 2025 18:19:26 +0300 Message-ID: <162d62ff75d7ad4515724870248a1896c8bed82f.camel@yandex.ru> References: <87h66gcuxk.fsf@gmail.com> <809895537e1e07fca05e124a4741f2de8e0cc080.camel@yandex.ru> <8c0f6726a535fdb203907ee0a105a9cc72861ca1.camel@yandex.ru> <86ldvsglpm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18450"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.54.2 Cc: stefankangas@gmail.com, execvy@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 03 16:20:18 2025 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tTjTG-0004cm-1i for ged-emacs-devel@m.gmane-mx.org; Fri, 03 Jan 2025 16:20:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTjSe-00048A-AS; Fri, 03 Jan 2025 10:19:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTjSb-00047z-JK for emacs-devel@gnu.org; Fri, 03 Jan 2025 10:19:37 -0500 Original-Received: from forward501a.mail.yandex.net ([2a02:6b8:c0e:500:1:45:d181:d501]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTjSX-00006s-DT; Fri, 03 Jan 2025 10:19:37 -0500 Original-Received: from mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:9e27:0:640:a9d8:0]) by forward501a.mail.yandex.net (Yandex) with ESMTPS id 9FC2B6105E; Fri, 3 Jan 2025 18:19:27 +0300 (MSK) Original-Received: by mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id QJjT1GQOpCg0-ocWCxOfb; Fri, 03 Jan 2025 18:19:27 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1735917567; bh=eHTzWjti423eNycwtPxFRrLJHgj8gXXPKl0OUtDJK3w=; h=References:Date:In-Reply-To:Cc:To:From:Subject:Message-ID; b=hkvm6tKTjkP2JnpxNtawKrYjcBYORXX1k8izqW0x8+oDrE4F6wGxK4UNGnqAzpX8x vVwFNYoU2ww/d05ePmTL/Ba3u4vctH63AorwNc8nbF6ciQkHKdGSaWoY+qMjE1XVMj gZuXpTNe7RCBTj+kp0VM1N2rhwNoanyBKGwc3Lg0= Authentication-Results: mail-nwsmtp-smtp-production-main-17.iva.yp-c.yandex.net; dkim=pass header.i=@yandex.ru In-Reply-To: <86ldvsglpm.fsf@gnu.org> Received-SPF: pass client-ip=2a02:6b8:c0e:500:1:45:d181:d501; envelope-from=Hi-Angel@yandex.ru; helo=forward501a.mail.yandex.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327629 Archived-At: On Fri, 2025-01-03 at 13:50 +0200, Eli Zaretskii wrote: > > From: Konstantin Kharlamov > > Date: Fri, 03 Jan 2025 12:31:23 +0300 > >=20 > > On Fri, 2025-01-03 at 03:21 -0600, Stefan Kangas wrote: > > > Konstantin Kharlamov writes: > > >=20 > > > > On Fri, 2025-01-03 at 13:45 +0800, Eval EXEC wrote: > > > > > Hello, I am building Emacs from source, and I=E2=80=99ve noticed > > > > > something > > > > > unusual. Line numbers appear in my rg and xref buffers, but > > > > > they > > > > > disappear after approximately 100ms. This happens even though > > > > > I=E2=80=99ve > > > > > only > > > > > configured display-line-number-mode to be enabled in prog- > > > > > mode > > > > > via an > > > > > add-hook. > > > > >=20 > > > > > Has there been any recent change in the code related to > > > > > display- > > > > > line- > > > > > number-mode that might explain this behavior? > > > > >=20 > > > > > Thank you for your help! > > > >=20 > > > > FWIW, I just tried building Emacs from latest commit to look at > > > > it, > > > > but > > > > it doesn't even build with `Error: void-function (rx)`. > > > >=20 > > > > 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. =F0=9F=A4=B7 > > >=20 > > > Did you try make bootstrap? > >=20 > > Nope. >=20 > 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. >=20 > As already abundantly explained in the past, there are valid reasons > for us not to reach that ideal in 100% of cases.=C2=A0 That's why when a > build fails, the Makefile suggests "make bootstrap".=C2=A0 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=E2=80=A6 I think that took a lot of shared human-hours. Then I rew= rote 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=E2=80=A6