From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#43103: 28.0.50; Default ElDoc composition strategy in Elisp mode (eldoc-documentation-strategy) Date: Sat, 29 Aug 2020 16:36:51 +0100 Message-ID: <87h7sla2gc.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10460"; mail-complaints-to="usenet@ciao.gmane.io" To: 43103@debbugs.gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Aug 29 17:38:17 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kC2vp-0002cK-MS for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Aug 2020 17:38:17 +0200 Original-Received: from localhost ([::1]:56552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kC2vo-0007EQ-Hj for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 29 Aug 2020 11:38:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47636) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kC2va-0007EF-Ff for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2020 11:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37341) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kC2va-0007Yi-6T for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2020 11:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kC2va-0002kV-2X for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2020 11:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 29 Aug 2020 15:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 43103 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org, larsi@gnus.org, monnier@iro.umontreal.ca Original-Received: via spool by submit@debbugs.gnu.org id=B.159871542510496 (code B ref -1); Sat, 29 Aug 2020 15:38:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 29 Aug 2020 15:37:05 +0000 Original-Received: from localhost ([127.0.0.1]:48887 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kC2uf-0002jE-3M for submit@debbugs.gnu.org; Sat, 29 Aug 2020 11:37:05 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:34436) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kC2uZ-0002ie-SG for submit@debbugs.gnu.org; Sat, 29 Aug 2020 11:37:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47500) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kC2uZ-0006SH-L4 for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2020 11:36:59 -0400 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:34979) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kC2uX-0007Uf-Lt for bug-gnu-emacs@gnu.org; Sat, 29 Aug 2020 11:36:59 -0400 Original-Received: by mail-wr1-x435.google.com with SMTP id e16so1912635wrm.2 for ; Sat, 29 Aug 2020 08:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=tfqzrSUpsfmjF9ZyFejE9hdvX0399J9G3JhIasZB7vE=; b=jZK+gti/w5wCUAXEVOWY0T4HrJHMVadRk13rWV0KKxMF9oPHbAykijVOvfc/6EpvXg nNzVgPZIDlFAximsmYJ2NbW/vO7BVNTBj5ziACgJyfzFdLP1HBcDtboy4FCLR3h46779 7LUqFfwSggel6GpmqIVYiUBr99KTXTIOwIi7oZ5E4I0yzzdYITMbR6Cw54JgmeGd31F0 4UvXahWbTQ9Bxp9zYT3q5eHi4Q/5nD60cr2MN1C0Y6r+sBzFq4YjYR0Muk3qBbKxCLiE hXqwj4ViEUuqhhy9YUYdoqYA/xfONELlnLW+xE6wHZhxdzXy/7h2YKF0NxO5hABvvfRk FNmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=tfqzrSUpsfmjF9ZyFejE9hdvX0399J9G3JhIasZB7vE=; b=eME2qDvWYWzHIfVoV38keVbdgOtHXo0gB0dGnK8kRZdmA7kv6q/aXYnG663epaaR/I Qi5KoDGYIFn1RBRmnBSRo/M8dfK1R1q/MxxhKhPclBrmjq4RzWkmeP3jg6cwStzeu4Il 3ootHxnsl2jRDGBjt+6rRfu5cw/yCVHPseUjBOMcDg+xEcXzyaAGk4/21ksfDlblUQO/ nEDR0eniZY5h8H/r/+ndkc+hLjVh6idCkOtQal36vN4YQ+msDiARknmcFZx+Hcyp28If 8Izg0MoEcTi/Z1G22gBupCJzVK/S4VpmFPM/mwoQStAXdEWkkFGSXCmRg1FMtMspZy7t Pyhw== X-Gm-Message-State: AOAM530W0xDDhODrndMYqIXf9O0sBo7WTCTRLgbhaDl98qeoGZ7q1BMP VuSKzxxfI95LaqNtZQPKqvo= X-Google-Smtp-Source: ABdhPJzjO0IvV2tsulxtOpe/DFgHUAQ7Ffuzx668TMfo86V1QAQtCnVfj4qmwYkcyQQSdLs36HbQUQ== X-Received: by 2002:adf:83c3:: with SMTP id 61mr1181016wre.287.1598715415444; Sat, 29 Aug 2020 08:36:55 -0700 (PDT) Original-Received: from krug (a83-132-192-71.cpe.netcabo.pt. [83.132.192.71]) by smtp.gmail.com with ESMTPSA id g9sm4117394wrw.63.2020.08.29.08.36.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 29 Aug 2020 08:36:54 -0700 (PDT) Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x435.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:186646 Archived-At: 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