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

Previous Next

Full log

Message #14 received at 43103 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
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: Re: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp
 mode (eldoc-documentation-strategy)
Date: Sat, 29 Aug 2020 21:17:03 +0300

> From: João Távora <joaotavora <at> gmail.com>
> Cc: 43103 <at> debbugs.gnu.org,  larsi <at> gnus.org,  monnier <at> iro.umontreal.ca
> Date: Sat, 29 Aug 2020 17:07:48 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > How will the proposed change modify the behavior in the use case with
> > which you started this message?
> 
> In the use case I started this message with, the user has enabled
> Flymake.  Instead of seeing only the function signature in the echo area
> -- and being denied the presumed Flymake diagnostic "beneath it" -- this
> user would now see both items of information in two lines of said echo
> area.

So the user will see both the function's signature and the Flymake's
error message because the call's syntax is not yet complete?  That
sounds sub-optimal, doesn't it? why show an error message when the
user is clearly still typing the code?

> A similar reasoning applies to other situations with two competing
> different sources of context or "at point" documentation.  Currently,
> even without Flymake there are function signatures and variable
> docstrings, for example.

I'm talking specifically about Flymake, because it reports errors,
not just any information.

Previous Next

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