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 14:27:57 -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="25518"; 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 20:28:14 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 1pVHGH-0006Nx-QC for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Feb 2023 20:28:14 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVHGA-0005IY-ET; Thu, 23 Feb 2023 14:28:06 -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 1pVHG8-0005HC-Hw for emacs-devel@gnu.org; Thu, 23 Feb 2023 14:28:04 -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 1pVHG6-0004Km-Oz; Thu, 23 Feb 2023 14:28:04 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id AAA56442D49; Thu, 23 Feb 2023 14:28:00 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id E8468442D43; Thu, 23 Feb 2023 14:27:58 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1677180478; bh=rFBxtrjrXMPKhf1dv0nhOf2VB3EvrAp01oAhXVao0Qo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XANWHU64vVCAqSynQaeO0aT1Ygi6xEtZtA9hiD4f8kDv85zqAP77CBzsMtGmHu/8e wiLVxanWzl4w8p+L53Seu1VVOuUv7lc4BVxJhI2irSmPkEB7tTkbF4xHmmIsxN6Q1p s8G146nEGJHrAgK0rog8cd6VA4YuOVtE2lXrJpcAEjNxfZ50KqycUsElQQTPw2vGQ6 QZKkTSbIZm8zeHrNJgdxE4N8nki7IeJu5vFFcdcVRui7IbG8lWXTbqsM1LcTYAHMQC OHngxdWQIGAFQgv08g16wth+u0ZWkuS1W7grL+nq1pWVno7gsmz1NeEEtsTUD1H7NG X81xm7BLUJtwQ== Original-Received: from pastel (unknown [216.154.34.24]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8589C1209D5; Thu, 23 Feb 2023 14:27:58 -0500 (EST) In-Reply-To: (=?windows-1252?Q?=22Jo=E3o_T=E1vora=22's?= message of "Thu, 23 Feb 2023 17:46:08 +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:303715 Archived-At: > I'd love to switch over to the jit-lock implementation as it has > potential to be much neater. But I can't seem to get it to not > over-request stuff. I attach the patch I've been trying, and it's > clearly got some thinkos when you test it. It doesn't help that > `window-start` and `window-end` aren't -- apparently -- reliable > when called from a jit-lock function. Sorry, I have not followed the discussion, so I don't know what are "inlay hints" nor how to test them. What problem do you see what you try your code? > +(defvar-local eglot--inlay-hints-outstanding (cons nil nil) > + "Largest (BEG . END) window subregion not yet updated for inlay hints.") > + > +(defun eglot--update-hints (from to) > + "Jit-lock function for Eglot inlay hints." > + (cl-symbol-macrolet ((x eglot--inlay-hints-outstanding)) > + (setq x (cons (min from (or (car x) most-positive-fixnum)) > + (max to (or (cdr x) 0)))) > + (let ((w (get-buffer-window))) > + (trace-values "window: " w) > + (trace-values "window-region: " (cons (window-start w) (window-end w))) > + (trace-values "outstanding: " eglot--inlay-hints-outstanding) > + ; FIXME: this is NOT the correct condition to decide when to > + ; request stuff from the server. > + (when (or (< (car x) (window-start w)) (> (cdr x) (window-end w))) > + (unwind-protect > + (eglot--update-hints-1 (car x) (cdr x)) > + (setq x (cons nil nil))))))) Why do you compare to `window-start/end`? As you say, they're not reliably available during jit-lock, and that's for fundamental reasons: jit-lock effects can change `window-start/end`. But I can't see a good reason why you'd need to do such comparison: the fact that jit-lock calls you is supposed to say "we need this for redisplay", so you shouldn't need to double-check against window bounds. Unless maybe you have `jit-lock-stealth-time` set to a non-nil value, in which case indeed jit-lock will be called even on non-displayed areas of the buffer, but it's arguably what the user (you in this case) asked for. IOW, you should be able to skip `eglot--update-hints` altogether and use `eglot--update-hints-1` directly (modulo catching errors and such maybe). Stefan