From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66041: 30.0.50; Should 'flymake-note-echo' inherit from 'compilation-info'? Date: Mon, 25 Sep 2023 20:23:57 +0300 Message-ID: <83sf72180i.fsf@gnu.org> References: <1f9e98be-3248-56cf-b7fd-8301666675c6@gmail.com> <1e19cc18-9942-aa51-c49e-9441e873f037@gmail.com> <83edivg3rg.fsf@gnu.org> <83zg1jemi8.fsf@gnu.org> <8d01b781-abac-e22b-39fe-8697a173ad7a@gmail.com> <834jji35nc.fsf@gnu.org> <831qem316n.fsf@gnu.org> <83zg1a1kq9.fsf@gnu.org> <83v8by1gkr.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17465"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 25 19:25:08 2023 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 1qkpKW-0004Lp-8z for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 Sep 2023 19:25:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qkpKE-0004cs-AH; Mon, 25 Sep 2023 13:24:50 -0400 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 1qkpKD-0004cO-Gq for bug-gnu-emacs@gnu.org; Mon, 25 Sep 2023 13:24:49 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qkpKD-0004ln-8v for bug-gnu-emacs@gnu.org; Mon, 25 Sep 2023 13:24:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qkpKP-0002QP-NZ for bug-gnu-emacs@gnu.org; Mon, 25 Sep 2023 13:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 25 Sep 2023 17:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66041 X-GNU-PR-Package: emacs Original-Received: via spool by 66041-submit@debbugs.gnu.org id=B66041.16956626889296 (code B ref 66041); Mon, 25 Sep 2023 17:25:01 +0000 Original-Received: (at 66041) by debbugs.gnu.org; 25 Sep 2023 17:24:48 +0000 Original-Received: from localhost ([127.0.0.1]:46562 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkpKC-0002Pq-7B for submit@debbugs.gnu.org; Mon, 25 Sep 2023 13:24:48 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38268) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkpK8-0002PZ-Rk for 66041@debbugs.gnu.org; Mon, 25 Sep 2023 13:24:46 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qkpJr-0004jq-0V; Mon, 25 Sep 2023 13:24:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=jsX+zoyLOGXzivE61RCxhMSMr3Vb7ghrQ/qrUG3J2Ss=; b=VRXQDs8RyFX46MS3xCAn s9PAaggrVdU3KjDB2DQd29NgKmJAcF1qRYOfvO3dRm8Gah2s+FjLKgT4n+WsPpovzs/eU8Ws3bOVq b45YlnKYWlxE+kSIvmMt3Bej0IH5WcNMSbO4xroqqGu3yitpgEjTaWZtus4uBVlc8hysTMhhjHuGh kw66m4F+kgIQsgVEff0MrbfYlErm05e++biB8o+o4J/T0U6qNZk0znnVDd0ITPk2CgwcZBpaCmS7h rNZ9i3RxEXj7MBZlymL+ICRRekP8fIGb8IfoyY8i+LUxhOhoqtbYSxgxIj/KEXGdxnanCk+2y1kU6 AXUHDRaM42U9sQ==; In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Mon, 25 Sep 2023 17:55:45 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:271345 Archived-At: > From: João Távora > Date: Mon, 25 Sep 2023 17:55:45 +0100 > Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org > > > There's no built-in mechanism for the display engine to do that, and > > the fact that overlays are processed one by one in the order they are > > encountered doesn't help: when processing an overlay the display > > engine has no idea there are other overlays in the same screen line > > that will "compete" for the fringe display. > > Could it be changed, as it analyses a line, to keep a record of > which overlays have already touched the left fringe for that line > (and then clear this record as it moves on to other lines). The display engine does not analyze lines. It starts where it is told to start, and goes on, one buffer position at a time, until some other buffer position, where it was told to stop. To analyze lines means scan each line twice, and the apply some (as yet undefined) logic. > This would be easiest to implement if the the display doesn't > sometimes consider only a fraction of a line.I don't know if this > holds true. That happens in some situations, yes. > I assume it does, since otherwise that would mean that > if a line is scrolled near the beginning and truncated, the current > "last one" criteria you described before also doesn't always > hold true. The "last one" means the last overlay processed on a screen line. > IMHO this should be automatic and based on relative overlay > priorities. Overlay priorities are not for overlays that cover disjoint portions of text. Also, the same problem will happen when several 'display' properties that draw on the fringe are put on buffer text, without any overlays and thus without any priorities to begin with. So if we want to implement something like this in the display engine, we'd need to extend the format of the 'display' property in this case, adding some kind of "priority" there, or maybe extend the fringe bitmap data itself.