From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Eglot "inlay hints" landed Date: Thu, 23 Feb 2023 17:19:08 -0500 Message-ID: References: <83edqqaf8c.fsf@gnu.org> <2B284D77-97DF-4B3E-89FB-13F0CA93D240@gmail.com> <87356xv65z.fsf_-_@gmail.com> <83fsawriye.fsf@gnu.org> <835ybsr6aa.fsf@gnu.org> <83356wr224.fsf@gnu.org> <87bklktu89.fsf@gmail.com> <83y1oophd0.fsf@gnu.org> <83k008pah3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3381"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , dalal.chinmay.0101@gmail.com, emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 23 23:20:02 2023 Return-path: Envelope-to: ged-emacs-devel@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 1pVJwX-0000Ys-Qi for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Feb 2023 23:20:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVJvp-0004ea-LK; Thu, 23 Feb 2023 17:19:17 -0500 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 1pVJvo-0004eR-3p for emacs-devel@gnu.org; Thu, 23 Feb 2023 17:19:16 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVJvm-0006xN-9q; Thu, 23 Feb 2023 17:19:15 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1509C81110; Thu, 23 Feb 2023 17:19:12 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D106180F4E; Thu, 23 Feb 2023 17:19:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677190749; bh=pKFPyNO7r8NfRPvQO28LofnZll7+M3td3gYzr86YUf4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=joo4MeR6RiU5C6fJl8Q+DCC1TcsdXj5VPyYaQFJULj/17sTBstM7cQJUpcJgtDEnC T71ENxGc4fCMeTW5t3OGFLhHqJN3m2E6BFAkhk4vwz0YxPwRYnnjsHqVhkt2YOGbMm fta7gD5XlBy0nP/GEwK4Kce1ZmprgRXFkxs35lqCNs6mVEjKtuAQTOEXC9XR4XfLR4 dzmQy5AjB+gE858z/o3drRL/r0zwbw3MYn3J4KrisCETZy7wGHeQ/wFYuPyUd87W2C E9gq6XDHnZ52QsZcKubElwQHBIgUVCk8lKojrnVr/X/G5odN28czSVfy1nZPlI6hry lG3N4hTjQwVnA== Original-Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5E0971212CB; Thu, 23 Feb 2023 17:19:09 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Thu, 23 Feb 2023 20:09:28 +0000") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:303723 Archived-At: > Mostly the fact that it's operating on a separate timer, but one > that is directly correlated to jit-lock-context-time. But that's because you're willing to wait for the context refresh to do your own. > So the bookkeeping and the coalescing of the small+large jit chunks > should be provided by the jit infrastructure instead. So far, you're the first to need such a thing. In my experience the needs for "jit display refresh" can be fairly subtly different, so it's not clear how generally useful your approach would be. Maybe we could provide some shared infrastructure to maintain a "coalescing set of buffer regions", but if so, I suspect that it wouldn't need to be tied to `jit-lock.el`. Also, I'm not sure it gives exactly the info you need/want: I suspect that in some languages you can have: foo (x) ... function foo (bar : Int) so that changing the `foo` definition will need to update the inlay on the call to `foo` that is earlier in the buffer, hence jit-lock-context refresh won't be sufficient and you'll need to force your own refresh. [ I think jit-lock would benefit from being able to flush a particular backend's without forcing all of the backends at the sane time. ] > And then no extra timer or logic would be needed. You mean you'd integrate it into `jit-lock-context`? Maybe that could be done. > Can we make jit-lock.el a :core ELPA package? I have no opinion on that. Stefan