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

[João Távora]

Dmitry Gutov <dgutov@yandex.ru> writes:

>>> 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 know where your evolutionary argument is headed
but it's not very interesting, in my opinion..

>>> Change the default in eldoc.el. Why emacs-lisp-mode?
>> See subject line.
>
> Having a major mode exhibit a different behavior WRT eldoc strategy is
> bound to be confusing. E.g., why Elisp and not Python? Why not the
> rest?

I think people are used to their major modes working in a certain way,
and changes to that way should come about incrementally.  Other modes
may have ElDoc sources that don't lend themselves to this particular
composition strategy.

>>> One would probably prefer to see the description of the compilation
>>> error rather than the function signature, if they had to choose.
>> Maybe you would, you can adjust it.  I'd rather not change more
>> defaults
>> than the one suggested in the subject line.
>
> If it's for emacs-lisp-mode only, it's already not "changing the default".

I don't care what you call it.  I proposed to change the "Emacs -Q
behaviour" of emacs-lisp-mode first.

>>>> - 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.

>>> This command is pretty odd in its design. But if its main purpose was
>>> to show multiple eldoc results together
>> It's similar to `help-buffer`, but also switches to the buffer when
>> called interactively.  I don't see anything odd in that, in Emacs terms.
>
> It's odd to use basically the same presentation for the buffer as the
> one for the echo area.

They don't use the same presentation.  I don't understand the rest of
your reasoning,  sorry.

If you want another example in Emacs, here's one: in Flymake (and in
Flycheck) there are diagnostics collected from multiple backends.  This
information is presented in a variety of ways: in-source annotations,
tiny mode-line construct, echo area, and a constantly updated separate
buffer listing all the diagnostics in tabular form.  The ElDoc buffer is
similar to the latter.

>> This is beyond the scope of this bug, though.
> You brought it up.

No.  You asserted the design is odd, I explained how it's not.

João