From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#40529: 26.3; global-display-line-numbers-mode and flymake-show-diagnostics-buffer error Date: Sun, 12 Apr 2020 17:58:16 +0100 Message-ID: References: <83v9m7n98j.fsf@gnu.org> <83r1wvmt7k.fsf@gnu.org> <83ftdbmjan.fsf@gnu.org> <837dyklszu.fsf@gnu.org> <833698lq9o.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000013c3d805a31ae059" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="121949"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 40529@debbugs.gnu.org, Aidan Beggs To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 12 18:59:27 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1jNfx9-000VZ5-Hw for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Apr 2020 18:59:27 +0200 Original-Received: from localhost ([::1]:35220 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNfx8-0001FI-L2 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Apr 2020 12:59:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46770) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNfwn-00011R-C4 for bug-gnu-emacs@gnu.org; Sun, 12 Apr 2020 12:59:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNfwl-0003Y9-FI for bug-gnu-emacs@gnu.org; Sun, 12 Apr 2020 12:59:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47189) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jNfwk-0003XE-9W for bug-gnu-emacs@gnu.org; Sun, 12 Apr 2020 12:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jNfwk-0005bF-9x for bug-gnu-emacs@gnu.org; Sun, 12 Apr 2020 12:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Apr 2020 16:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 40529 X-GNU-PR-Package: emacs Original-Received: via spool by 40529-submit@debbugs.gnu.org id=B40529.158671071421488 (code B ref 40529); Sun, 12 Apr 2020 16:59:02 +0000 Original-Received: (at 40529) by debbugs.gnu.org; 12 Apr 2020 16:58:34 +0000 Original-Received: from localhost ([127.0.0.1]:58735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jNfwI-0005aV-4s for submit@debbugs.gnu.org; Sun, 12 Apr 2020 12:58:34 -0400 Original-Received: from mail-il1-f172.google.com ([209.85.166.172]:36929) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jNfwH-0005aH-4X for 40529@debbugs.gnu.org; Sun, 12 Apr 2020 12:58:33 -0400 Original-Received: by mail-il1-f172.google.com with SMTP id e4so4295050ils.4 for <40529@debbugs.gnu.org>; Sun, 12 Apr 2020 09:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rzsf1p3eLpDEano0uult3UaQfYyPZ+w6dTf1YKyN5pY=; b=HWwTlA6MWIrFQb4bCjNP8Cu/MuFAZ7ussdu4UdeLsH0bYaSvXnAj5CF0ve+nNObaXk XfesHqW53Q8WAs6IaP+uX3zMgWxKc3kWznheeRIDhh5cgCnJyPZZzDtjgmRiifUjv4mJ Qr2qET09Zv8i27u8ctkR3FYYrcT9qZywrIWBKMeTkUOWYFykOn+w0/MFA9cGcFrBndVX WaEpC3vimvcNuGdbgjJwrNyvEHdoJ5+mz2kDa1Dc3aRKCkAd3VvMjuArmxh8GNigrek0 ubX51L0+qMx0ekjr3gMz6pqIg8qMEkTEYfbe9DvRtYN1E3fonT30LjJdkuH3LDYVqy+W Zwwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rzsf1p3eLpDEano0uult3UaQfYyPZ+w6dTf1YKyN5pY=; b=nY6PBphzX4IsjzAhWLarVOEz7oHycIKoC014EVq4Tn3oiJx888FVchDH5ymbnMYwPQ n1QjtDtNrwhvD1fmYMSWR1KA9Xqqkuc6QxvAwzvxe/ODfB73cEUndBbNwkx/s9dHT7Mr 2jb+69PuoxL2tJyoTroKNwmj3Uvj/81maK/S1OIzzAq7u6P11wTM54cAqFDYW5wzKELJ 9U/1EuEzQPwL77ruyG3VR/30q/ewQPVco2BeK7havOCOxJ8vMrlhfXms73vQOnvc2TCn av5Wc+JAVq8Tg+RxQgaappMPZcGh6J6nEaiuoyH2l7ReRR+x8Gre9roOdtlIhM82eYvY quNQ== X-Gm-Message-State: AGi0PuaGRkDpp0ZmJaz6GgVvnqkR4aILvwoMNw41zozkUz9HWuj8k5He CJR9HrWzN3Scdj8HN0neRXfNe+UVnLyujUl/wrs= X-Google-Smtp-Source: APiQypK9ffHZ1xj5Xa2UUGQAte4YuHD7EzCynXn435wIQbCagA/xWE2OkwhrJKuipsv8Oyl6BcSvm59EoYNgs02oy/s= X-Received: by 2002:a92:ce8b:: with SMTP id r11mr13779833ilo.199.1586710707420; Sun, 12 Apr 2020 09:58:27 -0700 (PDT) In-Reply-To: <833698lq9o.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178259 Archived-At: --00000000000013c3d805a31ae059 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 12, 2020 at 3:42 PM Eli Zaretskii wrote: > AFAIR, the :align-to display spec needs to be recalculated when line > numbers are turned on or off. I don't know what that is, but if it involves propertizing the rows themselves, there's possiblya bug when you gain or lose a character when scrolling. As evidenced by the fact that the hooks I showed you also only recalculate the header. > The code was introduced to solve real problems in some users of > tabulated-list-mode (and we have quite a few of them in core alone). Do you have reason to believe these would resurface if you did my change? What are these "real problems"? Can references to them be found in the git log? > Maybe so, but that code endured many months on the master branch and > then in the pretest, so we have some reason to believe it is correct. I don't think it's correct to ask the buffer's row-providing backend to produce rows just you turned on the mode. Certainly I can't think how it can be correct to do that depending on whether or not a totally unrelated customization related to presentation is enabled or not. If you disagree, I would at least indicate this possibility in the manual before releasing. The manual says, in https://www.gnu.org/software/emacs/manual/html_node/elisp/Tabulated-List-Mo= de.html The listing command should create or switch to a buffer, turn on the derived mode, specify the tabulated data, and finally call tabulated-list-print to populate the buffer. Maybe you should add something explaining that sometimes populating happens automatically, sometimes not. If gathering the data is expensive, the client code can be doing it twice, a bad thing IMO. But even conceptually and intuitively, changing the line numbers to the left of a buffer shouldn't need recalculating the buffer's contents. Even the effect on the header line smells a little, to be honest. Shouldn't line numbers care to handle also push the header line forward as they do the remainder of the buffer? I don't know and I don't use line numbers, just wondering. > I'm sure a simple solution for Flymake can be found. E.g., what about > skipping the entire body of flymake--diagnostics-buffer-entries if > flymake--diagnostics-buffer-source is nil Maybe that works, yes. Feel free to try it and commit it to Emacs 27, I have little time and I'm booted into a machine with no Emacs. Thanks, Jo=C3=A3o --00000000000013c3d805a31ae059 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Apr 12, 2020 at 3:42 PM Eli Zaretskii <eliz@gnu.org> wrote:

