all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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?





  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.