GNU logs - #43103, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Aug 2020 15:38:01 +0000
Resent-Message-ID: <handler.43103.B.159871542510496 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Sat, 29 Aug 2020 16:36:51 +0100
Message-ID: <87h7sla2gc.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::435;
 envelope-from=joaotavora@HIDDEN; helo=mail-wr1-x435.google.com
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.0 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Hello,

As I recently mentioned to Lars over at bug#32243, the recent changes to
ElDoc have made it possible for the user and the major mode to control
the information that is eventually showed to the user in the echo area.
That bug, which concerned Elisp function signatures overriding/hiding
Flymake diagnostic lines, has been fixed, mostly because Flymake itself
is an independent producer of Eldoc information, and one is now given
the tools to coordinate between different sources.

The TL;DR is that this bug is a proposal for changing the default value
of `eldoc-documentation-strategy` to `eldoc-documentation-compose`, in
Elisp mode so that all these sources can serve us simultaneously.

So, in Emacs master, we have reasonably common sources for Elisp mode,
which may all act and be useful at the same time.  They occupy this
relative order in 'eldoc-documentation-functions':

- elisp-eldoc-funcall
- elisp-eldoc-var-docstring
- flymake-eldoc-function  (only active if Flymake mode is enabled)

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.

If that creates too tall an echo area for some, I want to mention that,
for now, there is the variable `eldoc-echo-area-use-multiline-p` to
control this.  For those willing to bear with 2 lines at most, I think
this is guaranteed.  For non-users of Flymake, for instance, 2 lines
usually happens if one lands the cursor on documented Elisp variable
being used inside a documented function.  With the cursor on the first
argument in this form:

   (run-with-idle-timer eldoc-idle-delay nil ...)

The echo area would show two lines instead of the usual 1:

    eldoc-idle-delay: Number of seconds of idle time to wait before printin=
g.
    run-with-idle-timer: (SECS REPEAT FUNCTION &rest ARGS)

Also note that even if one sets `eldoc-echo-are-use-multiline-p` to nil,
or 1, one can still get the full set of lines by via M-x
eldoc-doc-buffer.

Later on, we will probably want to review and explore other outlets
other than the echo area and this auxiliary buffer for displaying the
information collected and coordinated by our chose
eldoc-documentation-strategy.

But that is matter for another bug report...

Jo=C3=A3o

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Subject: bug#43103: Acknowledgement (28.0.50; Default ElDoc composition
 strategy in Elisp mode (eldoc-documentation-strategy))
Message-ID: <handler.43103.B.159871542510496.ack <at> debbugs.gnu.org>
References: <87h7sla2gc.fsf@HIDDEN>
X-Gnu-PR-Message: ack 43103
X-Gnu-PR-Package: emacs
Reply-To: 43103 <at> debbugs.gnu.org
Date: Sat, 29 Aug 2020 15:38:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 43103 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
43103: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D43103
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Aug 2020 15:59:02 +0000
Resent-Message-ID: <handler.43103.B43103.159871670712438 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Date: Sat, 29 Aug 2020 18:58:11 +0300
Message-Id: <83wo1hxx4c.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87h7sla2gc.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sat, 29 Aug 2020 16:36:51 +0100)
References: <87h7sla2gc.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: João Távora <joaotavora@HIDDEN>
> 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?

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Aug 2020 16:09:02 +0000
Resent-Message-ID: <handler.43103.B43103.159871728113354 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
Date: Sat, 29 Aug 2020 17:07:48 +0100
In-Reply-To: <83wo1hxx4c.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 29 Aug
 2020 18:58:11 +0300")
Message-ID: <87r1rpigff.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Eli Zaretskii <eliz@HIDDEN> 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.

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.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Aug 2020 18:18:02 +0000
Resent-Message-ID: <handler.43103.B43103.15987250379967 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.15987250379967
          (code B ref 43103); Sat, 29 Aug 2020 18:18:02 +0000
Received: (at 43103) by debbugs.gnu.org; 29 Aug 2020 18:17:17 +0000
Received: from localhost ([127.0.0.1]:49104 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kC5Ph-0002ah-Kt
	for submit <at> debbugs.gnu.org; Sat, 29 Aug 2020 14:17:17 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35962)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kC5Pf-0002aU-Vf
 for 43103 <at> debbugs.gnu.org; Sat, 29 Aug 2020 14:17:16 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:56685)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kC5Pa-0002ba-B1; Sat, 29 Aug 2020 14:17:10 -0400
Received: from [176.228.60.248] (port=4597 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kC5PZ-0003C1-ND; Sat, 29 Aug 2020 14:17:10 -0400
Date: Sat, 29 Aug 2020 21:17:03 +0300
Message-Id: <83tuwlxqow.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87r1rpigff.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sat, 29 Aug 2020 17:07:48 +0100)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: João Távora <joaotavora@HIDDEN>
> Cc: 43103 <at> debbugs.gnu.org,  larsi@HIDDEN,  monnier@HIDDEN
> Date: Sat, 29 Aug 2020 17:07:48 +0100
> 
> Eli Zaretskii <eliz@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 29 Aug 2020 20:14:02 +0000
Resent-Message-ID: <handler.43103.B43103.159873202520494 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159873202520494
          (code B ref 43103); Sat, 29 Aug 2020 20:14:02 +0000
Received: (at 43103) by debbugs.gnu.org; 29 Aug 2020 20:13:45 +0000
Received: from localhost ([127.0.0.1]:49204 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kC7EP-0005KT-DZ
	for submit <at> debbugs.gnu.org; Sat, 29 Aug 2020 16:13:45 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:39283)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1kC7EL-0005KE-EM
 for 43103 <at> debbugs.gnu.org; Sat, 29 Aug 2020 16:13:43 -0400
Received: by mail-wr1-f53.google.com with SMTP id a17so1436181wrn.6
 for <43103 <at> debbugs.gnu.org>; Sat, 29 Aug 2020 13:13:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=2zbnKfxWB+V0AAVLOIrLDFnnR6EjrtyjTxNls8vT2Bk=;
 b=A1JL+d+OWZPg0y1UCs8gMxBTEapbg/OvPOXFlzY901JxEQsKinSHlAs/GBv13eS7m6
 oeBuI/rV9sRNkmnY7wRcCAq4FwxAkSWR/ZnKi0kjQYwlCVM/tq23p5wMlrpbhn6d/90L
 MPxlotHbe7Bw8v8v/v8qn2PZxgEjo3bm4sXPKw38LSaUW+Bnbdai6wCAS+Abl4isELhP
 MZ10vkiCviDaYxrb6r7vNrtWtbCsXuN8v6ZvCOKMmn/UzoRYaMMpOEZPEyN+WjAsXDjN
 VNKgxBYK9seSnsq1pedOrD6lbXKJDySHmUb23wdMW0yksGyL7YnzutIH5VvxnDxwjz85
 asog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=2zbnKfxWB+V0AAVLOIrLDFnnR6EjrtyjTxNls8vT2Bk=;
 b=L6MSvud6+4KFOPiZI8VEUs8LuQuR8IWDWWAX7vOP63c6FrfWobrmXhSU7iKuyz8OlE
 c3V8PM0dHolTBWOGEAz99gDxrf6Br0ysb4H+4QtPTLL/Lvjgt+Hd2kyIe9CCzdFUoqbo
 ZF3MhPtbXy5TfM0z6SSSxeuJ1JOFBJ2f8K/loHIRuuEhAlecOgyNoqn/r/9zGOD7uuM9
 rycMxstd6Nm8XpGSaspSi3ncDGCXuXtti5hqfy8wuwu9EQknCIawb8zyFRVLJfhQs2K2
 zUnqLJgOpP6lfmTohMVKsEnCHMe3Rwf7m+jetlHkX/NzTtrdQDHJmc2WGWJyqaUv2cS7
 N4hw==
X-Gm-Message-State: AOAM532gQMuPJ90joAeSdQoSiydxpmLlTxcIKwEql0JllU6qY3Nrs2W7
 J08Du+5dFUOsNynDOIZ/hfQ=
X-Google-Smtp-Source: ABdhPJxmISlz0G63Gd+uPd2D5TvlnSxYOFse246EPZmaush6DOToZwQxJQy54hTL08Y/qvGAe5cYqA==
X-Received: by 2002:a05:6000:162d:: with SMTP id
 v13mr5050768wrb.12.1598732015639; 
 Sat, 29 Aug 2020 13:13:35 -0700 (PDT)
Received: from krug (a83-132-192-71.cpe.netcabo.pt. [83.132.192.71])
 by smtp.gmail.com with ESMTPSA id h184sm3842901wmh.41.2020.08.29.13.13.34
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 29 Aug 2020 13:13:34 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
Date: Sat, 29 Aug 2020 21:13:31 +0100
In-Reply-To: <83tuwlxqow.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 29 Aug
 2020 21:17:03 +0300")
Message-ID: <87k0xhi51w.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
>> Cc: 43103 <at> debbugs.gnu.org,  larsi@HIDDEN,  monnier@HIDDEN
>> Date: Sat, 29 Aug 2020 17:07:48 +0100
>>=20
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>=20
>> > How will the proposed change modify the behavior in the use case with
>> > which you started this message?
>>=20
>> 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?

For me it's really not clear.  What if the user changed the function
signature elsewhere or the compilation the error check is based on might
is looking at a different version of the library that has another
protocol.  When point is on those invalid calls, it's quite useful to be
alerted to both the error and the signature.  Also note this happens in
any mode that uses Flymake and provide signatures, not just Elisp.

So, situations where the user is typing function calls from scratch do
happen, but they're not necessarily the majority -- it depends on the
editing work.  I will agree with you that displaying the transient error
on those situations is alarmist and not very useful, but it's better
fixed by adjusting 'flymake-no-changes-timeout' (or some other heuristic
that makes Flymake less eager) than asserting that the simultaneous
display of both pieces of information isn't useful _in general_.  It is.
In fact, I recall bug reports in Eglot that repeateadly state so.

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

More precisely, it reports "diagnostics", which may be errors, warnings,
notes, or really any annotation about a region in your source.

