From: Eli Zaretskii <eliz@gnu.org>
To: "João Távora" <joaotavora@gmail.com>
Cc: 43103@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Date: Sat, 29 Aug 2020 18:58:11 +0300 [thread overview]
Message-ID: <83wo1hxx4c.fsf@gnu.org> (raw)
In-Reply-To: <87h7sla2gc.fsf@gmail.com> (message from João Távora on Sat, 29 Aug 2020 16:36:51 +0100)
> From: João Távora <joaotavora@gmail.com>
> Date: Sat, 29 Aug 2020 16:36:51 +0100
>
> I've recently moved `flymake-eldoc-function` from first to the last spot
> in the list. If I hadn't done that, the default behaviour when writing
> a sexp such as, say:
>
> (my-dear-function [point here])
>
> would be to foremost greet the user with the Flymake error message about
> insufficient args being supplied to the `my-dear-function` call about to
> be written, rather than what those args are supposed to be. Obviously
> this defeats the purpose of having ElDoc serve as a code-writing aid.
>
> But now take this other situation and suppose there is an error in the
> "foo" where point is on:
>
> (my-dear-function 'fo[point here]o 42 'bar)
>
> Having the sexp written with a suitable number of arguments but with
> some Flymake mistake will now fail to notify us of those mistakes, since
> the signature information takes priority. This is similar, if not the
> same, as the aforementioned bug#32243.
>
> Earlier, there was no obvious solution to this, especially if one
> insisted on using only a one-line-tall echo area at the maximum. Now,
> after Mark Oteiza's introduction of `eldoc-documentation-functions`,
> there are ways to configure suitable behaviours. In particular there is
> `eldoc-documentation-strategy` (formerly `eldoc-documentation-function`,
> singular), which tells how to coordinate ElDoc information from multiple
> sources.
>
> This variable's value defaults to `eldoc-documentation-default`
> globally. I suggest we default it to `eldoc-documentation-compose` in
> Elisp mode, so the three functions occupying
> `eldoc-documentation-functions` can be in play at the same time. This
> is because the information conveyed by them can be generally be useful
> at the same time.
How will the proposed change modify the behavior in the use case with
which you started this message?
next prev parent reply other threads:[~2020-08-29 15:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-29 15:36 bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy) João Távora
2020-08-29 15:58 ` Eli Zaretskii [this message]
2020-08-29 16:07 ` João Távora
2020-08-29 18:17 ` Eli Zaretskii
2020-08-29 20:13 ` João Távora
2020-08-30 14:26 ` Eli Zaretskii
2020-08-30 15:15 ` João Távora
2020-08-31 1:07 ` Dmitry Gutov
2020-08-31 8:38 ` João Távora
2020-08-31 20:03 ` Dmitry Gutov
2020-08-31 20:25 ` João Távora
2020-08-31 20:48 ` Dmitry Gutov
2020-08-31 21:12 ` João Távora
2020-08-31 21:20 ` Dmitry Gutov
2020-08-31 22:50 ` João Távora
2020-09-01 10:52 ` Dmitry Gutov
2020-09-01 11:11 ` João Távora
2020-09-01 11:23 ` Dmitry Gutov
2020-08-31 0:47 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83wo1hxx4c.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=43103@debbugs.gnu.org \
--cc=joaotavora@gmail.com \
--cc=larsi@gnus.org \
--cc=monnier@iro.umontreal.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.