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

[Dmitry Gutov]

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.

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

Many of us here program in multiple programming languages.

Having major modes exhibit different behaviors where they don't have to 
is jarring.

> Other modes
> may have ElDoc sources that don't lend themselves to this particular
> composition strategy.

They don't have multiple documentation sources? One from major mode, 
another from Flymake, at least.

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

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.

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

Same text contents.

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

I'm not saying the Eldoc buffer command is unnecessary. I'm saying the 
current implementation and semantics are weird.

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.