Anyway, from your statement, it seems you'd be OK (or at least find less
problematic) that the two Flymake-unrelated lines:

    eldoc-idle-delay: Number of seconds of idle time to wait before printin=
g.
    run-with-idle-timer: (SECS REPEAT FUNCTION &rest ARGS)  [SECS is boldfa=
ce]

Being shown when point hovers on the second atom of the form

    (run-with-idle-timer eldoc-idle-delay nil ...)

?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Aug 2020 14:27:01 +0000
Resent-Message-ID: <handler.43103.B43103.159879759916272 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159879759916272
          (code B ref 43103); Sun, 30 Aug 2020 14:27:01 +0000
Received: (at 43103) by debbugs.gnu.org; 30 Aug 2020 14:26:39 +0000
Received: from localhost ([127.0.0.1]:50467 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCOI3-0004EO-Ga
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2020 10:26:39 -0400
Received: from eggs.gnu.org ([209.51.188.92]:35894)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1kCOI1-0004EC-V6
 for 43103 <at> debbugs.gnu.org; Sun, 30 Aug 2020 10:26:38 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:40193)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1kCOHv-0006rt-Up; Sun, 30 Aug 2020 10:26:31 -0400
Received: from [176.228.60.248] (port=2739 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1kCOHv-0000m6-55; Sun, 30 Aug 2020 10:26:31 -0400
Date: Sun, 30 Aug 2020 17:26:27 +0300
Message-Id: <83blisxl9o.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87k0xhi51w.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sat, 29 Aug 2020 21:13:31 +0100)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN> <87k0xhi51w.fsf@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: João Távora <joaotavora@HIDDEN>
> Cc: 43103 <at> debbugs.gnu.org,  larsi@HIDDEN,  monnier@HIDDEN
> Date: Sat, 29 Aug 2020 21:13:31 +0100
> 
> I will agree with you that displaying the transient error
> on those situations is alarmist and not very useful, but it's better
> fixed by adjusting 'flymake-no-changes-timeout'

If we are okay with a large timeout (like 1 sec at least), then maybe
it's fine.

> Anyway, from your statement, it seems you'd be OK (or at least find less
> problematic) that the two Flymake-unrelated lines:
> 
>     eldoc-idle-delay: Number of seconds of idle time to wait before printing.
>     run-with-idle-timer: (SECS REPEAT FUNCTION &rest ARGS)  [SECS is boldface]
> 
> Being shown when point hovers on the second atom of the form
> 
>     (run-with-idle-timer eldoc-idle-delay nil ...)
> 
> ?

Expect annoying users due to resizing of mini-window.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 30 Aug 2020 15:16:02 +0000
Resent-Message-ID: <handler.43103.B43103.159880053121154 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159880053121154
          (code B ref 43103); Sun, 30 Aug 2020 15:16:02 +0000
