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#62029: 29.0.60; Allow users to customize eldoc buffer separator Date: Thu, 13 Apr 2023 10:50:54 +0100 Message-ID: <87ttxkrtz5.fsf@gmail.com> 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> 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="22585"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 62029@debbugs.gnu.org, Yuan Fu To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Apr 13 11:49:19 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 1pmtZv-0005hD-Aa for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Apr 2023 11:49:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pmtZg-0002aZ-Hd; Thu, 13 Apr 2023 05:49: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 1pmtZe-0002aA-PU for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 05:49: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 1pmtZe-0004Es-Hf for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 05:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pmtZe-000094-Do for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 05:49: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: Thu, 13 Apr 2023 09:49:02 +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.1681379338548 (code B ref 62029); Thu, 13 Apr 2023 09:49:02 +0000 Original-Received: (at 62029) by debbugs.gnu.org; 13 Apr 2023 09:48:58 +0000 Original-Received: from localhost ([127.0.0.1]:42547 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmtZZ-00008l-Ow for submit@debbugs.gnu.org; Thu, 13 Apr 2023 05:48:58 -0400 Original-Received: from mail-wr1-f46.google.com ([209.85.221.46]:36545) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pmtZX-00008Y-4O for 62029@debbugs.gnu.org; Thu, 13 Apr 2023 05:48:56 -0400 Original-Received: by mail-wr1-f46.google.com with SMTP id q6so2136200wrc.3 for <62029@debbugs.gnu.org>; Thu, 13 Apr 2023 02:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681379329; x=1683971329; 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=8db1yQq/40ikkmgQ9If282dVqKjq0ZTBx7xEFenuXo0=; b=o35yRmZYNxBLOPjBC+9eS6BiUEuq2OafafRbAVc78E1ZBnRz/mxFKNiMe0gRv8yIin u4SkKBwOpqOjm1UEeHI9upFKPL2o35wchqm/MnnVDP1qiV7TVJa8gs0eg6+x2BsxDEt4 g9Hcqv3FHF+vBQB2M4OlmnRfnE7LEoT8/yrKqybtJrwKII/MnGQmYD759jS0pf7dwrGk qX6yHYflDNmlTc1vb4nO10JogTMam3UQz0KkN8QwQ79QgIQw2oUPN7scdEcwdiqzWCPG /E7Vy5/yHd9WOmNE+DSOLN48wHWCqaBJWe37UDQV0rI4Lrc1umbR+frqZnV9Xtt04eCW DzJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681379329; x=1683971329; 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=8db1yQq/40ikkmgQ9If282dVqKjq0ZTBx7xEFenuXo0=; b=H3xBlYFATk246ogCtBrRGy8rCUb37JY3nA+o3MyaLi4VqTzPps7c39DDbmnHaGU5Ut nDgsv5agezTWEiU3gHTiP3AFwXv9ps5N2S7wHp6M767JZphCdtdO7v5QEMF64eAd4zW5 6tcq0NybicOvTYo15w1ZjSRs1paWo7biAfSUDDFSd8UifcI2Jp323H0l5pmC5O3csJGB W/ce/mFWs/AXqUlwY5EglTf0yI0Pgr78Nb54dwMxiYYrkp+PCLyuicx9GTwPhg3MUegV Vdbof+6E30wDLGa6d6fFC5kkbw1vzzd4tBIaZ+ae6Xjxk1r6HpEsHtAQia3E/rWnxbHS RVRw== X-Gm-Message-State: AAQBX9e9MHYi64/Ftq9KjyehSzAVKfTAukHqlQLF/rqDZ3v5Qpr1GJ17 0UWnXbl2zWDvYz6jtzljaWResTmCy/Q= X-Google-Smtp-Source: AKy350aehxW1J6WFpevDBjLa0SQElw7UYc3RVWlfjv3OL6RL0wEIHjQIVbjIHk2NJE2TbxSk4C59wQ== X-Received: by 2002:a5d:5943:0:b0:2ef:b525:bdf9 with SMTP id e3-20020a5d5943000000b002efb525bdf9mr1053114wri.48.1681379328535; Thu, 13 Apr 2023 02:48:48 -0700 (PDT) Original-Received: from krug ([87.196.73.56]) by smtp.gmail.com with ESMTPSA id b3-20020adfde03000000b002efb2d861dasm905355wrm.77.2023.04.13.02.48.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Apr 2023 02:48:48 -0700 (PDT) In-Reply-To: <6c64f601-0c28-2993-e55a-042419e1623e@gutov.dev> (Dmitry Gutov's message of "Thu, 13 Apr 2023 03:20:19 +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:259844 Archived-At: 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. > 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. 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). 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. 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. > And the thing with window jumping/blinking seems common enough across > the modes.=20 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. 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. > 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? Jo=C3=A3o [1]: https://www.masteringemacs.org/article/seamlessly-merge-multiple-documentat= ion-sources-eldoc [2]: Yes, I know the default is 'truncate-sym-name-if-fit', but that's the same as the potentially infinite 't' in 99% of the cases. And we set it another value like 'truncate-sym-name-but-keep-it-to-one-line' if that 1% is indeed relevant.