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 15:49:18 +0300 Message-ID: <83zg1a1kq9.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> 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="28505"; 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 15:07:55 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 1qklJa-0007Bp-Kf for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 25 Sep 2023 15:07:54 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qkl37-0006hp-GS; Mon, 25 Sep 2023 08:50:53 -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 1qkl34-0006hT-Nw for bug-gnu-emacs@gnu.org; Mon, 25 Sep 2023 08:50:51 -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 1qkl33-0001CX-Lj for bug-gnu-emacs@gnu.org; Mon, 25 Sep 2023 08:50:50 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qkl3G-0008Pw-03 for bug-gnu-emacs@gnu.org; Mon, 25 Sep 2023 08:51:02 -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 12:51: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.169564623132317 (code B ref 66041); Mon, 25 Sep 2023 12:51:01 +0000 Original-Received: (at 66041) by debbugs.gnu.org; 25 Sep 2023 12:50:31 +0000 Original-Received: from localhost ([127.0.0.1]:44543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkl2k-0008PA-V4 for submit@debbugs.gnu.org; Mon, 25 Sep 2023 08:50:31 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56634) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qkl2e-0008Op-RJ for 66041@debbugs.gnu.org; Mon, 25 Sep 2023 08:50:28 -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 1qkl2L-000136-7n; Mon, 25 Sep 2023 08:50:06 -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=c6G5HOUf/tn4xAmdPMp60UZY0McStIEkQ3oHcC6FMxo=; b=i4+Ewwa8Hkkgzjz4OFi8 dcrw9dAXhCHpPEph0ExtFJWVknebWMBgpEXGPngdkIZgG+8a3lCT3EkrIBXVwJzZfkSARBs2zqPhj IcsJRLtI7Ye9tTNlCTfeiz1pQpqgeZhg0qCQ9FQXGkrlToJ38WNSmDjLfydNibGcH6WiRghg0l5DF dkR4iYztA7T0bMSfbhnY9ip9+oTlNXmUJL+WtM75ofEdYtuwtakZ22lr3PXwOX0UF0qsI83vsCXtM kGwCQq4/OsUF1sU7g/MMF/lnR6++OBla14ta6kGnQLIvMqmyZiT4nL0oDRhaiZHkEralDHpAeEcDT dUp+JuAxKzw2GQ==; In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Mon, 25 Sep 2023 13:12:50 +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:271332 Archived-At: > From: João Távora > Date: Mon, 25 Sep 2023 13:12:50 +0100 > Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org > > On Mon, Sep 25, 2023 at 1:09 PM Eli Zaretskii wrote: > > > > > From: João Távora > > > Date: Mon, 25 Sep 2023 12:46:35 +0100 > > > Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org > > > > > > On Mon, Sep 25, 2023 at 11:32 AM Eli Zaretskii wrote: > > > > > > > Add some character after the SPC, even a newline, and the display will > > > > be as you expect. > > > > > > I think that's only because this newline will, by default, delete the SPC > > > character and thus resolve the diagnostic from checkdoc, deleting the > > > overlay. > > > > No, because if you insert any other character after the space, the > > display will also be as you expect. > > Obviously, because any other character which is not space > will _also_ fix the trailing whitespace diagnostic issued by the > checkdoc backend. By definition :-) OK, let's back up a notch, because I think I've misunderstood you. What you have here are two separate overlays, each with a before-string. The overlays cover two completely disjoint portions of buffer text: 1 to 6 for the first overlay, 6 to 7 for the second. Now, priorities are only relevant for overlays that cover overlapping portions of text. In your case, there's no overlap, so both overlays will be displayed. Try this variant: (let (ov) (setq ov (make-overlay 1 6)) (overlay-put ov 'before-string "B1") (overlay-put ov 'priority 42) (setq ov (make-overlay 6 7)) (overlay-put ov 'before-string "B2") (overlay-put ov 'priority 41)) You will see that "B1" is displayed before "hello" and "B2" is displayed before the space that follows "hello", like this: B1helloB2 Both overlays show on display regardless of their priorities. Right? That is exactly what happens in your case: both overlays are displayed. Except that in your case the before-strings have a 'display' property on them, whose value draws a bitmap on the fringe, instead of showing the string itself in the text-area. What Emacs does is again display both overlays, both of which draw a bitmap on the same fringe, so what you see is the bitmap which is drawn last. Because when some 'display' property draws on the fringe, we draw it unconditionally, regardless of priorities etc. So the last bitmap drawn on the fringe "wins". And since the display engine processes overlays in the order of buffer positions (for left-to-right text), the overlay that wins is always the last one. Does this explain what happens?