From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#62029: 29.0.60; Allow users to customize eldoc buffer separator Date: Fri, 14 Apr 2023 00:53:29 +0300 Message-ID: References: <0C40D168-54D5-47E9-8BD8-77CFCD70B895@gmail.com> <87355vdufe.fsf@gmail.com> <87h6uacadx.fsf@gmail.com> <87h6u2y7uj.fsf@gmail.com> <871qkqmzit.fsf@gmail.com> <61fd5d66-ca0b-f67d-df70-7906c32596de@gutov.dev> <87v8i1jr5v.fsf@gmail.com> <6c64f601-0c28-2993-e55a-042419e1623e@gutov.dev> <87ttxkrtz5.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7478"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Cc: 62029@debbugs.gnu.org, Yuan Fu To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 13 23:54:23 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 1pn4ta-0001gr-CV for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Apr 2023 23:54:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pn4tI-0008HT-Jq; Thu, 13 Apr 2023 17:54:04 -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 1pn4tG-0008Gp-O2 for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 17:54:02 -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 1pn4tG-0000bm-Fm for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 17:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pn4tF-0004OW-U0 for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 17:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Apr 2023 21:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62029 X-GNU-PR-Package: emacs Original-Received: via spool by 62029-submit@debbugs.gnu.org id=B62029.168142282116859 (code B ref 62029); Thu, 13 Apr 2023 21:54:01 +0000 Original-Received: (at 62029) by debbugs.gnu.org; 13 Apr 2023 21:53:41 +0000 Original-Received: from localhost ([127.0.0.1]:44969 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pn4su-0004Nq-CZ for submit@debbugs.gnu.org; Thu, 13 Apr 2023 17:53:40 -0400 Original-Received: from new3-smtp.messagingengine.com ([66.111.4.229]:47339) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pn4sr-0004Nc-Hh for 62029@debbugs.gnu.org; Thu, 13 Apr 2023 17:53:39 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 253E3582409; Thu, 13 Apr 2023 17:53:32 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 13 Apr 2023 17:53:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1681422812; x=1681426412; bh=186FScAHF36HNaZL63o1SKRKuKLtlSLpocz Yh9FJrtw=; b=FLd61ayoM6LgWpswQ5MN9kArTQ/U+qqfMnvy06zDp4lyXJbncwc Do02K2XzsRnJrnG8uGrmbBsbZrS4TTFMhmxEWJ+O68GjBEXkB66C9UyjbMTcixbW p7dgDokF+DGE8M7va1vz0PmukV9+90AhJXWjJ8C8KKo48imsWdMkDiwWrpSmlqyb PniEeEFRTCgzUUnk9raBEGSMJnWTudRVjSRPNfzdJ1uZV/BVcBG3+AF6VoHkPhs3 cXSq08+ilCqj9jmpJotShGLYJu47sT2teIS0g8eaTtGMFPwcS2vxi5gxZs4orSPX u37bYFVXDso6LHCrQb+/qATrjTHe9apgt3w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1681422812; x=1681426412; bh=186FScAHF36HNaZL63o1SKRKuKLtlSLpocz Yh9FJrtw=; b=SwdqcmZYRFTQDR4Z94rqYnhNY8+zJOKEjDXMvXT+fQpxZt59Lhn 5pwBlfk2m6YxOLCRCj/81vyiUJXsmQbKxmNHbxnxFFXX4z3bpchQRuFugha1CIxA HKTAHR1lm7MQ0T/qlV/rWF25wqInpbcmU9Hxh0/HKRP3u5YvwGGvSsQYDHM+ohsc aUBaWP9xwVH9mNte/Ez+0NGrfaEYhXdc2yPYY/k3siuU2VKQoOhAkraEhRlYZJmz 2K+gfEAHug3TUuqMhlKkin6ZPKhRP6VY4Qp/LC3UUMoaBJEiL7P/qSAL0x+ARIRd k7V3EHmi/3u+bb2hPOswTsPDaDobcMBunxA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdekledgtdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Apr 2023 17:53:30 -0400 (EDT) Content-Language: en-US In-Reply-To: <87ttxkrtz5.fsf@gmail.com> 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:259879 Archived-At: On 13/04/2023 12:50, João Távora wrote: > Dmitry Gutov writes: > >>>> I have applied it. What should I be looking at? >>> Right. That's a good sign it itself. Here, have some more patch: >>> (setq-default eldoc-documentation-strategy >>> 'eldoc-documentation-compose) >>> (add-hook 'emacs-lisp-mode-hook >>> (lambda () (setq-local eldoc-echo-area-use-multiline-p 1))) >>> Then go on with elisp your life and maybe peek into M-x >>> eldoc-doc-buffer >>> once in a while. >> >> What is the reason to have a special value for Elisp again? > > Try to take it out and see for yourself. It'd be a good test. That's what I did, hence the report. >> One obvious downside is that if the user customizes it to some >> different value (e.g. 2, limiting the height of the window below), it >> won't be honored by Elisp without some extra work on the part of the >> user. So if we want to do that, we'd need some strong argument for why >> Elisp is different from everyone else. > > Apparently it is. The working assumption here is that Elisp users never > ever want to see more than one line of ElDoc documentation in the mode > line, even though the default value of eldoc-echo-area-use-multiline-p > is t [2] . These users, presumably, won't mind and could even > appreciate larger snippets of documentation in the *eldoc* buffer and in > Yuan's eldoc-box popup, though. We're currently working on the pretty > formatting of this buffer, and this bug you're reading is primarily > about that. We might discuss and re-consider that. Anyway, from what I remember, Elisp and "we've always done it this way" has been used as an argument for not changing the default. But nobody stated that Elisp is different from most other modes, and thus should have forced settings different from the default. > Now, Elisp has three different ElDoc backends, two of them added to > eldoc-documentation-functions by default, which already contains one for > flymake-mode (if that is enabled). Doesn't sound too different from the situation with Eglot. > So the patch I've given you is the only way that I know that: > > (setq-default eldoc-documentation-strategy 'eldoc-documentation-compose) > > can coexist with what I understand to be a 1-line-echo-in-elisp > requirement. This is the main point: that value is a vastly better > default for the e-d-strategy variable, and not just in my opinion [1]. > > I was under the impression the 1-line-echo-in-elisp is a hard > requirement, especially to the old-timers. I'd love to be mistaken. I can't answer this one way or the other myself. There are some backward compatibility expectations, probably, and some expectations of stability. But these probably extend to all modes (which have also lived with the given defaults until now), not just Elisp. > But let's say I'm not. Then there's no actual "obvious downside" as you > state. Let's say the user does customize > 'eldoc-echo-area-use-multiline-p' away from its default infinite [2] > value to '42'. It shouldn't have any effect in elisp-mode because of > the hard requirement. It won't have today and won't have after my > proposed change. And if the user does want to override that requirement > and see lots of echo lines in Elisp, there are hooks for that. And if > the user doesn't like hooks (but why is she doing Elisp then?) then > there could be an extra customization variable (not my cup of tea, but I > won't mind). > > But this is all possibly too complicated. I do think that just setting > > (setq-local eldoc-echo-area-use-multiline-p 1) > > In Elisp-mode's major-mode function would have absolutely minimal > impact. It's a great time to experiment in master. At the moment people who don't like the default can easily change it across modes. Setting the var in elisp-mode would change that. >> And the thing with window jumping/blinking seems common enough across >> the modes. > > We have to define the concepts. I thought what was hitherto called > "bouncing" merely referred to the fact that sometimes ElDoc displays 1 > line, and sometimes more. And that causes the echo are to be resized. Let's call "bouncing" the occurrence when the windows resize, frequently enough. In this case, due to the echo area resizing. And "flickering" is when the echo area contents change, sometimes twice per user command (first to blank, and then either to new message, or even to the previous one). > Is this concept of "bouncing" acceptable to you in elisp-mode? Do you > think it will ever be accepted by other Emacs lisp developers that > sometimes, when standing over a symbol with both a function and variable > definition the two things will be documented in two separate lines? I > assume it won't, thus the Elisp setting of > eldoc-echo-area-use-multiline-p to 1. I suggest you put it up for the discussion on emacs-devel after we ensure that the flickering and bouncing situation has improved. In particular, bouncing shouldn't happen on every user input. Echo area resizing is probably unavoidable when moving point between totally different contexts (e.g. one without a flymake error and one with it), but at least the display should be stable while the same things are displayed. And regarding flickering, we can try to ensure that the change in the echo are happens just once per user command, at most. No flickering to blank, if we can help it. >> But in Elisp -- even if I just move the cursor with arrows or C-f/C-b, >> 1 times out of 2 the echo are window will blink. >> >> It's trivially reproduced even with 'emacs -Q': just add somewhere >> inside an Elisp buffer: >> >> (remove-hook asd) >> >> when flymake-mode is enabled and eldoc-documentation-strategy is >> 'eldoc-documentation-compose, and eldoc-echo-area-use-multiline-p is >> not 1, and move around 'asd' with C-f and C-b. >> >> Is that bug Elisp-specific? That would seem odd. > > You seem to be describing a separate problem that I never noticed or was > bothered with (and I do use company and multi-line echo areas > liberally). I'll try your recipe but would you describe exactly what to > look for? It seems you've reproduced it already and even pushed out a fix to master. I believe I've mentioned these things a few times when the change in eldoc-documentation-strategy. They seemed obvious enough not to warrant an extra detailed explanation, so I guess that's on me.