> AFAIR, the :align-to display spec needs to be recalculated when line<= br>> numbers are turned on or off.

I don't know what that is, but if it involves propertizing=
the rows themselves, there's possib= lya bug when you gain
or los= e a character when scrolling. As evidenced by the fact
that the hooks I showed you also only recalculat= e the header.

> The code was introduced to solve real problems in= some users of
> tabulated-list-mode (and we have quite a few of= them in core alone).

Do you have reason to believ= e these would resurface if you
did my change? What are these &quo= t;real problems"?=C2=A0 Can
references to them be found= in the git log?

> Maybe so, but that code = endured many months on the master branch and
> then in the pretest, s= o we have some reason to believe it is correct.

I don't think it's correct to ask the buffer's row-providing=
backend to produce rows just you turned on the mode.=C2=A0 =
Certainly I can't think how it can be correct to do that= depending
on whether or not a totally unrelated customization re= lated to
presentation is enabled or not.

If you disagree, I would at least indicate this possibility in
the manual before releasing.

The manual s= ays, in

=
=C2=A0=C2=A0 The listing command should create or switch to a
=C2=A0=C2=A0 buffer, turn on the derived mode, specify the tabulated= data,
=C2=A0=C2=A0 and finally call tabulated-list-print to populate the buffer.
=

Maybe you should add something explaining that so= metimes
populating happens automatically, sometimes not.=C2=A0 If= gathering
the data is expensive, the client code can be doing it= twice,
a bad thing IMO.

But even c= onceptually and intuitively, changing the line numbers
to th= e left of a buffer shouldn't need recalculating the buffer's
contents. Even the effect on the header line smells a little, to <= br>
be honest. Shouldn't line numbers care to handle also pus= h
the header line forward as they do the remainder of the buffer?=
I don't know and I don't use line numbers, just wonderin= g.

> I'm sure a simple solution f= or Flymake can be found.=C2=A0 E.g., what about
> skipping the entire= body of flymake--diagnostics-buffer-entries if
> flymake--diagn= ostics-buffer-source is nil

Maybe that works, yes.= Feel free to try it and commit it
to Emacs 27, I have littl= e time and I'm booted into a machine
with no Emacs.

Thanks,
Jo=C3=A3o
--00000000000013c3d805a31ae059--