Received: (at 43103) by debbugs.gnu.org; 30 Aug 2020 15:15:31 +0000
Received: from localhost ([127.0.0.1]:50558 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCP3L-0005V7-DJ
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2020 11:15:31 -0400
Received: from mail-wm1-f53.google.com ([209.85.128.53]:40336)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1kCP3J-0005Uu-G9
 for 43103 <at> debbugs.gnu.org; Sun, 30 Aug 2020 11:15:30 -0400
Received: by mail-wm1-f53.google.com with SMTP id v4so2422395wmj.5
 for <43103 <at> debbugs.gnu.org>; Sun, 30 Aug 2020 08:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=7rcKUZnxG+dmxJuycrUxWklY3Fzd0O5J2hDpX3oFwUs=;
 b=fmDTu6DqlJild7+e9F49q/R6CLOOPNUkv5LBvMMrkPVjyuVbYsvGBOVM7dzvCeyN13
 zm8rg0kRUXUKdB9rUdBIBp7MUL4Aq4Gqgz0uIvz/3nz8L2nGuwT42pe6eSRwgoA7Smme
 0bxJdb0StfU0JmYBMt7/3vLbEO+UcZ6bjvephwfrFBJBhl2JwMW6YfTto36TfdhOSn7/
 Ro+sim0YfjK0mGmwy/vkWdTm5YwvYLDTGI3DdxXWESwiDPmDFf86sISw2vdVVqFEeMvo
 DPWsCqijCjGLtOE61RwuA30S0+fL7d2nUO8fh0lCS6zTbi40XOziZpjpTaGA82PWXqyB
 qFXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=7rcKUZnxG+dmxJuycrUxWklY3Fzd0O5J2hDpX3oFwUs=;
 b=ShoIX9YmWF70EAQzaXL+BJYcMAo1i8CTeP42E+Wzh1jYvT18dN7T3G+q7DcxXyGDFB
 3aFHSnKCMh5sSaMZmVW21+qV4KQCwFkxYb0IckXDsPXRbUHhnsiu17MCviXE+VJJyhZK
 aiCT1dIMZSVOTCXwsQmTet9KjpvasdVwIvmQLcEjtd7hEFICu9vUdqaetG7FWfrQwjQ6
 C34qgnI/vTFXYcAepvOVzex0cPzeRTXJ0CyqbhEUwyTIHxRck913JZCMKWndYFmv91jk
 kErL4dCXz1rE2md9hqmivMqHn/UTFbr0Ii0WyReycUcwlVXKdPcSJsMc4NZyrDe4jQhl
 t6JQ==
X-Gm-Message-State: AOAM532iXcgRND0TmRWnPpSxUgQw0QTIEFZOjwYxjfKWc109TGilW0dF
 IbrKbpbMUOL4wH/tSt+vRsU=
X-Google-Smtp-Source: ABdhPJyRACt8/4duSQg02/01EGlISKoGo0b6izG0cARUDHG/KZ8rV3NxiqSCHNPYOnPmOMEA9D13rQ==
X-Received: by 2002:a1c:f30f:: with SMTP id q15mr7240253wmq.60.1598800523520; 
 Sun, 30 Aug 2020 08:15:23 -0700 (PDT)
Received: from krug ([89.180.151.132])
 by smtp.gmail.com with ESMTPSA id q6sm7546761wma.22.2020.08.30.08.15.22
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 30 Aug 2020 08:15:22 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
Date: Sun, 30 Aug 2020 16:15:21 +0100
In-Reply-To: <83blisxl9o.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 30 Aug
 2020 17:26:27 +0300")
Message-ID: <878sdwi2ra.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
>> Cc: 43103 <at> debbugs.gnu.org,  larsi@HIDDEN,  monnier@HIDDEN
>> Date: Sat, 29 Aug 2020 21:13:31 +0100
>>=20
>> I will agree with you that displaying the transient error
>> on those situations is alarmist and not very useful, but it's better
>> fixed by adjusting 'flymake-no-changes-timeout'
>
> If we are okay with a large timeout (like 1 sec at least), then maybe
> it's fine.

I'm okay with a 1 sec timeout for flymake-no-changes-timeout, though
before changing that default I'd first pay attention to the feedback of
Flymake+ElDoc users (as you know, Flymake isn't on by default).

Personally, as a Flymake user, I'm not very bothered by the alarmist
messages.  They're very similar to what until very recently happened
with the "add a quote" situation (the one that
`jit-lock-antiblink-grace` fixed).  Other modes (and other editors,
IIRC) will visually annotate the transient erroneous state as the user
is typing "new code".  Though, granted, we shouldn't compare ourselves
with those inferior kind.

>> Anyway, from your statement, it seems you'd be OK (or at least find less
>> problematic) that the two Flymake-unrelated lines:
>>=20
>>     eldoc-idle-delay: Number of seconds of idle time to wait before prin=
ting.
>>     run-with-idle-timer: (SECS REPEAT FUNCTION &rest ARGS)  [SECS is bol=
dface]
>>=20
>> Being shown when point hovers on the second atom of the form
>>=20
>>     (run-with-idle-timer eldoc-idle-delay nil ...)
>>=20
>> ?
>
> Expect annoying users due to resizing of mini-window.

Yes, and this is why I mentioned eldoc-echo-area-use-multiline-p in my
original message.  It is the current way to control this (at least
before I propose a overhaul of the ElDoc display system).

Its default and original value is `truncate-sym-name-if-fit`, which (but
for one detail) basically amounts to `t` or "yes, do use multiple
lines".  So we could

1. greet these annoyed users with this fact and tell
them to set eldoc-echo-area-use-multiline-p to nil or 1

2. set it to such a value by default in emacs-lisp-mode

3. wait for the aforementioned overhaul to somehow give us better
perspective before doing the work of this bug report (i.e. switch to
eldoc-documentation-compose in emacs-lisp-mode).

At any rate, as I wrote earlier:

- the Flymake Eldoc source is last in the list, so it will be the one
edited out if eldoc-echo-area-use-multiline-p is set to nil.  In
practice this would amount to no immediately visible change in
behaviour;

- 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

Hope this clarifies things,
Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 00:48:01 +0000
Resent-Message-ID: <handler.43103.B43103.159883485315624 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159883485315624
          (code B ref 43103); Mon, 31 Aug 2020 00:48:01 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 00:47:33 +0000
Received: from localhost ([127.0.0.1]:51014 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCXyv-00043w-EC
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2020 20:47:33 -0400
Received: from mail-lf1-f42.google.com ([209.85.167.42]:35812)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kCXys-00043i-VP
 for 43103 <at> debbugs.gnu.org; Sun, 30 Aug 2020 20:47:31 -0400
Received: by mail-lf1-f42.google.com with SMTP id w11so558567lfn.2
 for <43103 <at> debbugs.gnu.org>; Sun, 30 Aug 2020 17:47:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=KZODWCkVZH4yIX0Z29R9IMPJLIODimlxtlZ6i6bhgUw=;
 b=N3vwgiXHUntaDbbilBvwABxZzeCoiRoCUGT2EkfAmXIYQx7tnHLUadIchs/MtRc9xc
 l2DuCHdqMIXn7Qrhc7fBLfn6HGhfZj+FPodoPNeJqZ/2T9urmif+TA/wwrJg29qz7cHG
 tsYdXL11cCA9NraZUHduOeYwascXLsVqgGj9WZ11l45xVXvK5AF24LbSNZOTzFV1etlA
 T7p79N7AIizwztr3RpdksP7j6gQacjZh3Uc8rEg5Yp75FFnB6Tp60yBudD5lZ5qIhPzw
 mgC97pQKuPC5lbQ7a9nbqr6WGGmDO4spZpt32ZE1f3aDqsTdtG1Mk8z7v9VSDNeNXyue
 vbWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=KZODWCkVZH4yIX0Z29R9IMPJLIODimlxtlZ6i6bhgUw=;
 b=SFzdLO9nI35paCcbX3oWzNj/Nu3Z0QkOJYCvdjhMAnFkwXI/amQcjkloRGk5iKYwwN
 BBUxt0RoWkjCSpVW7pfGfQtHjRdJUannXmaJvX8aE80NrMfJrk1bavfRY0Iungb+mhL7
 hiEBM3Hg/17ARnB8PbzL9NQ+0oMKI4SvC3VdOsqbij76dPARHp3lgTbMhwbNio3je7e/
 rExLR0Jh7LPF8DaEeknFi659P8yokS+7YW6+9xQocAUsPtUsomO60Pdw4PT4cjyYosK7
 FeSNX+3WNENzZELIQJocb45bPHQFZhyOzsEKu8qxug38h2dCxV4TwSOxcblFbHsDOYMl
 VDmQ==
X-Gm-Message-State: AOAM532kR9YBG19mkaULMUT4kg03NCEbaIS7em6BBwuntsdRJMb8h+QS
 T8KhPYGZ46sDzPpcRU8aBKQ=
X-Google-Smtp-Source: ABdhPJz+8zTpZybQvglZ5UCSLBJaQ7GB97qc6TrnBql/ZvRZzFO5PNGCJk9Avp4Fu4w23ZbaetWppQ==
X-Received: by 2002:ac2:5dc1:: with SMTP id x1mr4327946lfq.217.1598834844887; 
 Sun, 30 Aug 2020 17:47:24 -0700 (PDT)
Received: from [192.168.0.104] ([94.229.108.16])
 by smtp.googlemail.com with ESMTPSA id u6sm1234194ljg.105.2020.08.30.17.47.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 30 Aug 2020 17:47:24 -0700 (PDT)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <1c99257e-1d76-d0ef-c6f3-06d5b7e87772@HIDDEN>
Date: Mon, 31 Aug 2020 03:47:23 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <83blisxl9o.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On 30.08.2020 17:26, Eli Zaretskii wrote:
> Expect annoying users due to resizing of mini-window.

Exactly.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 01:08:01 +0000
Resent-Message-ID: <handler.43103.B43103.159883604817444 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159883604817444
          (code B ref 43103); Mon, 31 Aug 2020 01:08:01 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 01:07:28 +0000
Received: from localhost ([127.0.0.1]:51048 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCYIC-0004XI-2E
	for submit <at> debbugs.gnu.org; Sun, 30 Aug 2020 21:07:28 -0400
Received: from mail-lj1-f176.google.com ([209.85.208.176]:35684)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kCYIB-0004X6-AW
 for 43103 <at> debbugs.gnu.org; Sun, 30 Aug 2020 21:07:27 -0400
Received: by mail-lj1-f176.google.com with SMTP id i10so4810449ljn.2
 for <43103 <at> debbugs.gnu.org>; Sun, 30 Aug 2020 18:07:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=lyD75QySdpVjnEOtBAbO8VXYrmeYYdJGVRJicsy4/AA=;
 b=tB/dWB98GuWfjPXfIRJODIMuVYlHvOQPfQ0pjK/ZpAltMPTPH+kkrfllKHx4dR5wIZ
 trAvxds18qeicKm5Np9crpQHtKAmJI47xY9WqNp/i1WwBszs3T4hSC05q+Kzvj014Fu9
 VK6b4qzRSlhKjzyWHvuX0i1ahrsOlKzL4flPkWn73iwDkEgubHczPrvSX/xi5lBotLzD
 65EXHUsU1B2tXcqt+5o3qTh6Qw6kb229sbcW4lS4d7IqnZ83jdcysbFRBeJ/Ri2vz0xV
 gJAQ04Cs636o/ZR+PaoyEJHCdXjlumPaRIExE6YTpwG+Ee2jpd5FXBOG1EM02ko6iGRe
 Djvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=lyD75QySdpVjnEOtBAbO8VXYrmeYYdJGVRJicsy4/AA=;
 b=MR1uc4Nlqcy0atKjXMaKGgL5UZjNjGdxv6I4l63e9QH4ZrQkQ+Ured3X+QayjM39HD
 F4fsRUDUTl7R3HSNUlKq8ReBVjBoZvKOqTI4WeGV1xgcU6uKH5n1gjyfqtY97Uu2KdiP
 UAdVe2xnH0xrrrRBDib1Jsc8768cr/qEHFOhpgcBRttkKgZj9y2Az5WwpWaPNM9Vb9mB
 Fu7XCdu6tdnwdcm1K7+SRLwDWZDeUOHQvBMysaIIW0c8fojH0URzM68eepD32rmLMu0i
 aZUP/yk9utXtxVByDmJZxWxtbZAfFSCLNLllCTxZ4QWPtsYUicrooqQuvfdtTjmo3kgR
 Nd0Q==
X-Gm-Message-State: AOAM531iIzgL9AoxX6ZLtjS1hA8pXrQpfoo6pJfmfMxXOUzQvIVaIvt2
 kwZ5vtnjcfDzlp4lMWPLwrc=
X-Google-Smtp-Source: ABdhPJwHl3tJ8dOOrZkClEBSaVGBc7MoTqOJRqyHnWHB0Zje+fHCXPUIcByJa8ofv1df4116Myp9vQ==
X-Received: by 2002:a2e:9ac5:: with SMTP id p5mr4355395ljj.253.1598836041224; 
 Sun, 30 Aug 2020 18:07:21 -0700 (PDT)
Received: from [192.168.0.104] ([94.229.108.16])
 by smtp.googlemail.com with ESMTPSA id a12sm1578712lfi.83.2020.08.30.18.07.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sun, 30 Aug 2020 18:07:20 -0700 (PDT)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
Date: Mon, 31 Aug 2020 04:07:19 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <878sdwi2ra.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

On 30.08.2020 18:15, João Távora wrote:

> Its default and original value is `truncate-sym-name-if-fit`, which (but
> for one detail) basically amounts to `t` or "yes, do use multiple
> lines".  So we could

It's true, but the curious reality is that AFAIK the built-in eldoc 
functions (foremost, the Elisp one) have always used the one-line 
display, even when they could show more.

These is definite wisdom in that.

> 1. greet these annoyed users with this fact and tell
> them to set eldoc-echo-area-use-multiline-p to nil or 1
> 
> 2. set it to such a value by default in emacs-lisp-mode

Change the default in eldoc.el. Why emacs-lisp-mode?

> 3. wait for the aforementioned overhaul to somehow give us better
> perspective before doing the work of this bug report (i.e. switch to
> eldoc-documentation-compose in emacs-lisp-mode).

Or that.

> At any rate, as I wrote earlier:
> 
> - the Flymake Eldoc source is last in the list, so it will be the one
> edited out if eldoc-echo-area-use-multiline-p is set to nil.  In
> practice this would amount to no immediately visible change in
> behaviour;

One would probably prefer to see the description of the compilation 
error rather than the function signature, if they had to choose.

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

This command is pretty odd in its design. But if its main purpose was to 
show multiple eldoc results together, it could always use the 'compose' 
strategy itself, regardless of the value of eldoc-documentation-strategy.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 08:39:02 +0000
Resent-Message-ID: <handler.43103.B43103.159886311112968 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159886311112968
          (code B ref 43103); Mon, 31 Aug 2020 08:39:02 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 08:38:31 +0000
Received: from localhost ([127.0.0.1]:51518 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCfKh-0003N6-1c
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2020 04:38:31 -0400
Received: from mail-wm1-f47.google.com ([209.85.128.47]:38674)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1kCfKe-0003Mr-QL
 for 43103 <at> debbugs.gnu.org; Mon, 31 Aug 2020 04:38:29 -0400
Received: by mail-wm1-f47.google.com with SMTP id l9so666967wme.3
 for <43103 <at> debbugs.gnu.org>; Mon, 31 Aug 2020 01:38:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=r8F8xjpCRIqIR/ViFuF5UQBhDoaUCVBWO5rGfXL0/Kc=;
 b=IDoWQr+yK0rjfQqfuyVBIE4iByW8XBq6GLuxLdgsteeNhNHBdwz9w1d0oIKIDT5A6f
 h0Zz8Xhmv35BzGB6SMmESlnxcEgCgTzP81f13G+ciP9CJhY48UNi084K6lTO9hRGKnBH
 aKM78Uo7Uuc3YMBTV9XDpvx9r5CzNM2ScY/Ah91lSo1rjXBDKiqiGCPNq6M67oaBfYck
 SYD2JxZ3gge0PcR0u5hSctzJyjJmZBS1RmCsbfjv+zkaGHR6nRbTfqBzevDWdw/qnIUN
 0vQI0JZKu09tURnE11Ew1SzL+uB2QW9u32Tvh0Ijc9iqYFvha32l95X9yB9oMraj0pCI
 vXMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=r8F8xjpCRIqIR/ViFuF5UQBhDoaUCVBWO5rGfXL0/Kc=;
 b=XH0o3snaRmH/juG+NRSjiQRBLgJCj9gDZ4CzBNOoZsjtE+z6WEOqi7FxMDa/FJy8X8
 e+y+UcV82o06l1Vd4oKiJp5YH9eXoPzThEzvY++HwV4lGW/kpnFKJ+SDcZKfooVzWQtM
 eyHid6F6TRdCEc5FdGOoCNpl96QlwBkilQs96m3AqRCm07NjoNF1uh4FtaA3FA1bSVTY
 hWcNpCyMvthsOPZbpT+ib/UQfzTkEn1RWdgWHRJxzUqlRuE5GFdNad3/uxyORuaqyk6L
 4WIa3VTMFCKqXKjeJZTYn965dOsT9eLyighVbb+mDdqgqT46dXWGARwvMOY30765slPK
 7meQ==
X-Gm-Message-State: AOAM530GlMB5IAvvoWy6UzKgKB5WQDDDz26+Ht5yfdpQVPJf4MTlFJvY
 HuCSPW8fSbkKIn1kVFAezhc=
X-Google-Smtp-Source: ABdhPJytSNCow485a/yP9IOJdK/Pag2TWdbrNrxlX3wfK31AhAVlJgkbDbn3JXe7y1LatBZkx79+lw==
X-Received: by 2002:a1c:56d6:: with SMTP id k205mr366093wmb.88.1598863102878; 
 Mon, 31 Aug 2020 01:38:22 -0700 (PDT)
Received: from krug (173.37.158.5.rev.vodafone.pt. [5.158.37.173])
 by smtp.gmail.com with ESMTPSA id x2sm11806443wrg.73.2020.08.31.01.38.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2020 01:38:22 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN>
 <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
Date: Mon, 31 Aug 2020 09:38:19 +0100
In-Reply-To: <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN> (Dmitry Gutov's
 message of "Mon, 31 Aug 2020 04:07:19 +0300")
Message-ID: <87sgc3gqh0.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:
> On 30.08.2020 18:15, Jo=C3=A3o T=C3=A1vora wrote:

> It's true, but the curious reality is that AFAIK the built-in eldoc
> functions (foremost, the Elisp one) have always used the one-line
> display, even when they could show more.
>
> These is definite wisdom in that.

I see only signs of rudimentary intial design which predates
eldoc-...-multiline-p, composition, Flymake...

> Change the default in eldoc.el. Why emacs-lisp-mode?

See subject line.

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

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

> 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.
The command pops a window to *eldoc ...*, a less restricted view into
the continuously composed results of ElDoc collection, the echo area
being a much more restricted outlet.  In the future, there could/should
be an arbitrary number of such outlets: windows, frames, tooltips, some
more restrictive, some less, some more interactive, some less.

This is beyond the scope of this bug, though.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 20:04:02 +0000
Resent-Message-ID: <handler.43103.B43103.15989042297507 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.15989042297507
          (code B ref 43103); Mon, 31 Aug 2020 20:04:02 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 20:03:49 +0000
Received: from localhost ([127.0.0.1]:53774 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCq1t-0001x0-6R
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2020 16:03:49 -0400
Received: from mail-lj1-f180.google.com ([209.85.208.180]:46233)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kCq1p-0001wi-Af
 for 43103 <at> debbugs.gnu.org; Mon, 31 Aug 2020 16:03:47 -0400
Received: by mail-lj1-f180.google.com with SMTP id h19so8118210ljg.13
 for <43103 <at> debbugs.gnu.org>; Mon, 31 Aug 2020 13:03:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=gSyaLg0nY/pP8JVqK4Vd7JI+RWS2rvtmB/E9ytCxNvY=;
 b=W8xOf1DtPhCf9uZqfW6oEJ33H8hjSCYP+5qbK+6w8pVGMxZLwsKQjQosT/03mqIMeK
 Y6/kp7gU2cBBoUQyjr3tvLH0NjvVmQsoHeUu0Npzn/XtSx6I0aQ8y/AOck+x5K0vxA70
 ZmDecwCyGETKaP9dE2xp9WHiW5i7BKrUTHafoFCtTnCXuIFgwKurGpi8avRK600w/Jcg
 Xp5CMfLFMJtZl0fcSRNIznP6rYR508RQjOq0ftdQAgSzJEg0X6ER8JvlCNstowcoxSVE
 r3xiEH+4GjdouXBk0zroD/RolC6IloRrYKde4aYdGwo5m//fQgnN2OKsG+u9BlqPwvLG
 Cj+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=gSyaLg0nY/pP8JVqK4Vd7JI+RWS2rvtmB/E9ytCxNvY=;
 b=AHHvpHzn06Y4CW2dD92kv9Aztoewx99UxbUTFeFatibdgNIbS2A4rnXrwVTz2T3Zkx
 fmDH3dQzdprHYB5zCEZsBI1vfpoE0eRdi9od47w+Qhv3umNjihgoJfLmjprIW0uv53iV
 voHm15qcEVNU3cX4ii1Z9c/UnjICCqvaffLj2+OhOnOWbp02weIen2xVxMK7vklJ2yLi
 cytUChiF+bNyuJjbyI5XjOMECYymDixdJUMPVCgVVHXnpybnmGWjwCmeD7Ve5NT+sagI
 WiSmN0YWisGVwDz2ive6HE+Qjz46YVK/FJ/J3805ixG+v7gDrJRr/YCI3NcGKeb0VUm7
 sBdA==
X-Gm-Message-State: AOAM532IFgFAkHGNbmr6nt7ueecFEeOn4lcyJC+1Ccwjt5t2BYUDUSg+
 Ob4TbwSqtuueTZKGVdLzT60=
X-Google-Smtp-Source: ABdhPJx59IuAVckjZ4AVG9ON547kG+7OqWGiyy0l4v7o32Ry+v+PfTptsdn4BT+8/KNnLUmEMUsuHg==
X-Received: by 2002:a2e:9a93:: with SMTP id p19mr1316349lji.67.1598904219010; 
 Mon, 31 Aug 2020 13:03:39 -0700 (PDT)
Received: from [192.168.0.104] ([94.229.108.16])
 by smtp.googlemail.com with ESMTPSA id d2sm1799496ljo.126.2020.08.31.13.03.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Aug 2020 13:03:38 -0700 (PDT)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN> <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
Date: Mon, 31 Aug 2020 23:03:37 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87sgc3gqh0.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.9 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)

On 31.08.2020 11:38, João Távora wrote:

>> It's true, but the curious reality is that AFAIK the built-in eldoc
>> functions (foremost, the Elisp one) have always used the one-line
>> display, even when they could show more.
>>
>> 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.

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

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

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

>> 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. The echo area is smaller in size, and has 
undesirable side-effects when its contents change height. A buffer 
doesn't have these kind of constraints.

And if we were to differentiate the buffer's presentation (for instance, 
by binding eldoc-echo-area-use-multiline-p to t inside 
eldoc-print-current-symbol-info's interactive clause), we might as well 
use a different strategy for it, too.

> The command pops a window to *eldoc ...*, a less restricted view into
> the continuously composed results of ElDoc collection, the echo area
> being a much more restricted outlet.  In the future, there could/should
> be an arbitrary number of such outlets: windows, frames, tooltips, some
> more restrictive, some less, some more interactive, some less.

Some of these have different constraints, too.

> This is beyond the scope of this bug, though.

You brought it up.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 20:26:02 +0000
Resent-Message-ID: <handler.43103.B43103.15989055509754 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.15989055509754
          (code B ref 43103); Mon, 31 Aug 2020 20:26:02 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 20:25:50 +0000
Received: from localhost ([127.0.0.1]:53803 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCqNC-0002XG-DT
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2020 16:25:50 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:33432)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1kCqNB-0002X3-Di
 for 43103 <at> debbugs.gnu.org; Mon, 31 Aug 2020 16:25:49 -0400
Received: by mail-wm1-f45.google.com with SMTP id e11so735339wme.0
 for <43103 <at> debbugs.gnu.org>; Mon, 31 Aug 2020 13:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=F4NO07rXBwyAyF2VD1nlQ/J3eznCQr74XRqaS4aI9fU=;
 b=ht9+CBejI5cSFIKYVpW5reAyQ2VeJpRFHBxyp3Uqq3qzYM9bV1sQl2yu8hgOdNNDVN
 jrLxEA+coerqtGFNJvPpnQvFbgK2Zywlg1Eg+BuYnBCuwrQQWCkCQNTbsEGEvXV59dAW
 BdsU/tfwvPmIccGJEcGPDnEMHy9X8Mf09WTVfiOFbfsi0FYY6BrLBLr6hFt5eutFjV8K
 4q4kMnoXMA0e1U4eBAvAba0w47U0l+kVYxFV6r6R2L6Z+k/LF/89cAJDmMqDCl8HkR9G
 tN0NDqPJi0mVh+wFE8NezSej+wDiiSXNb3SqAqwvzgnQh0SMvOEshPoWKjbAdjv7QHYE
 KqgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=F4NO07rXBwyAyF2VD1nlQ/J3eznCQr74XRqaS4aI9fU=;
 b=KF+b+I9jwA8y2OOL42PbUofnCmfbexy2ueEr4UaxI0IyjV4BLES16/WBSMFXNqqy8e
 zKIbdBlaEKC1BqX9kZO0GYLFzsvOoyFephy/YD9ma2OohGdgvqox75ju5rErY9JsouWp
 kGouzK5ugOTVWK2ByAdh8wn7Bj6+eQ4WtMOQ4qKbpaMFrTrjGoRB7/KHE/YhTXN5Hw7n
 Pzgl7QtDA2QHfdlU1qrsmYOPmhM10K7mw9x6ZSsDZ3uK7YhFCxOrk+hcbsAT1ATPd4di
 zNK3CfLnpJoMUj2t1Kfc5XVk3yF6BahOQh0l16qxE+4cspcKk3gB9Qfdbf8IGw+fsvAQ
 MKKA==
X-Gm-Message-State: AOAM531c3/5l4qcD5e/IIqgT4oxSkmBzIfU8bQbeLw2icA922o+VjTYL
 4z/26+PaJR4IuStT6L4oUd0=
X-Google-Smtp-Source: ABdhPJxpXed/TxaLcwsn4BtAm26i9XRkepwSV8Uv8+PR1hxzssWibdZhep62JSUDhC3vLkf6v160RA==
X-Received: by 2002:a1c:7907:: with SMTP id l7mr904563wme.89.1598905543265;
 Mon, 31 Aug 2020 13:25:43 -0700 (PDT)
Received: from krug (214.221.137.78.rev.vodafone.pt. [78.137.221.214])
 by smtp.gmail.com with ESMTPSA id q8sm13531458wrx.79.2020.08.31.13.25.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2020 13:25:42 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN>
 <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN>
 <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
Date: Mon, 31 Aug 2020 21:25:39 +0100
In-Reply-To: <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN> (Dmitry Gutov's
 message of "Mon, 31 Aug 2020 23:03:37 +0300")
Message-ID: <873642k1fg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> 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 sti=
ll
>>>> 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=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 20:49:03 +0000
Resent-Message-ID: <handler.43103.B43103.159890690011956 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159890690011956
          (code B ref 43103); Mon, 31 Aug 2020 20:49:03 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 20:48:20 +0000
Received: from localhost ([127.0.0.1]:53858 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCqix-00036m-KN
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2020 16:48:19 -0400
Received: from mail-lf1-f51.google.com ([209.85.167.51]:39250)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kCqiv-00036Y-JD
 for 43103 <at> debbugs.gnu.org; Mon, 31 Aug 2020 16:48:18 -0400
Received: by mail-lf1-f51.google.com with SMTP id q8so4285781lfb.6
 for <43103 <at> debbugs.gnu.org>; Mon, 31 Aug 2020 13:48:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=fY+E4J4yGrztN0Uwlz1qwEiq5BkHHb9mFnb3T4cINIs=;
 b=HWzn8dULluDfbJF/Ken6k0vLSZCmj3Mg6asvrclZSyACiHdryRC23IMgyOuoh4WO1+
 20PqL4kY6/f6XSTG0GXz/PtJ0R7dnS6fwYlmDcQEsRslSEOzc3TvgIQB5zXvtrz97tjo
 xscXivC1+syIVyKryiL/c3jZTz7Lx6pHZfI5wIrslgdr/Bfi+3ZWXCA0k0H4ZYr1I6jZ
 KOwOXHR7DGvUmTghujekS/cprTj6BEumt6srG+7iOULGYuIMTdc1Dr7CJfCVSP4SlQ4F
 n11YIQqAepfeCiUzDvrlpkl6cWwuC7jOVZTSzX119MbhEJ2dFipByUSX0iJSNNtawjSp
 QuVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=fY+E4J4yGrztN0Uwlz1qwEiq5BkHHb9mFnb3T4cINIs=;
 b=H9VfiGDHA1OH8p0YDifbusS6+zamqZXfp19Kto9ZFkBP5gCJRBKJrE65lDjfz9AGhO
 xc3Mtw4S4G7soWNlGR+oWo1o1cvw0Q7ivTsJCXL4irbf7Xf+FmxSB4GMAsczAhgeigLh
 j8biSoqhYM2I4FUSBO0mkCwAfJGlEStElFRhkvKXdfDW9exQH8E06XOFKCSjP6zeML9i
 tPg4Jg1W8LsAPVbz7rekzMOHiDGHl775AG4q7nOS0y8MP3g6WVJTTZs7Ulv/N6djTB4V
 GdTE63cmhXs/m6cm1XY9JCz/lYWY8Y1cizgvRgAtALoarwCwYN1QA0ufqjlb4NGWZBxo
 oeHw==
X-Gm-Message-State: AOAM531J6L1+3JrnWa4WQqUa2WR7Pm4U4SlkXXn79RxkkniVFoHpWdMe
 RbkAxw/ZCzQjG/6D9z9zpg8=
X-Google-Smtp-Source: ABdhPJwgWbTSVqjnGJFxfetkkNsfyRFVOlAZVn1BMVsbdgjizQJo6QTByyT0GgiyXM+YZ78qqI5Kjg==
X-Received: by 2002:a05:6512:3189:: with SMTP id
 i9mr1459618lfe.41.1598906891788; 
 Mon, 31 Aug 2020 13:48:11 -0700 (PDT)
Received: from [192.168.0.104] ([94.229.108.16])
 by smtp.googlemail.com with ESMTPSA id y9sm1784066lji.106.2020.08.31.13.48.10
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Aug 2020 13:48:11 -0700 (PDT)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN> <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN> <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
 <873642k1fg.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <59d878fc-98e0-26c3-e568-239638f54962@HIDDEN>
Date: Mon, 31 Aug 2020 23:48:10 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <873642k1fg.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.9 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)

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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 21:13:01 +0000
Resent-Message-ID: <handler.43103.B43103.159890833922712 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159890833922712
          (code B ref 43103); Mon, 31 Aug 2020 21:13:01 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 21:12:19 +0000
Received: from localhost ([127.0.0.1]:53920 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCr6B-0005uG-6k
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2020 17:12:19 -0400
Received: from mail-wr1-f48.google.com ([209.85.221.48]:45497)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1kCr69-0005u1-By
 for 43103 <at> debbugs.gnu.org; Mon, 31 Aug 2020 17:12:17 -0400
Received: by mail-wr1-f48.google.com with SMTP id h15so7267453wrt.12
 for <43103 <at> debbugs.gnu.org>; Mon, 31 Aug 2020 14:12:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=B6A1i5hFhz7ES2h89gJMaTPBc3dnTMA+1SIf691IZDQ=;
 b=KPoeYcmhSy3GkeTJEHo+/sbiCff8IRtkofYKmUiTbhqHv3EDjNMb/GYgXvEfHGbQIj
 VNxaEpf/JQfVpSb7xk9sj9gNb9TZAUyjlXW9Qb5+3BlkT6SyaSNL0y+fnXaHexio1FE6
 P9v6BoXzM+PlL3h+6rcdWywyHROxM+5xetPyyxZNx3eGCW/Ht4cJrOv34ESEXwJzkqJh
 swFLh9rFvhU6YMCk4wKxYPZ1b0BX7GyU+vJdRafLVjQLXjctK0wmFwE+4a/8eNKnbd2j
 28W/3Fss5yJr5uQe2Kq4XB8SH9YNDztKpARGhVJa+HpOk0aAL9jj5naNrLiaGAxT5e3o
 wSfw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=B6A1i5hFhz7ES2h89gJMaTPBc3dnTMA+1SIf691IZDQ=;
 b=rToeTOHnqjJmri4Kj05jwS6+0QWThaVuy8ChySWpmgSpMYIaMP2vEvbqDgInf92PSF
 puAkbVIU+sq9wqNCYrWWsYpT3fdU+CbgMG/yXRavvkZFFsC2pFRavbVyJHR02krbkURd
 /lrdUEQr/LY2hLUpgF7DIGBSG3Ai4Sbp7PgriheFGosPJ0t++AYxvT6wkr0CIyd3gyjh
 oAUuz53Rs98DQefx6ssRiUmCQ6dDLUI/b5Blqiu3Lc1q1bpustBQZU4mOC0BDkiUpemL
 8ZjgqTsYl1kmmGk5s0lf3xsC85zjqSKKx22leGXx0bTdpQpUg7cIQR0mEU6ZHO0zkj3I
 2s6Q==
X-Gm-Message-State: AOAM532C/xHvz5K2X7LNmZsaRQ3wvIhvGpqTvbbVLtXGiclDvBBp0k7v
 nFxfu2qCEe+beD1TW6DaZpw=
X-Google-Smtp-Source: ABdhPJyRbNo5cAhC/6RPIluOAb5LMnhW1OVz0EEgOEdZsEj0ZueBfAe6hehQFD0oIvHL/2uZch7gjg==
X-Received: by 2002:a05:6000:110b:: with SMTP id
 z11mr3385179wrw.426.1598908331510; 
 Mon, 31 Aug 2020 14:12:11 -0700 (PDT)
Received: from krug (214.221.137.78.rev.vodafone.pt. [78.137.221.214])
 by smtp.gmail.com with ESMTPSA id 201sm1109369wma.27.2020.08.31.14.12.10
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2020 14:12:10 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN>
 <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN>
 <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
 <873642k1fg.fsf@HIDDEN>
 <59d878fc-98e0-26c3-e568-239638f54962@HIDDEN>
Date: Mon, 31 Aug 2020 22:12:09 +0100
In-Reply-To: <59d878fc-98e0-26c3-e568-239638f54962@HIDDEN> (Dmitry Gutov's
 message of "Mon, 31 Aug 2020 23:48:10 +0300")
Message-ID: <87wo1eikpi.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 31.08.2020 23:25, Jo=C3=A3o T=C3=A1vora 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.

The echo area is not one of the new tools.

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

Shall I enumerate variables that are set differently per major-mode?
Your argument is very odd: every major mode has different behaviours,
including for example the shape and form of the elements of
eldoc-documentation-functions.

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

But you don't know in general the form of each of those, or if there may
be more, or other characteristics.

>>>>>> - even if eldoc-echo-area-use-multiline-p is set to nil, users can s=
till
>>>>>> get to all the info collecte by ElDoc with the new
>>>>>> `eldoc-documentation-compose` strategy by pressing M-x eldoc-doc-buf=
fer
>>>>>
>>>>> 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?

Yes.

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

Hopefully you understand now.  I've told you all I know.

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

Try M-x eldoc and global-set-key and tell us what's missing. I don't
know how this relates to the ElDoc buffer or its purported "weirdness".

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 21:22:01 +0000
Resent-Message-ID: <handler.43103.B43103.159890887223697 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159890887223697
          (code B ref 43103); Mon, 31 Aug 2020 21:22:01 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 21:21:12 +0000
Received: from localhost ([127.0.0.1]:53954 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCrEl-0006A9-Ms
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2020 17:21:11 -0400
Received: from mail-lj1-f196.google.com ([209.85.208.196]:41420)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kCrEg-000699-H7
 for 43103 <at> debbugs.gnu.org; Mon, 31 Aug 2020 17:21:09 -0400
Received: by mail-lj1-f196.google.com with SMTP id y4so7328291ljk.8
 for <43103 <at> debbugs.gnu.org>; Mon, 31 Aug 2020 14:21:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=SSv7U0U6y+tHiOTsKEtC9hVk8br6+fvvdu5vbKinnf4=;
 b=OC3eWTw2CEWzP6E5G+P48P6DykNPBk4qtU1x+NoTPRa9jLZjCExr27RKT1rEO1clyl
 K3F77D8Q/S1RM2ImdZZpqg8+dH3dsJyK88OKnFFO0nJ+SxzjrFnm/sNO6LELe3VJggHD
 qAYhNFLJ7y4am8yeZ4H9CNE2S5NziO6gfdEL9GTSl+AzBvXDM79Y6d1mo2VELy7t3CyM
 RkWvyCimqRF21PPVTWwkHy7YD6uFojvjHmZfJK9uiWZWI3yH1pG9IxUDuilo2rk0PTHK
 fSEgG7YMIrFbu40F0duBfNAseZ6wTj2F47qdqs+OnLxrBw4K/o91uAizdgx/wqgfrvX+
 18pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=SSv7U0U6y+tHiOTsKEtC9hVk8br6+fvvdu5vbKinnf4=;
 b=t3QQLvlmZvHvIMvuGttH/N8O44O3UOmWXnOEOzaT0yCpJz/s1vqGfDxNnORvRlRBuL
 RKuhJ6U8X/ucLJB4EIEvoEQ7qISBtLo+/r1bGdlHu9wA/f5Beoc/g27jFiyIlWysFe2E
 uPcw3nCsnERfPKIz+aWjFfRAaialiJqUCfrp+oUl/H4fklESvGPeInRGfBXR1My8ft8F
 1O+NocabpubdXRCALAo2N1GaldL96Ne+8wz+03+gV44fVZcEXRnQ+GTPtYhZ5gp2QoTr
 aFW/LWTa16xJSvshqk1qNx+33j+m7PVGYZxn2YOYoLxUUWUZkMryv7s6egh1+mUOlDsS
 tCBw==
X-Gm-Message-State: AOAM532pAhAQJi+wP1W6NHpZhjaYb83nbfnz1GI7Uu1JTsGOJ8g+RxDw
 iQafZ9R3JVN0NBYutPjG+cM=
X-Google-Smtp-Source: ABdhPJxcvUAEynBewA4Ujz8RewxaZ0NjvPwaU3vGXKLohG22x7FKyn7zV2g2esSMLNsZSs2ftPspZA==
X-Received: by 2002:a2e:6f17:: with SMTP id k23mr1526045ljc.245.1598908860445; 
 Mon, 31 Aug 2020 14:21:00 -0700 (PDT)
Received: from [192.168.0.104] ([94.229.108.16])
 by smtp.googlemail.com with ESMTPSA id g63sm2225600lfd.28.2020.08.31.14.20.59
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 31 Aug 2020 14:20:59 -0700 (PDT)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN> <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN> <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
 <873642k1fg.fsf@HIDDEN> <59d878fc-98e0-26c3-e568-239638f54962@HIDDEN>
 <87wo1eikpi.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <84b1d158-8f97-3b79-91cf-22ab2cb58e9c@HIDDEN>
Date: Tue, 1 Sep 2020 00:20:59 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87wo1eikpi.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.9 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)

On 01.09.2020 00:12, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>> 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.
> 
> The echo area is not one of the new tools.

You're making my point here.

>> Many of us here program in multiple programming languages.
>>
>> Having major modes exhibit different behaviors where they don't have
>> to is jarring.
> 
> Shall I enumerate variables that are set differently per major-mode?
> Your argument is very odd: every major mode has different behaviours,
> including for example the shape and form of the elements of
> eldoc-documentation-functions.

One reason we create minor modes, unified bindings, and so on, is to 
make the behavior in general more predictable and uniform. So that one 
doesn't need to re-learn Emacs entirely when editing a file in a 
different format.

>> They don't have multiple documentation sources? One from major mode,
>> another from Flymake, at least.
> 
> But you don't know in general the form of each of those, or if there may
> be more, or other characteristics.

That looks like a drawback of your latest redesign (which I pointed out 
previously, but who cares about that). The strategy is a global 
variable, and it's user-customizable.

And yet, somehow, now you're getting worried that different strategies 
might only suit some major modes?

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

The command. Not the strategy?

>> 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.
> 
> Hopefully you understand now.  I've told you all I know.

You seem to have been answering a different question.

>> 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.
> 
> Try M-x eldoc and global-set-key and tell us what's missing.

Already told you. I'm not sure how many different ways I can explain 
things, if you keep snipping those explanations out.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 31 Aug 2020 22:51:02 +0000
Resent-Message-ID: <handler.43103.B43103.159891422531855 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.159891422531855
          (code B ref 43103); Mon, 31 Aug 2020 22:51:02 +0000
Received: (at 43103) by debbugs.gnu.org; 31 Aug 2020 22:50:25 +0000
Received: from localhost ([127.0.0.1]:54043 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kCsd7-0008Hi-Cg
	for submit <at> debbugs.gnu.org; Mon, 31 Aug 2020 18:50:25 -0400
Received: from mail-wm1-f54.google.com ([209.85.128.54]:51664)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1kCsd4-0008HO-5H
 for 43103 <at> debbugs.gnu.org; Mon, 31 Aug 2020 18:50:24 -0400
Received: by mail-wm1-f54.google.com with SMTP id w2so972103wmi.1
 for <43103 <at> debbugs.gnu.org>; Mon, 31 Aug 2020 15:50:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=t0q8D0IrrBG0v+G7RzKjfHMqGeeEII78LQJTLp8RXxk=;
 b=hFAPB4z/EHhQOyJnNogI3l22M94DYZAHkmyM2kgy72aUKnS2tfA6DzkIPS15FBSdJz
 vP7LxTqQbIKWbNHrAw8T1x4PaHb/pTC3GfWjKBkHI7CQzUnXwDgwOyK25NO3/BKerE5j
 y3plTRK7Ko8gGscLiUoC1Be4eFEMu+YXIFQqjfF2Z7OId58ydHR8uCGtk7ppRxj6kWZQ
 POx6ETflDitCEEv/EIyzzSrsWuMzuFy2glpjSf6wI0SoNG0ogAsYBDIHSpm8k0jvsTej
 Yo7hyj0OiI3YkmSWf4n8hFFms7OB3APpO8XODUNDmR/PD94GB9rNjKNvOJa+cB1rpW8y
 56Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=t0q8D0IrrBG0v+G7RzKjfHMqGeeEII78LQJTLp8RXxk=;
 b=PKORyIok0m6WIoTSMk1NzytYgbcJJ1e4+LnV+JOjj9Ur7lBvO4xLfi4n4cY3tq+bTp
 77s0LELDZfNhZa9KMbu7kvKbvBA3u0qWXtxfzSTEI34I2i4dOtNH4HRiez12SphMjW1L
 RuibowK5RDKahpVi3j/dwCbhqrF0ehCEt3Jp9r9nsMJBtwfOFag82OxsUf7hU49X3/c2
 DS0RKbpAc5KMV4r4zSYUavuffveJ+mDkr4bg1dX1SCBLgEY5M/HEX1YUy/rSwPmQdjrS
 jvLAN1w3iJJ+M63RgB2T4JIf1xwrVGopBBsdsULx8HZ5yzkfIb66uUwqY9mt0KQjOc4S
 p4kw==
X-Gm-Message-State: AOAM531zrw7LbhVs3BvmRze3GUCX9t9nSLqm/0h+l8e+v0AhufOgctSe
 S9e6RMKEfFZUfAtYdK+4C1k=
X-Google-Smtp-Source: ABdhPJxKn1bN8ixBUj5zF943Anv6odxC0uruaR5N584m5NC7TIV5bo2qpQ1+6hZlzoOiWSnd+g6uCw==
X-Received: by 2002:a7b:c0c8:: with SMTP id s8mr1399005wmh.4.1598914216181;
 Mon, 31 Aug 2020 15:50:16 -0700 (PDT)
Received: from krug (214.221.137.78.rev.vodafone.pt. [78.137.221.214])
 by smtp.gmail.com with ESMTPSA id o4sm11256783wrv.86.2020.08.31.15.50.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 31 Aug 2020 15:50:14 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN>
 <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN>
 <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
 <873642k1fg.fsf@HIDDEN>
 <59d878fc-98e0-26c3-e568-239638f54962@HIDDEN>
 <87wo1eikpi.fsf@HIDDEN>
 <84b1d158-8f97-3b79-91cf-22ab2cb58e9c@HIDDEN>
Date: Mon, 31 Aug 2020 23:50:12 +0100
In-Reply-To: <84b1d158-8f97-3b79-91cf-22ab2cb58e9c@HIDDEN> (Dmitry Gutov's
 message of "Tue, 1 Sep 2020 00:20:59 +0300")
Message-ID: <87sgc2ig63.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 01.09.2020 00:12, Jo=C3=A3o T=C3=A1vora wrote:
>> Dmitry Gutov <dgutov@HIDDEN> writes:
>>=20
>>> On 31.08.2020 23:25, Jo=C3=A3o T=C3=A1vora 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.
>> The echo area is not one of the new tools.
> You're making my point here.

If you say so, I really have no clue what your point is.  The echo area
has been there from ElDoc's first design, it is not one of the new tools
that ElDoc offers now.

For your benefit, and to wrap up this exchange, here's a summary of what
I propose: In Elisp mode, I've experimented with the
`eldoc-documentation-compose` strategy and I like the results: it's
useful to have Elisp function signatures, Elisp variable documentation
and Elisp diagnostics displayed somewhere, constantly updated.  I think
other people would like these things, hence my proposal.  I don't mind
the echo area jumping in height one or two lines once in a while, but if
others do, there are tools to control it, which we can leverage to good
effect.  That's it.

>>> 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.
>> Try M-x eldoc and global-set-key and tell us what's missing.
>
> Already told you. I'm not sure how many different ways I can explain
> things, if you keep snipping those explanations out.

You said you wished for a command to "show documentation" and I pointed
you to M-x eldoc, a new command which seems to do what you want, and
that you might not be aware of since it wasn't discussed.  If you don't
wish to pursue this suggestion, fine.  I am in no obligation to waste my
time replying to every new off-topic point you bring up, I do so only
where I think I can add value.  Bickering with you is not one of those
things.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Sep 2020 10:53:01 +0000
Resent-Message-ID: <handler.43103.B43103.15989575316308 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.15989575316308
          (code B ref 43103); Tue, 01 Sep 2020 10:53:01 +0000
Received: (at 43103) by debbugs.gnu.org; 1 Sep 2020 10:52:11 +0000
Received: from localhost ([127.0.0.1]:55213 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kD3tb-0001df-7G
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2020 06:52:11 -0400
Received: from mail-lf1-f52.google.com ([209.85.167.52]:37930)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kD3tY-0001dR-BE
 for 43103 <at> debbugs.gnu.org; Tue, 01 Sep 2020 06:52:09 -0400
Received: by mail-lf1-f52.google.com with SMTP id y11so503581lfl.5
 for <43103 <at> debbugs.gnu.org>; Tue, 01 Sep 2020 03:52:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=A31Kek3VhhE2V8xbLKQ6pmRSEQhf77wjkFRvW6ukSrk=;
 b=vJtakL31nwnN5PxD4f5xaeJODyWj70+7ZrZC+VUEJwX+2HdPOEhJ77J1dw8nzswIO1
 ClEMVRHajhpZtiy58H5AMpO54koipVXjz08WT9PHDcQBH7y8NotWLcVqfl3FYCrYWubp
 zaZmu/yDjxiPlEDHdrxJn4bTsbGG0OcscHzMLPYc5+vKVMm5Eaqt+NfccTxoEWZc5kYa
 lbxvlhoU3eO9M0U+5c7IfYMcGvD9JywvEwdRN5ZIxhQ2e0CY/vQk7KcDXEyO2jN8Zv1H
 Wt0AmL9l2C010oErmX3liH6T5lDvHrSJ3gncnKtcmgUbaIHr0Pebj7axfjZW5T/+FmnJ
 /FSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=A31Kek3VhhE2V8xbLKQ6pmRSEQhf77wjkFRvW6ukSrk=;
 b=CtPWyP+6Kw5MzLChJUxknkCxtOXP7Wk8hcKZ9eQbaK9yrQX+Tp4BD8UOiWNaTgNedf
 v4dzIzrWrgwFDUcT+to6fNWvyQAJZhwTyYA9q6INljQ4nrgseT0yx/yfxdBl54SRs2c9
 fTHGsr7rM0bUlQ7Dka6G9JbiilLGiDxbcd4UuybwvsUdhMORGje8clWWX3qhGMJs4LsO
 GrwNt7MBQ3qH1Arq+p86K6bmZy/v9Kq6NwqnTgs/ft28VRpDYD3FMqkGBN7GXIRiPEW3
 je59bG+fh7FmSt8TYVWWiUxY1YUEnvVKLyLPKJVlY31aP1aBGsU9CvXUhiFt0nZm86ka
 w32A==
X-Gm-Message-State: AOAM530ql0uKL+GPYvIx2hqP2P0xH/wxIgwUBo/iacgW/GmE/TWTQX8M
 TcHymrUuxluT+UrqU1064Tg=
X-Google-Smtp-Source: ABdhPJyZx2ZAsrX/Icx1SH3nG6FtrUq63Zb6r9/dtZyuosyMWZJSzGBlfZfhbyT14gW/2TzH1smP+A==
X-Received: by 2002:a05:6512:3143:: with SMTP id
 s3mr310512lfi.154.1598957522119; 
 Tue, 01 Sep 2020 03:52:02 -0700 (PDT)
Received: from [192.168.0.104] ([94.229.108.16])
 by smtp.googlemail.com with ESMTPSA id y5sm194867lfy.88.2020.09.01.03.52.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Sep 2020 03:52:01 -0700 (PDT)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN> <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN> <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
 <873642k1fg.fsf@HIDDEN> <59d878fc-98e0-26c3-e568-239638f54962@HIDDEN>
 <87wo1eikpi.fsf@HIDDEN> <84b1d158-8f97-3b79-91cf-22ab2cb58e9c@HIDDEN>
 <87sgc2ig63.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <cbd83df6-8af5-7e98-b2ec-752ee8bc1d4c@HIDDEN>
Date: Tue, 1 Sep 2020 13:52:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87sgc2ig63.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.9 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)

On 01.09.2020 01:50, João Távora wrote:

> The echo area
> has been there from ElDoc's first design, it is not one of the new tools
> that ElDoc offers now.

My point is -- as is well-known -- the echo area has a long-standing 
problem. If the message is multiline, the windows will jump. Since the 
echo area is still the main means of conveying Eldoc notifications, 
changing Eldoc behavior to multiline messages is problematic.

> For your benefit, and to wrap up this exchange, here's a summary of what
> I propose: In Elisp mode, I've experimented with the
> `eldoc-documentation-compose` strategy and I like the results: it's
> useful to have Elisp function signatures, Elisp variable documentation
> and Elisp diagnostics displayed somewhere, constantly updated.

Indeed.

> I think
> other people would like these things, hence my proposal.  I don't mind
> the echo area jumping in height one or two lines once in a while,

I mind. Unfortunately.

> but if
> others do, there are tools to control it, which we can leverage to good
> effect.  That's it.

What tools?

>>>> 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.
>>> Try M-x eldoc and global-set-key and tell us what's missing.
>>
>> Already told you. I'm not sure how many different ways I can explain
>> things, if you keep snipping those explanations out.
> 
> You said you wished for a command to "show documentation" and I pointed
> you to M-x eldoc, a new command which seems to do what you want, and
> that you might not be aware of since it wasn't discussed.

And I told you its semantics are broken.

Showing the text intended to be displayed in the echo area (one line, 
usually; maybe a few) in a full-size window is ridiculous.

> If you don't
> wish to pursue this suggestion, fine.  I am in no obligation to waste my
> time replying to every new off-topic point you bring up, I do so only
> where I think I can add value.  Bickering with you is not one of those
> things.

If you try actually reading what I wrote, you might find some actionable 
suggestions there.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Sep 2020 11:12:01 +0000
Resent-Message-ID: <handler.43103.B43103.15989587108084 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.15989587108084
          (code B ref 43103); Tue, 01 Sep 2020 11:12:01 +0000
Received: (at 43103) by debbugs.gnu.org; 1 Sep 2020 11:11:50 +0000
Received: from localhost ([127.0.0.1]:55239 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kD4Cb-00026K-Qp
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2020 07:11:50 -0400
Received: from mail-wr1-f43.google.com ([209.85.221.43]:39236)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1kD4CZ-000264-5R
 for 43103 <at> debbugs.gnu.org; Tue, 01 Sep 2020 07:11:48 -0400
Received: by mail-wr1-f43.google.com with SMTP id a17so1049247wrn.6
 for <43103 <at> debbugs.gnu.org>; Tue, 01 Sep 2020 04:11:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:references:date:in-reply-to:message-id
 :user-agent:mime-version:content-transfer-encoding;
 bh=Sv8SS2L7w52jN150HmmtC5yjVhmb6zS4XeLSTslhzIs=;
 b=EWpgWxoALC0RgSJE2/zJMK0lEcBlEAkH1L0EONwfuB1H3L4h7uYqJwPsdn0wQHzENK
 8anFvyBdMfR+lwFqh2O2oq9znVa9OgPbZR0XLpt5JmmlAuAXp02nPCMir955FPxKr7Ez
 U5veebwpTcFQdSmDAsknzvU8e5IrWu1Mz8KO7LcBEqcvvhVrlmgoPlS8yCpRNfqCRogg
 YTp5gecTVAtCbQvRFfZCSxa5638qhxx4UnFEY94gWFEfe6OI/a3BlZOCnDuN2uXAiwn6
 M4UA5eRDavZlC75eO/HCujLhqV+xW7ZBCRHoqEN3S7WoP45yg6jFWn5mEgCGjwO6ptJU
 NHnw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to
 :message-id:user-agent:mime-version:content-transfer-encoding;
 bh=Sv8SS2L7w52jN150HmmtC5yjVhmb6zS4XeLSTslhzIs=;
 b=KYXz3DNt3E6x+Ly8nAQEjEsOX0lwPWXdLY6DGqG4nCdSsOyBC9Se/rpvkxxqSZoUyl
 s6eL0G6eNWRK0RBdSUo+EUUlpA8qRI/1S3i1NFyvPf7Q9FAnQovR83iMA4eEZxNMruDy
 jTwbzAwPx5VUJgFNVUpiw3sDZbvXToRRSDSkEhUnvMgQo3KUiROXFodRpmVTB5roFo2Z
 XFeCoqds8JUiXdJEKAC6r9aQFqyRLmHPTQGk1n3/oWBrTd2Xg/Mr9gkUnqhweDPlN3p/
 RrCMSq2phcXRU42dwyC6DN6gmsz92fHT+vB2R78ErFaVurwGTTtX1BBDWVvHrt/Bm18F
 xrhQ==
X-Gm-Message-State: AOAM530ZVJcqI5+WEFLClaMQNEuXrKtKIAAuxY0qlm1mf95mk3JL+qhH
 g++57R6JflimvOtS8dyiTQQ=
X-Google-Smtp-Source: ABdhPJz6DlnQHYsQ4ghRzp91T+ebVFrUWHm6lrLbqalIkyLeKKi0S3Dw68RlgaxGZtVFxVjTgMBYJA==
X-Received: by 2002:adf:e54f:: with SMTP id z15mr1292531wrm.136.1598958701482; 
 Tue, 01 Sep 2020 04:11:41 -0700 (PDT)
Received: from krug (77.68.108.93.rev.vodafone.pt. [93.108.68.77])
 by smtp.gmail.com with ESMTPSA id h185sm1494361wme.25.2020.09.01.04.11.39
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 01 Sep 2020 04:11:40 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN>
 <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN>
 <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
 <873642k1fg.fsf@HIDDEN>
 <59d878fc-98e0-26c3-e568-239638f54962@HIDDEN>
 <87wo1eikpi.fsf@HIDDEN>
 <84b1d158-8f97-3b79-91cf-22ab2cb58e9c@HIDDEN>
 <87sgc2ig63.fsf@HIDDEN>
 <cbd83df6-8af5-7e98-b2ec-752ee8bc1d4c@HIDDEN>
Date: Tue, 01 Sep 2020 12:11:37 +0100
In-Reply-To: <cbd83df6-8af5-7e98-b2ec-752ee8bc1d4c@HIDDEN> (Dmitry Gutov's
 message of "Tue, 1 Sep 2020 13:52:00 +0300")
Message-ID: <87mu29iweu.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Dmitry Gutov <dgutov@HIDDEN> writes:

>> other people would like these things, hence my proposal.  I don't mind
>> the echo area jumping in height one or two lines once in a while,
>
> I mind. Unfortunately.
>
>> but if
>> others do, there are tools to control it, which we can leverage to good
>> effect.  That's it.
>
> What tools?

eldoc-echo-area-use-multiline-p, as I mentiond at least 3 times in this
thread.

>> You said you wished for a command to "show documentation" and I
>> pointed
>> you to M-x eldoc, a new command which seems to do what you want, and
>> that you might not be aware of since it wasn't discussed.

> And I told you its semantics are broken.

I think you are still confusing M-x eldoc and M-x eldoc-doc-buffer,
which are two different commands.  For the record, both commands and
surrounding functionality can and probably will be improved.

> Showing the text intended to be displayed in the echo area (one line,
> usually; maybe a few) in a full-size window is ridiculous.

This is not true in the generality of ElDoc usage, of course: LSP users
are confronted with very verbose at-point documentation.  And a window
and buffer in Emacs are not the same thing, something I assumed you
knew.

>> If you don't
>> wish to pursue this suggestion, fine.  I am in no obligation to waste my
>> time replying to every new off-topic point you bring up, I do so only
>> where I think I can add value.  Bickering with you is not one of those
>> things.
>
> If you try actually reading what I wrote, you might find some
> actionable suggestions there.

I told you at least once that it's rude to accuse other people of not
reading your emails.  It's a lie and a disrespect for the precious time
they invest in reading them and replying to them as they see fit.  Not
to mention wholly unproductive.  Because I don't have time for this, I'm
putting you in my ignore list, joined by very few, if anyone.  So now
you'll _know_ that I won't be reading what you write, and the reason why
I won't.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy)
Resent-From: Dmitry Gutov <dgutov@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 01 Sep 2020 11:25:01 +0000
Resent-Message-ID: <handler.43103.B43103.15989594449258 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 43103
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 43103 <at> debbugs.gnu.org, larsi@HIDDEN, monnier@HIDDEN
Received: via spool by 43103-submit <at> debbugs.gnu.org id=B43103.15989594449258
          (code B ref 43103); Tue, 01 Sep 2020 11:25:01 +0000
Received: (at 43103) by debbugs.gnu.org; 1 Sep 2020 11:24:04 +0000
Received: from localhost ([127.0.0.1]:55263 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1kD4OR-0002PG-Qx
	for submit <at> debbugs.gnu.org; Tue, 01 Sep 2020 07:24:04 -0400
Received: from mail-lj1-f171.google.com ([209.85.208.171]:40491)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1kD4OQ-0002Oj-C0
 for 43103 <at> debbugs.gnu.org; Tue, 01 Sep 2020 07:24:02 -0400
Received: by mail-lj1-f171.google.com with SMTP id s205so1033136lja.7
 for <43103 <at> debbugs.gnu.org>; Tue, 01 Sep 2020 04:24:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:to:cc:references:from:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=wqSGog/mLFFnXNsjMgMHSNhSmLETgolt2JJLEwPnzow=;
 b=iKzsg3QssYL1yRDZ97GPZtbUyr2/BHXHD+EXbkd6MAmsMvrl9txbs2D1WkAhVtoHBP
 Dppw2Twq/rGjc9jhVJAVDfu4Ix6W5v2ViP+ivLtDrpte+oYg/2Mw/zvdv3UKjIEf83Os
 ukOBc6B+RfVcmYNdkS7wmnLXUsE11cn6VIkDWufS/opk0nNn4j0JjeFEfjSktB2dww+o
 oXIT4LUE1hrAbS+jo3SVeJ4Px8kpQpgOJVy4Gw92OzxY+f/YRqCRlfmr8rdQFHkadvNB
 VkqCM06qLkIq5LM63fIy0VPfCn33D+ZhyUmX1lr53vp8braTuI6enQe8ZgFu5PPAWpTY
 Znog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:to:cc:references:from:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=wqSGog/mLFFnXNsjMgMHSNhSmLETgolt2JJLEwPnzow=;
 b=CjYgn0HTdWK5RoRgjh/QrRulHbBdC+1ch2SSkokkqQGA0bijFoFYQA2dGkncS4lVwU
 0WQEFAoAKH+PeoOlWDk6NDaV8HW2OYFKCnW2lLkhH0CG8yp7ZR6obbHIBvU00Iqf3i5i
 9D2sZygWNTAxYzwKP/dhi1lmIqCkgvBfk9UupYl2IIYeKHLHm0Hz1dkx+J6y0jAUPz/A
 NH9s2Ut2ZD6dtWCy44yU+Jym38O/Tc5lgHUPe8Ngq0pJlSO6r1RyYx7PMPUexHhSbMa7
 azAKizTfEPdeU6zWOAKFZIEik4CmlWB9u8nThzUEGB8E5mhuUWw5t0xzHydrLCwF7jCD
 xswg==
X-Gm-Message-State: AOAM531CmwXII7tVd7yUZZo8j8OFY16Rk7IicicKZMs5mPKk+7Unmvhs
 lB4JkB8THULZ/5G4gE0Ie38=
X-Google-Smtp-Source: ABdhPJwtvcE83RqKyM3MtrsrxfhfiPUuLJimmZZYbitkcQU3HKRG0bv/wXJ6KSMLbhPV88ydA19gpQ==
X-Received: by 2002:a2e:3012:: with SMTP id w18mr376246ljw.61.1598959436294;
 Tue, 01 Sep 2020 04:23:56 -0700 (PDT)
Received: from [192.168.0.104] ([94.229.108.16])
 by smtp.googlemail.com with ESMTPSA id x73sm212301lfa.94.2020.09.01.04.23.54
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 01 Sep 2020 04:23:55 -0700 (PDT)
References: <87h7sla2gc.fsf@HIDDEN> <83wo1hxx4c.fsf@HIDDEN>
 <87r1rpigff.fsf@HIDDEN> <83tuwlxqow.fsf@HIDDEN>
 <87k0xhi51w.fsf@HIDDEN> <83blisxl9o.fsf@HIDDEN>
 <878sdwi2ra.fsf@HIDDEN> <a1eea8fb-f0d9-3eca-42c2-1605dd2e07f2@HIDDEN>
 <87sgc3gqh0.fsf@HIDDEN> <60560e93-40e8-b7bf-1339-fbd48c792588@HIDDEN>
 <873642k1fg.fsf@HIDDEN> <59d878fc-98e0-26c3-e568-239638f54962@HIDDEN>
 <87wo1eikpi.fsf@HIDDEN> <84b1d158-8f97-3b79-91cf-22ab2cb58e9c@HIDDEN>
 <87sgc2ig63.fsf@HIDDEN> <cbd83df6-8af5-7e98-b2ec-752ee8bc1d4c@HIDDEN>
 <87mu29iweu.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <27f4163b-5f34-1df8-7992-cbeb7920f545@HIDDEN>
Date: Tue, 1 Sep 2020 14:23:54 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <87mu29iweu.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.9 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)

On 01.09.2020 14:11, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>>> other people would like these things, hence my proposal.  I don't mind
>>> the echo area jumping in height one or two lines once in a while,
>>
>> I mind. Unfortunately.
>>
>>> but if
>>> others do, there are tools to control it, which we can leverage to good
>>> effect.  That's it.
>>
>> What tools?
> 
> eldoc-echo-area-use-multiline-p, as I mentiond at least 3 times in this
> thread.

In my very first message, I asked what's the point of changing the 
strategy if we set this variable to nil.

Please pay attention.

>>> You said you wished for a command to "show documentation" and I
>>> pointed
>>> you to M-x eldoc, a new command which seems to do what you want, and
>>> that you might not be aware of since it wasn't discussed.
> 
>> And I told you its semantics are broken.
> 
> I think you are still confusing M-x eldoc and M-x eldoc-doc-buffer,
> which are two different commands.

Ah, that very well may be.

But if so, your advice wasn't great. M-x eldoc (if it only uses the echo 
area) is for showing small hints, not for showing documentation.

> For the record, both commands and
> surrounding functionality can and probably will be improved.

Indeed.

>> Showing the text intended to be displayed in the echo area (one line,
>> usually; maybe a few) in a full-size window is ridiculous.
> 
> This is not true in the generality of ElDoc usage, of course: LSP users
> are confronted with very verbose at-point documentation.

And very verbose eldoc messages, then?

> And a window
> and buffer in Emacs are not the same thing, something I assumed you
> knew.

Your point being?

The said buffer is subsequently displayed in a normal window. Not in a 
"mini" window akin to minibuffer.

>>> If you don't
>>> wish to pursue this suggestion, fine.  I am in no obligation to waste my
>>> time replying to every new off-topic point you bring up, I do so only
>>> where I think I can add value.  Bickering with you is not one of those
>>> things.
>>
>> If you try actually reading what I wrote, you might find some
>> actionable suggestions there.
> 
> I told you at least once that it's rude to accuse other people of not
> reading your emails.  It's a lie and a disrespect for the precious time
> they invest in reading them and replying to them as they see fit.

And it's not rude to snip off a third of the message your are replying 
to without any good reason?

> Not
> to mention wholly unproductive.  Because I don't have time for this, I'm
> putting you in my ignore list, joined by very few, if anyone.  So now
> you'll _know_ that I won't be reading what you write, and the reason why
> I won't.

It must be fun to see (or not see) one's commits surprisingly reverted 
because of a message you chose not to read.

Last modified: Tue, 1 Sep 2020 11:30:02 UTC

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