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.devel Subject: Re: Eglot "inlay hints" landed Date: Thu, 23 Feb 2023 14:36:35 +0200 Message-ID: <83356wr224.fsf@gnu.org> References: <83edqqaf8c.fsf@gnu.org> <2B284D77-97DF-4B3E-89FB-13F0CA93D240@gmail.com> <87356xv65z.fsf_-_@gmail.com> <83fsawriye.fsf@gnu.org> <835ybsr6aa.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="11011"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dalal.chinmay.0101@gmail.com, emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 23 13:37:18 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 1pVAqb-0002dQ-Sh for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Feb 2023 13:37:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVAq2-0004F5-95; Thu, 23 Feb 2023 07:36:42 -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 1pVAq0-0004Eg-6Q for emacs-devel@gnu.org; Thu, 23 Feb 2023 07:36:40 -0500 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 1pVApz-0000Qg-Qw; Thu, 23 Feb 2023 07:36:39 -0500 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=ohm7h0K3VUymhf9Mn7nUEmn1QMlk+vUoZ88qllkrxpU=; b=X/+0yLqh5LFIurFSh2U4 j8WvHChLz9ND73v95sv+f0EXPY/4z03vIfahhAeROSqEZkiWEKC5MNqcZadXgniSP7T1TuA0YjRBm qNQoi3HpYPvexSDzZYg6+BYbTrOm2hHhsN5VZVqpAZ/xA66YCSpEoonpWr/q5crXr+clYpsotJBBa MzRmpujT/trEjkkSCCZFo3E2+quXY8o1OKB9xAA7ol4TiO7Z2ztC0o3+67k0SiTiF4I+jeNvmm7s7 EHx7MEdLSGfnFy7OFF2ETPmqH9jZ2W8IzGniK0ObwMjkUbUrVuglwdmihP6mh4uCP0ahKeQqRC50k XWi1AjmLdGSiIg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pVApz-00043Y-8p; Thu, 23 Feb 2023 07:36:39 -0500 In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 23 Feb 2023 11:23:40 +0000) 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:303702 Archived-At: > From: João Távora > Date: Thu, 23 Feb 2023 11:23:40 +0000 > Cc: Chinmay Dalal , emacs-devel@gnu.org, > dimitri@belopopsky.com, luangruo@yahoo.com > > On Thu, Feb 23, 2023 at 11:05 AM Eli Zaretskii wrote: > > > > > Eli Zaretskii writes: > > > > > > >> Can it be instead done in such a way that initially (when loading a new > > > >> file) they are requested for the whole buffer, then on subsequent > > > >> changes they are only requested for the visible regions. > > > > > > > > Why would we want that? > > > > > > It will solve this problem: > > > > > > >> > When > > > >> > scrolling a window, it may take a short amount of time for inlay hints > > > >> > to "pop in". > > > > So would using jit-lock-register, which was proposed here. > > The "pop-in" delay is just a function of the intentional > bandwidth-conserving timer delay + the normal LSP interprocess > communication delay. Any jit/lazy Emacs-side solution > is going to have to deal at least with the second addend of > that sum. I don't understand: using jit-lock-register just means your code is called via jit-lock's fontification-functions instead of window-scroll-functions that you used. Any problems with LSP delays that you deal with in the latter should be possible in the former as well, no? Or what am I missing? The advantages of using jit-lock are that (a) it is more accurate in telling you which parts of the buffer are about to be displayed, and (b) it is much more reliable, because window-scroll-functions are not necessarily called when something changes on display. For example, we lately discovered that pixel-scroll-precision-mode doesn't call window-scroll-functions. > jit-lock-register was unknown to me. It seems to rely on some > heuristic to know what regions need to be "refontified". It isn't a heuristic. jit-lock is called from the display engine, which always has a pretty good idea which parts of the buffer it needs to show on the screen. > I wonder if the heuristic will be accurate for inlay hints, since > changing void foo(int bar){...} to void foo(int baz){...} in one > part of the buffer doesn't usually change the fontification of the > rest of the buffer. The display engine doesn't know which parts will be affected by the change, it only knowes what's on display and what isn't. The function called via fontification-functions are supposed to know their job, and look at the parts of the buffer according to their needs; jit-lock just gives them a hint in the form of the region of the buffer it wants to display. > In fact the invalidation impact is not just in the same buffer, > but potentially all other buffers (all the ones where a call to > 'foo' is found). Eglot's inlay hints implementation doesn't > handle this edge case. Though I don't think it would be > extremely hard to, it doesn't seem extremely relevant for what > is usually a "best effort" helper feature from the LSP side. We don't need to make the overlays until the buffer is shown in some window, right?