From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#62816: 30.0.50; ElDoc blinks echo area when eldoc-documentation-compose is used Date: Fri, 14 Apr 2023 01:16:40 +0100 Message-ID: <87jzyf2u8n.fsf@gmail.com> References: <87leivsusz.fsf@gmail.com> <87ttxj2wpm.fsf@gmail.com> <2e04fa32-d52e-73ac-dabb-7ed5396dce0a@gutov.dev> 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="30952"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62816@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Apr 14 02:15:22 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1pn762-0007t6-Lt for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Apr 2023 02:15:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pn75m-0003eW-V8; Thu, 13 Apr 2023 20:15:07 -0400 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 1pn75k-0003e8-Us for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 20:15:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pn75j-0003wG-1Z for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 20:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pn75i-0008F6-7U for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 20:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 00:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62816 X-GNU-PR-Package: emacs Original-Received: via spool by 62816-submit@debbugs.gnu.org id=B62816.168143128331647 (code B ref 62816); Fri, 14 Apr 2023 00:15:02 +0000 Original-Received: (at 62816) by debbugs.gnu.org; 14 Apr 2023 00:14:43 +0000 Original-Received: from localhost ([127.0.0.1]:45121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pn75O-0008EN-US for submit@debbugs.gnu.org; Thu, 13 Apr 2023 20:14:43 -0400 Original-Received: from mail-wm1-f48.google.com ([209.85.128.48]:40924) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pn75N-0008E5-2y for 62816@debbugs.gnu.org; Thu, 13 Apr 2023 20:14:41 -0400 Original-Received: by mail-wm1-f48.google.com with SMTP id o6-20020a05600c4fc600b003ef6e6754c5so7182883wmq.5 for <62816@debbugs.gnu.org>; Thu, 13 Apr 2023 17:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681431275; x=1684023275; 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=hHlyiKCPMJqxKJfjiYDphmVapFQyZi1mDl+jzah4GWY=; b=R5eA6mPzhGh9fA8lQlGAJBixNttFYzNnIzUdPwIJNRsSN6yVAvjT3/aZ8E1nRPRK3o CWbuo5lIK8hC/nMhYBVFn5OPrA6LjfnSullbZBR+Ep3yCpLPJpfoNglbmgrcFdBf7mv7 0bWNhlJZw1Pat6HruU7tpUzGCnraNoVDWu2u8m4S287K4sJwob2H2v+B2zZtKh14Wfgw VcdMQ/lhFBbZOz/o9r2P7tOaKgFCGX9+FVGELWq8oYWtgsHhxL9/uZJVsGRWBetDMOVR eTD1DMuD5+DK+/c6hFeOPU3L2D4e89/BdWWDUTXT3s+zGk4HGh5TqK5S8RRA7FJJAKCZ GP7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681431275; x=1684023275; 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=hHlyiKCPMJqxKJfjiYDphmVapFQyZi1mDl+jzah4GWY=; b=VtxIuwfPBTOZ2NxP9f8LjfKxSXNW65xLbOFrlnS4TLnnXg+6l8KodHGhtIgAo2xpRR f0z7NuT1HCvCFFfc3FMatj3w3zJCvAgw3UrOt+jXQP8CW35r12BL0cmkNvY+Mv+1PgAQ +ZDIdzH6vh1LSE/rbHBITMb7jwMuklJUQ2wFAq5Wpa0tUlRsfggyJpRSYa/Eo0d2OIA3 BBgi7ZKa6o9obUEgahYEpy0cPleA5F/1xTgXBXTxDQ85cpy/xkJaKm8WpwGZfJKtdUJD c0oS4ZPwWVRVLnXBlQ2983qHK+NFI6WEyWIzbugqe7kFcMhp0U0RKgXAoIJ9rRWNopYX CsaQ== X-Gm-Message-State: AAQBX9c+baqPaB6go9g7QsjMD6G7+UvPKt9mqpawRd2ST3d2B0Tv3Mej Zrbfp52NR5WnQJAW/ZYNS9p7CfqRqMo= X-Google-Smtp-Source: AKy350ZUqzlFGNB/IT3INEXiMGqRw+yZOj9KVExNNI5ydisjDfHy34agUbDrg+hksxRex9BFaM/tGg== X-Received: by 2002:a1c:ed07:0:b0:3ef:6eeb:c25a with SMTP id l7-20020a1ced07000000b003ef6eebc25amr2992974wmh.6.1681431274883; Thu, 13 Apr 2023 17:14:34 -0700 (PDT) Original-Received: from krug ([87.196.73.56]) by smtp.gmail.com with ESMTPSA id l42-20020a05600c1d2a00b003ef6988e54csm6728603wms.15.2023.04.13.17.14.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Apr 2023 17:14:34 -0700 (PDT) In-Reply-To: <2e04fa32-d52e-73ac-dabb-7ed5396dce0a@gutov.dev> (Dmitry Gutov's message of "Fri, 14 Apr 2023 02:37:39 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259888 Archived-At: Dmitry Gutov writes: > On 14/04/2023 02:23, Jo=C3=A3o T=C3=A1vora wrote: >> Dmitry Gutov writes: >>=20 >>> I still see the problem with window jumping and blinking when typing >>> with company-mode enabled, though. You say: "I do use company and >>> multi-line echo areas liberally". Do you have some extra configuration >>> for company-frontends? >> Not that I know of. I just use a TTY frame. I don't see it. The >> echo >> area is frequently empty for me when selecting Eglot completions (in >> clangd, the server I most use nowadays). >>=20 >>> Here's a screencast that demonstrates the problem: >>> https://a.uguu.se/csTMrzxc.webm >> Ugh, that indeed looks awful. We must fix it. >>=20 >>> One way to fix that is >>> (push 'company-echo-metadata-frontend company-frontends) > > Sorry, that was supposed to be (delete ...). The one above restores > the configuration -- I needed it for a repeat comparison. Ahaha :-) No, no, I did exactly the same and misquoted you. I put the push there to restore it, with a quick C-x C-e. You did send the delq. >>> but I wonder whether some better solution exists. >> I hope so. >>=20 >>> OTOH, Eglot implements the attribute which this frontend plugs into >>> via :company-docsig, and it seems like both with LSP servers that I >>> just tried it returns nil. If the feature is generally unused, I could >>> understand if Eglot users all disable this frontend anyway. >> I don't think that's the best solution. Though you're right that >> only >> one server, pyright, uses this (it's some user's hack in eglot.el I let >> through: I don't even know what it does, i think it tells) > > Maybe other servers have different bits of info that could be used for > this? Probably. Just looked at the spec, there's are two different "detail" fields (though it's not clear which one to pick or where exactly to send them). See https://microsoft.github.io/language-server-protocol/specifications/lsp/3.1= 7/specification/#textDocument_completion if you're interested, and search down for "detail". But are you saying that if that :company-docsig is taken out completely, the problem will not happen? Maybe I can put it in only for the pyright server. >> But, perhaps to ask the obvious, why can't Company just detect when nil >> is passed to it via :company-docsig and not do any echoing in that >> situation? Isn't it Company doing the clearing we want to avoid? > > I think it does need to clear the echo area when it was previously > echoed to by the same backend (showing meta from a different > completion). E.g. after the user just presses C-n with completion > popup already visible. So the idea to "just not do any echoes" would > require some bookkeeping about where the current message came from, > compare the current message contents, and possibly still fail > sometimes where the exact same message came from a different > source. The last one is unlikely, though. I see. Eglot only uses one Company source, company-capf, if that helps. >> Another option is just to temporarily disable eldoc during the duration >> of the Company completion session. > > Right. > > And yet another solution would be to detect that Eldoc will be used, > and try to plug into its documentation functions to display the meta > thingy alongside the other info. > > That's at least 3 potential solutions now. I think you should do the "bookkeeping" one, at least a very simple version. Just record in your concept of a "company session" if there was ever a non-nil :company-docsig sent from anywhere that required echoing. Until there is, never clear on nil :company-docsig. Eventually, if there is something to echo, tough luck: display it and proceed as currently, clearing always on nil, risking flickering. Suspect this should fix 95% of the cases, certainly Eglot usages. Jo=C3=A3o