From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Eglot "inlay hints" landed Date: Thu, 23 Feb 2023 12:57:26 +0000 Message-ID: <87bklktu89.fsf@gmail.com> 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> 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="6124"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: dalal.chinmay.0101@gmail.com, emacs-devel@gnu.org, dimitri@belopopsky.com, luangruo@yahoo.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Feb 23 13:59:45 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 1pVBCK-0001Ob-Sj for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Feb 2023 13:59:44 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pVB8P-0003ah-Jw; Thu, 23 Feb 2023 07:55:41 -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 1pVB8M-0003Vy-7I for emacs-devel@gnu.org; Thu, 23 Feb 2023 07:55:38 -0500 Original-Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pVB8K-0008GG-F4; Thu, 23 Feb 2023 07:55:37 -0500 Original-Received: by mail-wm1-x32a.google.com with SMTP id j19-20020a05600c1c1300b003e9b564fae9so4457163wms.2; Thu, 23 Feb 2023 04:55:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Hpx4jarC7hx1NwMEe4hB5EUnH5DElEbGdOHvQu+0y0g=; b=Xqk7DsSeCyGoafyrcEOjb9EGshw08yPPA9XNeSeDxQLmyaHbAae9O8hXcHXh8y48MA J9BF8Dt5Ig3US3PjIbHsN9Gfs34ol8uUtBFsP7zDfEduuYbmdEUJxorOJ2XC4TB2PFGE fo3YYyTJla1ELlceDK0EL2IUJ1FQyH8ht5qvEabuK0PCUqa8OJGG2/DktFpF2faY+pmZ mBV/bpFyK0CXxuD9GKJRusFctoHBNDoUCRWhTj1fVFlWri6texxegse4qHwVAuSgRJYP 2tN/OwSB5wYhlj9dAOkH29uvD1988rhXGSr5FLd32HvjywycbGlPiN3v65H9GGWH0s3q iSrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Hpx4jarC7hx1NwMEe4hB5EUnH5DElEbGdOHvQu+0y0g=; b=hAX3ma812qAa7velYoQBxlW1MfHlhC2AT9GSU7XcemIVkivUHlyjQCPxXtbt1Nqnxu 8mpxABpZBWz+ageKOqGYgjTkARKgg02kqzVj3xrCybhZ63s2jbWkycEolN+BDSrE3fdF vMViruAsUW/FGt5+hlIvNramzWK6J8avux5fkV/eOVmeSk6dW1GcJvUZmou6WZu6GUmY 5WT2QexHHUyKG3/noHZpKniEqA3ZdwKoExtELNNl5HcmOsw2ghifWxwpFtckIpGjF7Ou z7E+mEVJyPx4xELNkwkH55KYGPL/KK/FaiuE4/o+r20mdQiWpKwkFHZ/vuPvWGeihsOE 07UA== X-Gm-Message-State: AO0yUKUAocCRmpBFRMsMSPk7WGIdDAS3fltimCnowsMdcXRsQQ/87PFd RgWy/fmCTdwIKsf0bp+afXs= X-Google-Smtp-Source: AK7set8G/0kO3B9JDvLf5stNwVpB2mIvDTZOYqfej4vB5Jw+B6Xidl6F6Xg9NQHnbJEHgZTHPTFWbw== X-Received: by 2002:a05:600c:4d06:b0:3dd:1b02:23b7 with SMTP id u6-20020a05600c4d0600b003dd1b0223b7mr8405240wmp.10.1677156934430; Thu, 23 Feb 2023 04:55:34 -0800 (PST) Original-Received: from krug (87-196-72-142.net.novis.pt. [87.196.72.142]) by smtp.gmail.com with ESMTPSA id r8-20020a05600c458800b003db01178b62sm4965101wmo.40.2023.02.23.04.55.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Feb 2023 04:55:33 -0800 (PST) In-Reply-To: <83356wr224.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Feb 2023 14:36:35 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::32a; envelope-from=joaotavora@gmail.com; helo=mail-wm1-x32a.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:303703 Archived-At: Eli Zaretskii writes: > 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) Ah, if it works with "parts of the buffer about to be displayed", then it should be good, yes. But the docstring of jit-lock-register says "START and END indicating the region that needs to be (re)fontified". If that is guaranteed to always match the "region of the buffer about to be displayed" in the window, then we're good. I wonder if it also removes the need for the "smoothing" timers I am using. But note though, that while this has promise for a simpler and more robust implementation, it will _not_ solve the "pop-in" delay. The effects that Eglot's jit-lock-register FUN fontification function produces in the buffer are guaranteed _not_ be finished by the time FUN returns (unless these FUN is allowed to be slow and blocking, which I really don't think is the point). That's what I meant by "any Emacs-side solution [...] deal with [the normal LSP interprocess communication] delay". > 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. >> 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? Yes, but two buffers A and B might already be showing in some window. If you do the change in buffer A and it affects B, then in the current version, the parts of A being show in windows will be updated, but B the parts of B being shown in some other windows will not. Jo=C3=A3o PS: On an unrelated note, I pushed this to emacs-29. If you wish me to revert the inlay hints implementation and do all this work in master, it's fine by me. In practice, it won't really make that much of a difference because Eglot (along with being a new emacs-29 feature) is also a GNU ELPA :core package and emacs-29 users will have access to the latest and greatest features and bugfixes relatively easily anyway.