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 16:31:45 +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> 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="19255"; 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 17:30:50 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 1qiGD4-0004nT-69 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 18 Sep 2023 17:30:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qiGCF-0001If-Ja; Mon, 18 Sep 2023 11:29:59 -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 1qiGCB-0001Ea-5f for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 11:29:55 -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 1qiGCA-0004as-1M for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 11:29:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qiGCI-0000WO-6A for bug-gnu-emacs@gnu.org; Mon, 18 Sep 2023 11:30: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: Mon, 18 Sep 2023 15:30:02 +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.16950509631919 (code B ref 66041); Mon, 18 Sep 2023 15:30:02 +0000 Original-Received: (at 66041) by debbugs.gnu.org; 18 Sep 2023 15:29:23 +0000 Original-Received: from localhost ([127.0.0.1]:54113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiGBf-0000Ut-72 for submit@debbugs.gnu.org; Mon, 18 Sep 2023 11:29:23 -0400 Original-Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]:50299) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qiGBd-0000Ue-J0 for 66041@debbugs.gnu.org; Mon, 18 Sep 2023 11:29:22 -0400 Original-Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5007abb15e9so7716646e87.0 for <66041@debbugs.gnu.org>; Mon, 18 Sep 2023 08:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695050947; x=1695655747; 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=jhaDthE8q+AP/9DQVTD01G7D991ilLI5lQSxGhbuWe4=; b=mvFUjB1pyVWTp5vwUqIlv/1FJBmN/aj7P3ns82w4Fgu11tCYicEha59Q/qh0iWdEuP Hgl+RuSkie0lcSzsnZr2BtLl10LUqElAqzUTGJUpUagwEOc6pMAFw+Qo3IHnghyFmK15 8jRZFia55BDZBvioT8WgGd9ngOMeKDsDi1eQWjy6hyftZMEpBO1Vc5Q3vOOVPL+WLWfP CWF776+xRrlvtFcAMxveaMQTsFkHbMswe28L3uEQD77A/fWEn6aSYQyuJqpT8lMvS7ne jDOHBPREUWJ9g3TstwrRblNVxxxGj/SVllhD8j1f+Ut1Ke7ZxgGy+E1PDLIkto0iGR9y gh6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695050947; x=1695655747; 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=jhaDthE8q+AP/9DQVTD01G7D991ilLI5lQSxGhbuWe4=; b=aJH+WNke1tUlzBYXEadAqdOgS0ZOk0IdsbaXhFz4f6l7pezUtDzxJqIvzphOpnwqeR 1fyc1Sd81bkaX44u37bJrOeNlT9jhf++h5BWcMx9IpKb9fGBk8DBCTtTIXJgZgrr8bAl ar2EGPCdrCkOh6n+5N5x0zrYQ1ySFDnpejltwSZdywSG2hGwIjvKhZCA6hfI0lzF+u5h qH5/qs4LpmV1HmAnACNWSBJHXyuUGp3605BsvWvoC7XHEG7o3btXPeQHGH6umN6JtSCT wUlYEzkeN89af2rmMugnJPKCR7APxXQk6cJMdb7fu0wq+B1WgbWpShB+UQyDKYGaQBwF ruJA== X-Gm-Message-State: AOJu0YxldcheSbS3dbvh6VscCq3cIQZ9+8wiWJJCS1Cn9TYuwd84ZLVu ljg6TwVttM6+zUktBp9jg0rpFf1BqU6EqNQ+9G8= X-Google-Smtp-Source: AGHT+IFOWWhrMimS7i87pGKcp9ZumSMmryrejvf0kozj8+fk/2SrdsLTX43LmTq4RQU6Jb71LrcFzNjtKVb5+qeX6eE= X-Received: by 2002:a19:ca06:0:b0:503:6e8:1008 with SMTP id a6-20020a19ca06000000b0050306e81008mr4171596lfg.36.1695050947098; Mon, 18 Sep 2023 08:29:07 -0700 (PDT) In-Reply-To: <83sf7beemv.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:270816 Archived-At: On Mon, Sep 18, 2023 at 3:32=E2=80=AFPM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Mon, 18 Sep 2023 13:52:06 +0100 > > Cc: jporterbugs@gmail.com, 66041@debbugs.gnu.org > > > > On Mon, Sep 18, 2023 at 12:42=E2=80=AFPM Eli Zaretskii w= rote: > > > > > > You have there two overlays, each one with a before-string, and each > > > string has its first character propertized with (cursor t). So Emacs > > > picks up one of the two overlay strings to place the cursor, and it > > > just happens to be not the one you wanted. > > > > Yes, something like that. Skimming the code, I think I meant for only > > one overlay, not two, to be the end-of-line overlay containing the two > > strings. But this was tricky to implement and I probably missed an > > edge case. There is a FIXME there, have to investigate. > > > > Anyway, since I have your interest, any suggestions on how you would > > implement this? Knowing that this feature is upposed to display > > multiple pieces of relatively short cursor-unreachable text visually > > after the end -of-line (the text being the diagnostic text, naturally). > > I guess you want the cursor on the first character of the > overlay-string that is displayed first (leftmost)? Are you asking how > 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. > > Currently I'm placing them exactly between (line-end-position) and the > > character after that. There is a link between this eol overlay and > > the origin diagnostic. If you delete the latter, the former should > > be recalculated asap, i.e. it should ideally not wait another 1s or two > > before Flymake re-contacts the backend for up-to-date info. > > This seems to hint that you are talking about something different, so > maybe I misunderstand what you mean by "implement this" above? By my question, I just meant that I'm interested in hearing what approach you would take to solve this problem. Let me write a bit more. 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 after 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. Jo=C3=A3o