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 21:54:07 +0200 Message-ID: <837cw8p38g.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> <83356wr224.fsf@gnu.org> <87bklktu89.fsf@gmail.com> <83y1oophd0.fsf@gnu.org> <83k008pah3.fsf@gnu.org> <83edqgp8fl.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="39121"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 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 20:54:39 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 1pVHfq-0009sc-Cm for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Feb 2023 20:54:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVHfQ-0001eF-Pw; Thu, 23 Feb 2023 14:54:12 -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 1pVHfP-0001dw-Ga for emacs-devel@gnu.org; Thu, 23 Feb 2023 14:54:11 -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 1pVHfP-00038m-5T; Thu, 23 Feb 2023 14:54:11 -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=U2h6tddfhoRtN/kTaj4Hz/z+ZsIwhG8NedgP1Dgr/Mw=; b=qbQCqKqSAD1JulLz51TT CaT16R8x8fVWVW99VV2b0+SM/huUBfw+3AQqXICZ7cBOMXtZnUrb/QoJl2HO1CBfw05GhkmK2Z59z enqfNBWaRo1Cx/+/n2YkqYgrUDI5hCTfD2fI+euf0CwreKRCWYUd9iFqyAoL4eqwQBtJbrRdfXOL0 mcN99aSzyZL4XzyexaXuarZb0LzqZSVUWZ9GSqUvS8Uga/0Gr4SP1frjfarcdaUWtemdlXZaxMf4e lt5PAFcvOGF/Ks00TxAwZ3zb2eMv4IIOEtBGzZw3KBice/yrkxMKsWiyDFcV8mkGYSmj6gaFnBjdX mNJG6XgxwpQNnw==; 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 1pVHfO-0008LY-IR; Thu, 23 Feb 2023 14:54:10 -0500 In-Reply-To: (message from =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= on Thu, 23 Feb 2023 19:26:10 +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:303718 Archived-At: > From: João Távora > Date: Thu, 23 Feb 2023 19:26:10 +0000 > Cc: Stefan Monnier , dalal.chinmay.0101@gmail.com, > emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com > > > I actually gave you a recipe for demonstrating the problems I have in > > mind: scroll the window under pixel-scroll-precision-mode. AFAIK, we > > don't call window-scroll-functions in that case. > > I don't have a pixel-scroll-enabled Emacs to test. Can you scroll > large portions of the window like that and w-s-functions will never > get called? I'd say that's a bug we should fix. > > > Another situation where we don't call window-scroll-functions is when > > the user types into the buffer. > > That is handled by Eglot's after-change-functions already so it > isn't a problem. > > > Yet another situation is when you type "C-x 1" to delete all the other > > windows on the frame, leaving the current window that now shows more > > stuff than before. > > Reproduced. Easy enough to fix with window-configuration-change-functions. > I pushed a fix. My point is that using jit-lock machinery, you will never miss an update, because redisplay is very good at knowing when something needs to be redrawn. It has to. By contrast, all those hooks are less reliable, and also make Emacs sluggish, because the hooks are many times triggered when there's nothing to do wrt display.