GNU bug report logs - #43103
28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: 43103 <at> debbugs.gnu.org, larsi <at> gnus.org, monnier <at> iro.umontreal.ca
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Date: Tue, 1 Sep 2020 00:20:59 +0300

On 01.09.2020 00:12, João Távora wrote:
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
> 
>> On 31.08.2020 23:25, João Távora wrote:
>>
>>>>>> These is definite wisdom in that.
>>>>> I see only signs of rudimentary intial design which predates
>>>>> eldoc-...-multiline-p, composition, Flymake...
>>>> That doesn't mean the initial design didn't get something right.
>>>> If it didn't, this aspect would have likely changed by now.
>>> It couldn't change because there weren't the tools for it to change.
>>> There are now.
>>
>> I don't think so. It still uses the echo area.
> 
> The echo area is not one of the new tools.

You're making my point here.

>> Many of us here program in multiple programming languages.
>>
>> Having major modes exhibit different behaviors where they don't have
>> to is jarring.
> 
> Shall I enumerate variables that are set differently per major-mode?
> Your argument is very odd: every major mode has different behaviours,
> including for example the shape and form of the elements of
> eldoc-documentation-functions.

One reason we create minor modes, unified bindings, and so on, is to 
make the behavior in general more predictable and uniform. So that one 
doesn't need to re-learn Emacs entirely when editing a file in a 
different format.

>> They don't have multiple documentation sources? One from major mode,
>> another from Flymake, at least.
> 
> But you don't know in general the form of each of those, or if there may
> be more, or other characteristics.

That looks like a drawback of your latest redesign (which I pointed out 
previously, but who cares about that). The strategy is a global 
variable, and it's user-customizable.

And yet, somehow, now you're getting worried that different strategies 
might only suit some major modes?

>>>>>>> - even if eldoc-echo-area-use-multiline-p is set to nil, users can still
>>>>>>> get to all the info collecte by ElDoc with the new
>>>>>>> `eldoc-documentation-compose` strategy by pressing M-x eldoc-doc-buffer
>>>>>>
>>>>>> Is that the only benefit?
>>>>> No.
>>>>
>>>> Any others?
>>> For example, it can be used to have ElDoc information permanently
>>> visible in another frame.
>>
>> In the default configuration?
> 
> Yes.

The command. Not the strategy?

>> You're proposing to change the default configuration.
>>
>> To clarify, I was asking whether this was the only benefit of changing
>> the strategy if we also set eldoc-echo-area-use-multiline-p to nil.
> 
> Hopefully you understand now.  I've told you all I know.

You seem to have been answering a different question.

>> One particular way it's unfortunate, is I actually *would* like a
>> generic "show documentation" feature with an existing key
>> binding. Shame it doesn't really work for that purpose.
> 
> Try M-x eldoc and global-set-key and tell us what's missing.

Already told you. I'm not sure how many different ways I can explain 
things, if you keep snipping those explanations out.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.