From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#66041: 30.0.50; Should 'flymake-note-echo' inherit from 'compilation-info'? Date: Mon, 18 Sep 2023 19:55:00 +0100 Message-ID: References: <1f9e98be-3248-56cf-b7fd-8301666675c6@gmail.com> <1e19cc18-9942-aa51-c49e-9441e873f037@gmail.com> <83edivg3rg.fsf@gnu.org> <83zg1jemi8.fsf@gnu.org> <83sf7beemv.fsf@gnu.org> <83edive6eu.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="37506"; mail-complaints-to="usenet@ciao.gmane.io" Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 18 20:56:05 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 1qiJPg-0009Uz-Qq for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Sep 2023 20:56:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiJPX-0006fO-9A; Mon, 18 Sep 2023 14:55:55 -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 1qiJPV-0006f0-R0 for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 14:55:53 -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 1qiJPV-0006bC-JM for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 14:55:53 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qiJPd-0003qD-Lc for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 14:56:01 -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: Mon, 18 Sep 2023 18:56: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.169506333714700 (code B ref 66041); Mon, 18 Sep 2023 18:56:01 +0000 Original-Received: (at 66041) by debbugs.gnu.org; 18 Sep 2023 18:55:37 +0000 Original-Received: from localhost ([127.0.0.1]:54555 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiJPF-0003p2-CR for submit@debbugs.gnu.org; Mon, 18 Sep 2023 14:55:37 -0400 Original-Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]:42429) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiJP4-0003ob-9Y for 66041@debbugs.gnu.org; Mon, 18 Sep 2023 14:55:36 -0400 Original-Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-500bbe3ef0eso5738064e87.1 for <66041@debbugs.gnu.org>; Mon, 18 Sep 2023 11:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695063312; x=1695668112; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=c6XBfUMuMoJTkusY1XIpbXp83P6U41KJBpqmqAkI4W4=; b=LivSO2Nr/XwXVJYDXESCENOLv/3Mo2XSTJGiQ6cZrd3iUCraD1RjLjrJUPmhpzzbOQ dlcz0tF7RZZwEiiZf3HvfuXEDomMK4SCOlVg93iMpJXBEsXHbGnTt6v5r95Wx4SFSGEa 97g8qiNSfq9fn+Rjt4EeXPWcRLXu4FVSAcAjQbBJS3UbAvaVao48xtyFWDQL1HKysw47 DCkq97ZG4TUgcpWajZVRirRU66aq2jw/f6pUSkkW1U0mXhU/NZNnmOEP6MEAF4hKiTN8 tfaFpBXJYJm+O/sYf8Sawvll1G/oizCXh5fR6yXus0HdwvQ2LyisiJLMKWF/0/8gWsQ7 CXKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695063312; x=1695668112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c6XBfUMuMoJTkusY1XIpbXp83P6U41KJBpqmqAkI4W4=; b=jDmhAEbh8tpNRyIJShQ1fdrctb3Gauq6jdrA6+km6b1VhXYVYWcg9qnzVBZYvR0jAP qoomovjhDKBlIoygPBRjz2ufYWYJzYI02EPff1CxtxhWS1HQkVKEYFAIVqKzaAID/jmh QNgcX/Dts3kA4S4Lr3GBJhbGJIiNKdd43Ge6YAPMOTAlBsiJ1377QB5SG2A1Ln5NF6UB vU4elkq9D8xEKZPnSHWD7FK74Z3YqwVznQz0B+5mIQS86kNSZsH+k2IdNk2A7hGyZlP0 BOCP0IrvWbkEiWc3XPbOvmqJbcuMmpWZEkLilrjxWXG6v7IALgEdT7BFkZrGEB05085L ZI8w== X-Gm-Message-State: AOJu0YzfgZcKD/4RNIia/NDrOYFFzNTM8+lk2qMWvyViov2qaD6sA8Zz csiL9GPUTPfsE2zqtAFhmAYdVuBz1Zyv9XISnp/OFBNUGDiJZA== X-Google-Smtp-Source: AGHT+IEW5+sU4+0JrjOCgUW5R2gvpFb2c0xIWtu5HhHJYpjCZGywHyr0oGAanV+rKtiOW30uaF307b/0NwLUGyGCrbo= X-Received: by 2002:a05:6512:28f:b0:4f8:6d9d:abe0 with SMTP id j15-20020a056512028f00b004f86d9dabe0mr188038lfp.33.1695063311598; Mon, 18 Sep 2023 11:55:11 -0700 (PDT) In-Reply-To: <83edive6eu.fsf@gnu.org> 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:270840 Archived-At: On Mon, Sep 18, 2023 at 6:29=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Mon, 18 Sep 2023 16:31:45 +0100 > > Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org > > > > On Mon, Sep 18, 2023 at 3:32=E2=80=AFPM Eli Zaretskii wr= ote: > > > > > > I guess you want the cursor on the first character of the > > > overlay-string that is displayed first (leftmost)? Are you asking ho= w > > > to implement this when there are more than one overlay at EOB? > > > > Yes, a direct answer to that question would be nice to know, too. > > Give your overlays different priorities, and use (cursor t) only in > the overlay of the highest priority. If they all have before-string > (which is what I saw in the example), then priority will determine > which overlay is processed first (and thus displayed first). > > > The idea is to have multiple bits of diagnostic text displayed > > after the end-of-line each related to a source overlay contained > > within that line. The idea of the feature is that source overlay > > and eol text are linked. If the source overlay is deleted, the > > end-of-line should disappear. > > > > It's similar to what happens with a simple 'after-string' overlay > > property, but with the 'after-string' skipping over all characters > > until the end of line. > > > > Currently, I'm doing this with a single "end-of-line" overlay placed > > as I explained properly (modulo bugs like this one, of course, since > > I intended a single overlay but unexpectedly got two). It's this > > second end-of-line overlay which has an 'after-string' property. I use > > after change functions to control the value of this property, so that > > if a source overlays gets destroyed, the corresponding text in value > > is deleted (and eventually also > > > > But I could probably use multiple end-of-line overlays, with a > > one-to-one correspondence to the source overlays. I've tried that too > > but abandoned it for difficulty in placing the cursor (similar problem > > to this one). > > > > And I think I tried an overlay modification hook instead of buffer afte= r > > change functions and abandoned it too for some reason. Maybe the > > modification hook isn't called at all when the overlay is completely > > deleted? > > > > Or, conceivably, it could be done without end-of-line overlays at all, > > if somehow a 'eol-string' property similar to 'after-string' was > > implemented in the C code. But I would prefer a Lisp solution, of > > course. > > > > So, in summary, there is a fair bit of design space for this feature > > (which exists in VS code, btw) and I wanted to know your thoughts > > on these possibilities and my decisions. > > Is placing the cursor the only problem you need to solve? No. It's one of them. The other main problem is that the display-only string carried by the overlay needs to react quickly to deletions of the "source overlays" that span ranges of characters in the line to the left (or to the right, if writing in the opposite direction, but I hope you get what I mean). > And do I understand correctly that you normally collect all the > diagnostics into a single sting, and display it as a single overlay > string? For purposes of the "end of line" overlay, yes. Max one per line. That was the intent at least. But it seemingly failed here, so we got two for that first line. However there are more overlays. These "end of line" overlays only appear once you activate flymake-show-diagnostics-at-end-of-line. But Flymake uses other overlays to underline and propertize the actual text that originated the diagnostic "inside the line". These I call the "source overlays": they are the source of truth for the diagnostic information and its their deletion that should immediately trigger an update of the "end of line" overlay text. Jo=C3=A3o