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: Sat, 15 Apr 2023 02:50:19 +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> <8735534c9l.fsf@gmail.com> <87o7nr2ut9.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="15312"; 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 Sat Apr 15 01:51:30 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 1pnTCS-0003mK-GS for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Apr 2023 01:51:29 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pnTC5-0006VE-N1; Fri, 14 Apr 2023 19:51:05 -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 1pnTC3-0006Un-8d for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 19:51:03 -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 1pnTC2-00049N-RP for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 19:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pnTC2-00082e-95 for bug-gnu-emacs@gnu.org; Fri, 14 Apr 2023 19:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Apr 2023 23:51: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.168151623230722 (code B ref 62029); Fri, 14 Apr 2023 23:51:02 +0000 Original-Received: (at 62029) by debbugs.gnu.org; 14 Apr 2023 23:50:32 +0000 Original-Received: from localhost ([127.0.0.1]:47912 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnTBX-0007zN-BF for submit@debbugs.gnu.org; Fri, 14 Apr 2023 19:50:32 -0400 Original-Received: from new3-smtp.messagingengine.com ([66.111.4.229]:53551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnTBU-0007yQ-7T for 62029@debbugs.gnu.org; Fri, 14 Apr 2023 19:50:29 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id F30EC5823C7; Fri, 14 Apr 2023 19:50:22 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 14 Apr 2023 19:50:22 -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= 1681516222; x=1681519822; bh=ttnswDqGAMRhWfIobqQ//KnPagZW+lE2vzf Q1XgfCxA=; b=Z+IXJReeBz6aVyr4gZSi6EmeXp1X0xPEF0CI2YZz0yuJRQBOGY4 bArj8CMLDQIUgRPw+/IQ/vVu2SMe1IreBIG+6swdkFMz3Ttoj7gfxQOpu3hsscby nsREhXKFg62GbUS5MuWXzfuZyRj13uwMNRO7Q/Weq2FpmqflIUa1OlGx4hruA62E 4xTQwQ84IXihF9y55m51XTIszdMUOMyBzvn6ZVaF60/np6DX/gJIxDaN146/lvKD p5BYD5/bLwBaTOnKcA2I2eTB/3OZaU9ontZqGA1evi9vv7+/pD67Ar1bUpQ7LYuf VJrAR1JPzqb1JbPeqlmrPhok2Yw1VxaiNZQ== 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= 1681516222; x=1681519822; bh=ttnswDqGAMRhWfIobqQ//KnPagZW+lE2vzf Q1XgfCxA=; b=EkAGJzOXZY4jauhfLSa2kqPNxHwQ/OUw6x/UxqW4VYuXmX3+ole oIrK5cGMw7e01mdLjOoUXTjwjR2BecfoZqeGG5MbDbcM3WKbM645HvOYQLTFHknE h9IX5U+rBH94Z9gZCV96xLm++wnSZwL8o4OOBKSVRJljsUjRSaHpADw70wFQuox/ 0DtXoXoff4QeBWBG92ihqfpQmqT2+fs+d/Q6VIRxdawW2e11jgZJS3DLPPFXRha0 ECVO/b+lU7Pi5YAkw1cm4/4ipFVtCqRasqW9RhUk+O/vBuTOz/YuGy03EUrADov3 hrk/P760fevH3unYaEsjzXC2VIyhSJbEeiw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeluddgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhephfffheeljeffgeffueeghfekkedtfffgheejvdegjeettdduheeufffggfef jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 14 Apr 2023 19:50:21 -0400 (EDT) Content-Language: en-US In-Reply-To: <87o7nr2ut9.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:259988 Archived-At: On 14/04/2023 03:04, João Távora wrote: > Dmitry Gutov writes: > >> On 14/04/2023 02:01, João Távora 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. Okay, I see it now. I think it doesn't look optimal, for example, when point is on a variable, it lists just the name and the docstring. C-h v has a much richer display which might be worth reusing here (or more parts of it, at least). But those are details. To sum up, if I may, you have reached the conclusion that the doc buffer should look different, and its text needs to be produced differently, than the notifications in the echo area. (*) >>> 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. At certain point users start to self-select, especially if they don't know how things could be better/different. As evidenced just by the other bug report with the blinkage in the echo area which should be apparent to anybody with graphical Emacs. So "users of package xxx don't complain about yyy" is not as strong an argument as "almost all packages out there use approach yyy". >>> 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. I've done it before, and the results definitely aren't representative of the whole community (like 10 responses or so), but they has been convincing enough for me to abandon the particular idea I had. ;-( You could have a different result, though. >> 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. The patch will make it in soon enough, right? I'm not sure I understand this argument. >> 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. Sure. >> 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. Might be. If signature info is annotated with a particular key, which that display function will pick up. But I'm not sure how to make it so that the other display functions ignore it. If siginfo is displayed with eldoc-box is something similar, we don't need it in the echo area. Maybe not in eldoc-buffer either (not quite sure). Further, though, the siginfo could become a structured piece of data, rather than a string (e.g. I recall an interface where the user could switch between overloads using arrow keys). That is unlikely to fit eldoc's model at all. > [ 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) ] > It does not bootstrap, unfortunately. Or otherwise build: load("progmodes/elisp-mode") load("loadup.el") Eager macro-expansion failure: (wrong-type-argument listp t) And that's in a clean new worktree. >>> 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 Note that this one is easy enough to do for Elisp because both functions are synchronous and you can determine the success of elisp-eldoc-funcall by its return value. Not so easy to do for eldoc functions in general (e.g. to do a similar failover for Eglot). > 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). Nice. Let me get back to this later down in this email (**). > 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. It's a valid hypothesis, at least. > 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. We have a hook (hooks) eldoc-documentation-function (and -functions), which determine what should be displayed in the echo area. And then we have this eldoc buffer, which as we apparently agree now can/should have a different set of output functions (** above), and even the functions with information about the same things will usually print it in different ways (* above). That basically tells me that eldoc-buffer could use separate hooks, rather than reuse existing one, e.g. eldoc-buffer-output-function, eldoc-buffer-output-functions. Perhaps the former would reuse the existing set of combinator/strategies, but I can easily see eldoc-documentation-function and eldoc-buffer-output-function set to different strategies. This separation could still work together with eldoc-display-functions (the different functions in this list would just pick up its info from different hooks). I'm not going to bother with a patch because backward compatibility, and blah, and the current approach can obviously function too, though in a more complicated way. But you might want to consider ways the echo and the buffer could be configured to use different combinator strategies. I see no inherent reason for them to always use the same one.