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: Fri, 14 Apr 2023 01:04:18 +0100 Message-ID: <87o7nr2ut9.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> <87ttxkrtz5.fsf@gmail.com> <8735534c9l.fsf@gmail.com> 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="15183"; 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 Fri Apr 14 02:03:28 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 1pn6uV-0003iW-Oh for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Apr 2023 02:03:27 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pn6u8-0005xM-32; Thu, 13 Apr 2023 20:03: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 1pn6u6-0005vt-Gd for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 20:03: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 1pn6u6-0000Jk-4X for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 20:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pn6u5-0007uq-Vs for bug-gnu-emacs@gnu.org; Thu, 13 Apr 2023 20:03:01 -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:03: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.168143054530359 (code B ref 62029); Fri, 14 Apr 2023 00:03:01 +0000 Original-Received: (at 62029) by debbugs.gnu.org; 14 Apr 2023 00:02:25 +0000 Original-Received: from localhost ([127.0.0.1]:45102 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pn6tU-0007tb-HX for submit@debbugs.gnu.org; Thu, 13 Apr 2023 20:02:25 -0400 Original-Received: from mail-wr1-f53.google.com ([209.85.221.53]:41551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pn6tP-0007tH-6F for 62029@debbugs.gnu.org; Thu, 13 Apr 2023 20:02:23 -0400 Original-Received: by mail-wr1-f53.google.com with SMTP id v6so15808123wrv.8 for <62029@debbugs.gnu.org>; Thu, 13 Apr 2023 17:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681430533; x=1684022533; 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=J5fPUJtWaDsWIs0F9Bjukb311mgntBfp4V8Ifa0qInY=; b=pOLTHauIWf1xReLS6wdqqMla/RoFqPYk2V9r0kDb+JmRTglbOgIBPH2Uj0mgR6woph 6tqrAzj9o37L74jK89SRLeepunWoV+2NIVXtiOuCjQHdb5i3ccmUZ7Jg4GFzzIFul0oG iMDSoDfwrm7dQy8JiTgexPqZs3VGcYz9t7UMlGB/ky5FlkfhvZy5JnVuH11Dsq642/qb Ue9c0fGSqrpgssRe52HhCfye3QjCdLGtKYp0mZRY4MkQQ5xo8Dpe6OJ6C3yllY7ubGWk ShpIG2NjCfUdbuznl3O0HcWp881gmlQIig3PSktI15n8WpFrVPlvme5S9sSFdnpoT4MS Lx8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681430533; x=1684022533; 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=J5fPUJtWaDsWIs0F9Bjukb311mgntBfp4V8Ifa0qInY=; b=io0m34h1Y/kgWD2zSCnqO/VUxqjb/lv8FpVIUM/trIIsktgZ7T1GfUr0oBevkmW0JL ST7rWGpHX0z/KAXu+ZmdwTkWl0RrsOMM+O6vbQxBL8FajK7JIVS36fzoan3EGa5zE4Xw +UCGqX6nl9J3G6Avd6mmET+LQFOIBk8SeoNkEAxNWgEqsXD09uxvp9pFYLvwNl/wibmS ghu7Oim8EBLcsudG1ZgLU4mjaB0U6v41uEcQQNwDOHsrkI1ufNdvK/hdd9gnOwJ+qFf8 zIHWQkn+X9bdRFSDRAIM/uVtTQv6kGfBMQ9YQHYG5i+WPYHfx2FuHFSbdtTXz2HcKNiR 4Cfw== X-Gm-Message-State: AAQBX9cvDybJv+GJYrGF8WSFYDldawgClNAIqb6XUK4KvPe3QOig+dDT qkHKLdftKeeUc4BnJaa8BuiW6nfkrIw= X-Google-Smtp-Source: AKy350YZxnm9hxkSI13fCDW7ym4WRnP6pW1fDO3inlbPEgp+xVHcIApqQwaFqxrUCP31FfZX1hNwOg== X-Received: by 2002:a5d:530a:0:b0:2f0:2cfb:e90e with SMTP id e10-20020a5d530a000000b002f02cfbe90emr3078224wrv.17.1681430532549; Thu, 13 Apr 2023 17:02:12 -0700 (PDT) Original-Received: from krug ([87.196.73.56]) by smtp.gmail.com with ESMTPSA id y9-20020a5d4709000000b002c56013c07fsm2244320wrq.109.2023.04.13.17.02.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Apr 2023 17:02:12 -0700 (PDT) In-Reply-To: (Dmitry Gutov's message of "Fri, 14 Apr 2023 02:26:03 +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:259887 Archived-At: Dmitry Gutov writes: > On 14/04/2023 02:01, Jo=C3=A3o T=C3=A1vora wrote: >> And you liked the result with no problems? If so, that's a good >> datapoint. You will have seen "bouncing" of the echo area, I presume. > > I'm still vague on what your patch to elisp-mode.el does, but at least > I'm not seeing any particular breakage. My patch to elisp-mode.el that I showed Yuan Fu makes the two function elisp-eldoc-funcall and elisp-eldoc-var-docstring send very rich information to the *eldoc* buffer, but only summarized information to the echo area, via the new :echo option in newer ElDoc 1.14.0. This allows users who have eldoc-documentation-compose as the strategy to have the buffer on the side and see it update with full docstrings of the things they are navigating, organized with a suitable separator. This is why I suggested you try M-x eldoc-doc-buffer along with your tests. >> Elisp >> in de facto an exception. > > Do we have some sort of statistics or overview on that issue? E.g. if > we take only eldoc functions that are relatively old-ish (crossing out > lsp-mode and eglot, I mean). I'm not aware of many. SLY has a eldoc-documentation-function that prints multiline content, and SLY users have never complained about it. >> So a decision has to be made on what we really want for Elisp's echo >> area. If that decision is "yes, we Elisp users, override the default >> e-e-a-use-multiline-p", then it must somehow be recorded in code (hook >> or not, I don't care). If the decision is "OK, we accept a little >> bouncing to 2-3 lines as per the e-e-a-u-multiline-p we have" then >> nothing needs to change. > This is something to ask the users, I think. Maybe by trying an > experiment at some point. The problem is that "asking users" is really an impossibility. Best one can do is present this in Emacs devel and hope the knees don't jerk too much. If you have better ideas, please put them forth and help implement them. >> Of course, in this argument I'm assuming that changing >> eldoc-documentation-strategy to eldoc-documentation-compose is a good >> thing, even a very good thing. But even if it is just an "average" >> thing for a couple of fanboys it shouldn't be blocked by the Elisp >> exception. > > In the latter case, I would say that it probably should. But if we can > streamline things for the enjoyment of everybody, that would be > better. Agreed. > Or, if we change the default value of eldoc-documentation-strategy, > someone with the diametrically opposite preferences from you would > customize eldoc-echo-area-use-multiline-p to 1 and have that work in > all modes. Or set it to 2, to have some middle ground. Etc. OK I see. Well I don't think it's a tragedy to do that with emacs-lisp-mode-hook instead. We're only talking about the people familiar with "new" ElDoc features, which is arguably a very small group, because -- unless they are using my patch to Yuan Fu -- these features aren't yet very developed in Elisp-mode. So the likelyhood of that backlash is very low. > I've described a scenario in the bug you filed (bug#62816) which uses > company-mode. With a screencast. Again, in a basic default > configuration of everything. At first sight, I think that's primarily a problem in Company mode. Let's continue in that bug. > Personally, I'd rather people also tried to explore ways to show some > of this info that doesn't put it all in Eldoc. There are a lot of > examples of signature help interfaces that put it closer to the input. If I understand your preference for "put it closer to the input", that'd just be another function in eldoc-display-functions. Yuan Fu's eldoc-box is such an example. [ BTW, today I've pushed a Flymake feature flymake-show-diagnostics-at-end-of-line that puts diagnostics "closer to the input" (though not via Eldoc, of course) ] >>> (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. >> Of course. Agreed. And as far as I understand, that has always >> happened (modulo flickering, which is imperceptible in TTY Emacs). > Why isn't this stuff noticeable on TTY? Lower refresh rate or > something? Beats me. >> It could be the start of an idea that doesn't require changing >> e-e-a-use-multiline-p, because if you use it and don't turn on Flymake >> mode (which I suspect the older crowd doesn't), then it's like nothing >> ever changed: no bouncing whatsoever. > > Yep. (As long as that "you" wasn't about myself in particular.) Yes. Read that as "...because if one uses it...". >> Starting from there, we could >> modify it so that this e-d-function only echoes and doesn't send >> anything to the *eldoc* buffer, while elisp-eldoc-fucall and >> elisp-eldoc-var-docstring to the inverse. > > That reminds me of some of my older messages where I insisted the > eldoc-buffer thingy should have its own separate hook. Oh well. To be clear, what I'm thinking of is to have _3/4_ functions in elisp-mode's e-d-functions elisp-eldoc-funcall elisp-eldoc-var-docstring elisp-eldoc-failover-funcal-to-var flymake-eldoc-function (optional, depends on Flymake mode) By default, in Emacs -Q, the first 2 send _nothing_ to echo (via the new ElDoc :echo feature) are but send rich info to other eldoc-display-functions. The special elisp-eldoc-failover-funcall-to-var sends _only_ to the echo area (and only ever one line). A customization variable elisp-eldoc-legacy-oneliners, set to t by default, could control this. If set to nil, then the first 2 would behave as in Yuan Fu's patch and the third one would do nothing (or not exist). Then, I contend, eglot-documentation-strategy can "safely" be set to eldoc-documentation-compose without annoying old timers. And no touching of eldoc-echo-area-use-multiline-p. In my view, *eldoc* doesn't need any hook. I don't remember or understand this hook idea today, and I don't think I ever did. But if you do and think it's helpful to bring it back, you can always illustrate it in code. Jo=C3=A3o