GNU logs - #41531, boring messages

Message sent to monnier@HIDDEN, dgutov@HIDDEN, andreyk.mad@HIDDEN, bug-gnu-emacs@HIDDEN:

Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: monnier@HIDDEN, dgutov@HIDDEN, andreyk.mad@HIDDEN, bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 25 May 2020 17:05:01 +0000
Resent-Message-ID: <handler.41531.B.159042626013324 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 41531 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, andreyk.mad@HIDDEN
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 18:04:02 +0100
Message-ID: <875zckuet9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2a00:1450:4864:20::32c;
 envelope-from=joaotavora@HIDDEN; helo=mail-wm1-x32c.google.com
X-Spam_score_int: -10
X-Spam_score: -1.1
X-Spam_bar: -
X-Spam_report: (-1.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,
 FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001,
 URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN
X-Spam_action: no action
X-Spam-Score: 0.7 (/)
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 (--)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Stefan, Dmitry, Andrii and maintainers,

Moving the discussion that started in
https://github.com/joaotavora/eglot/pull/459 to the bug tracker, and
attaching the two patches that contain what I think is a decent
short-term solution to the eldoc/async problems.

It makes eldoc-diagnostic-functions have a very similar interface to
flymake-diagnostic-functions.  Flymake's handling of the multiple
backends and async is more sophisticated, and we could extend eldoc to
try similarly heroic stuff, if we do find there's a demand for it.

The main thing you probably want to read if
`eldoc-documentation-functions`'s new docstring.

This was tested summarily with Eglot, by the way, and seems to work OK.

Enjoy!
Jo=C3=A3o

PS: How do I mark that the bug report contains a patch in the mail
message itself?


--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
 filename=0001-Better-handle-asynchronously-produced-eldoc-docstrin.patch

From 9ca84e5482b2e7ef40f80679ec508afb008293ae Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 16:39:40 +0100
Subject: [PATCH 1/2] Better handle asynchronously produced eldoc docstrings

No longer do clients of eldoc need to call eldoc-message (an internal
function) directly.  They may return any non-nil, non-string value and
call a callback afterwards.  This enables eldoc.el to exert control
over how (and crucially also when) to display the docstrings to the
user.

* lisp/emacs-lisp/eldoc.el (eldoc-documentation-functions):
Overhaul docstring.
(eldoc-documentation-compose, eldoc-documentation-default): Handle
non-nil, non-string values of elements of
eldoc-documentation-functions.  Use eldoc--handle-multiline.
(eldoc-print-current-symbol-info): Honour non-nil, non-string
values returned by eldoc-documentation-callback.
(eldoc--handle-multiline): New helper.
(Version): Bump to 1.1.0.
---
 lisp/emacs-lisp/eldoc.el | 73 ++++++++++++++++++++++++++++++----------
 1 file changed, 56 insertions(+), 17 deletions(-)

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index ef5dbf8103..f5dcdb4ea0 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -5,7 +5,7 @@
 ;; Author: Noah Friedman <friedman@HIDDEN>
 ;; Keywords: extensions
 ;; Created: 1995-10-06
-;; Version: 1.0.0
+;; Version: 1.1.0
 ;; Package-Requires: ((emacs "26.3"))
 
 ;; This is a GNU ELPA :core package.  Avoid functionality that is not
@@ -338,12 +338,26 @@ eldoc-display-message-no-interference-p
 
 
 (defvar eldoc-documentation-functions nil
-  "Hook for functions to call to return doc string.
-Each function should accept no arguments and return a one-line
-string for displaying doc about a function etc. appropriate to
-the context around point.  It should return nil if there's no doc
-appropriate for the context.  Typically doc is returned if point
-is on a function-like name or in its arg list.
+  "Hook of functions that produce doc strings.
+Each hook function should accept no arguments and decide whether
+to display a doc short string about the context around point.  If
+the decision and the doc string can be produced quickly, the hook
+function should immediately return the doc string, or nil if
+there's no doc appropriate for the context.  Otherwise, if its
+computation is expensive or can't be performed directly, the hook
+function should save the value bound to
+`eldoc-documentation-callback', and arrange for that callback
+function to be asynchronously called at a later time, passing it
+either nil or the desired doc string.  The hook function should
+then return a non-nil, non-string value.
+
+A current limitation of the asynchronous case is that it is only
+guaranteed to work correctly if the value of
+`eldoc-documentation-function' (notice the singular) is
+`eldoc-documentation-default'.
+
+Typically doc is returned if point is on a function-like name or
+in its arg list.
 
 Major modes should modify this hook locally, for example:
   (add-hook \\='eldoc-documentation-functions #\\='foo-mode-eldoc nil t)
@@ -351,14 +365,18 @@ eldoc-documentation-functions
 taken into account if the major mode specific function does not
 return any documentation.")
 
+(defun eldoc--handle-multiline (res)
+  "Helper for handling a bit of `eldoc-echo-area-use-multiline-p'."
+  (if eldoc-echo-area-use-multiline-p res
+    (truncate-string-to-width
+     res (1- (window-width (minibuffer-window))))))
+
 (defun eldoc-documentation-default ()
   "Show first doc string for item at point.
 Default value for `eldoc-documentation-function'."
   (let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
-    (when res
-      (if eldoc-echo-area-use-multiline-p res
-        (truncate-string-to-width
-         res (1- (window-width (minibuffer-window))))))))
+    (cond ((stringp res) (eldoc--handle-multiline res))
+          (t res))))
 
 (defun eldoc-documentation-compose ()
   "Show multiple doc string results at once.
@@ -368,13 +386,11 @@ eldoc-documentation-compose
      'eldoc-documentation-functions
      (lambda (f)
        (let ((str (funcall f)))
-         (when str (push str res))
+         (when (stringp str) (push str res))
          nil)))
     (when res
       (setq res (mapconcat #'identity (nreverse res) ", "))
-      (if eldoc-echo-area-use-multiline-p res
-        (truncate-string-to-width
-         res (1- (window-width (minibuffer-window))))))))
+      (eldoc--handle-multiline res))))
 
 (defcustom eldoc-documentation-function #'eldoc-documentation-default
   "Function to call to return doc string.
@@ -408,6 +424,12 @@ eldoc--supported-p
            ;; there's some eldoc support in the current buffer.
            (local-variable-p 'eldoc-documentation-function))))
 
+;; this variable should be unbound, but that confuses
+;; `describe-symbol' for some reason.
+(defvar eldoc-documentation-callback nil
+  "Dynamically bound.  Accessible to `eldoc-documentation-functions'.
+See that function for details.")
+
 (defun eldoc-print-current-symbol-info ()
   "Print the text produced by `eldoc-documentation-function'."
   ;; This is run from post-command-hook or some idle timer thing,
@@ -417,11 +439,28 @@ eldoc-print-current-symbol-info
         ;; Erase the last message if we won't display a new one.
         (when eldoc-last-message
           (eldoc-message nil))
-      (let ((non-essential t))
+      (let ((non-essential t)
+            (buffer (current-buffer)))
         ;; Only keep looking for the info as long as the user hasn't
         ;; requested our attention.  This also locally disables inhibit-quit.
         (while-no-input
-          (eldoc-message (funcall eldoc-documentation-function)))))))
+          (let*
+              ((waiting-for-callback nil)
+               (eldoc-documentation-callback
+                (lambda (string)
+                  (with-current-buffer buffer
+                    ;; JT@2020-05-25: Currently, we expect one single
+                    ;; docstring from the client, we silently swallow
+                    ;; anything the client unexpectedly gives us,
+                    ;; including updates.  This could change.
+                    (when waiting-for-callback
+                      (eldoc-message (eldoc--handle-multiline string))
+                      (setq waiting-for-callback nil)))))
+               (res
+                (funcall eldoc-documentation-function)))
+            (cond ((stringp res) (eldoc-message res))
+                  (res (setq waiting-for-callback t))
+                  (t (eldoc-message nil)))))))))
 
 ;; If the entire line cannot fit in the echo area, the symbol name may be
 ;; truncated or eliminated entirely from the output to make room for the
-- 
2.20.1


--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
 filename=0002-Adjust-eldoc-documentation-functions-protocol-for-be.patch

From a6ba9972ee0e3305c7b41fd380a88dd18a6626a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 17:38:23 +0100
Subject: [PATCH 2/2] Adjust eldoc-documentation-functions protocol for better
 async

Instead of exposing a eldoc-documentation-callback variable to
clients, just pass it the callback as the first argument.

* lisp/emacs-lisp/eldoc.el (eldoc-documentation-functions): Rewrite docstring.
(eldoc-documentation-default, eldoc-documentation-compose): Use
internal eldoc--callback.
(eldoc-documentation-callback).
(eldoc---callback): Rename from eldoc-documentation-callback.
(eldoc-print-current-symbol-info): Bind eldoc--callback.

* lisp/hexl.el (hexl-print-current-point-info): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/cfengine.el (cfengine3-documentation-function):
Adjust to new eldoc-documentation-functions protocol.

* lisp/progmodes/elisp-mode.el
(elisp-eldoc-documentation-function): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/octave.el (octave-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/python.el (python-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
---
 lisp/emacs-lisp/eldoc.el     | 45 ++++++++++++++++++------------------
 lisp/hexl.el                 |  2 +-
 lisp/progmodes/cfengine.el   |  2 +-
 lisp/progmodes/elisp-mode.el |  6 +++--
 lisp/progmodes/octave.el     |  4 ++--
 lisp/progmodes/python.el     |  2 +-
 6 files changed, 32 insertions(+), 29 deletions(-)

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index f5dcdb4ea0..a4e1e460ac 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -339,22 +339,22 @@ eldoc-display-message-no-interference-p
 
 (defvar eldoc-documentation-functions nil
   "Hook of functions that produce doc strings.
-Each hook function should accept no arguments and decide whether
-to display a doc short string about the context around point.  If
-the decision and the doc string can be produced quickly, the hook
-function should immediately return the doc string, or nil if
-there's no doc appropriate for the context.  Otherwise, if its
-computation is expensive or can't be performed directly, the hook
-function should save the value bound to
-`eldoc-documentation-callback', and arrange for that callback
-function to be asynchronously called at a later time, passing it
-either nil or the desired doc string.  The hook function should
-then return a non-nil, non-string value.
-
-A current limitation of the asynchronous case is that it is only
-guaranteed to work correctly if the value of
-`eldoc-documentation-function' (notice the singular) is
-`eldoc-documentation-default'.
+Each hook function should accept at least one argument CALLBACK
+and decide whether to display a doc short string about the
+context around point.  If the decision and the doc string can be
+produced quickly, the hook function can ignore CALLBACK and
+immediately return the doc string, or nil if there's no doc
+appropriate for the context.  Otherwise, if its computation is
+expensive or can't be performed directly, the hook function
+should arrange for CALLBACK to be asynchronously called at a
+later time, passing it either nil or the desired doc string.  The
+hook function should then return a non-nil, non-string value.
+
+Note that this hook is only in effect if the value of
+`eldoc-documentation-function' (notice the singular) is bound to
+one of its pre-set values.  Furthermore, the asynchronous
+mechanism described above is only guaranteed to work correctly if
+that value is `eldoc-documentation-default'.
 
 Typically doc is returned if point is on a function-like name or
 in its arg list.
@@ -374,7 +374,9 @@ eldoc--handle-multiline
 (defun eldoc-documentation-default ()
   "Show first doc string for item at point.
 Default value for `eldoc-documentation-function'."
-  (let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
+  (let ((res (run-hook-with-args-until-success
+              'eldoc-documentation-functions
+              eldoc--callback)))
     (cond ((stringp res) (eldoc--handle-multiline res))
           (t res))))
 
@@ -385,7 +387,7 @@ eldoc-documentation-compose
     (run-hook-wrapped
      'eldoc-documentation-functions
      (lambda (f)
-       (let ((str (funcall f)))
+       (let ((str (funcall f eldoc--callback)))
          (when (stringp str) (push str res))
          nil)))
     (when res
@@ -426,9 +428,8 @@ eldoc--supported-p
 
 ;; this variable should be unbound, but that confuses
 ;; `describe-symbol' for some reason.
-(defvar eldoc-documentation-callback nil
-  "Dynamically bound.  Accessible to `eldoc-documentation-functions'.
-See that function for details.")
+(defvar eldoc---callback nil
+  "Dynamically bound.  Passed to  `eldoc-documentation-functions'.")
 
 (defun eldoc-print-current-symbol-info ()
   "Print the text produced by `eldoc-documentation-function'."
@@ -446,7 +447,7 @@ eldoc-print-current-symbol-info
         (while-no-input
           (let*
               ((waiting-for-callback nil)
-               (eldoc-documentation-callback
+               (eldoc--callback
                 (lambda (string)
                   (with-current-buffer buffer
                     ;; JT@2020-05-25: Currently, we expect one single
diff --git a/lisp/hexl.el b/lisp/hexl.el
index cf7118f208..38eca77e26 100644
--- a/lisp/hexl.el
+++ b/lisp/hexl.el
@@ -515,7 +515,7 @@ hexl-current-address
       (message "Current address is %d/0x%08x" hexl-address hexl-address))
     hexl-address))
 
-(defun hexl-print-current-point-info ()
+(defun hexl-print-current-point-info (&rest _ignored)
   "Return current hexl-address in string.
 This function is intended to be used as eldoc callback."
   (let ((addr (hexl-current-address)))
diff --git a/lisp/progmodes/cfengine.el b/lisp/progmodes/cfengine.el
index f25b3cb9e2..9a6d81ce06 100644
--- a/lisp/progmodes/cfengine.el
+++ b/lisp/progmodes/cfengine.el
@@ -1294,7 +1294,7 @@ cfengine3-make-syntax-cache
                           'symbols))
         syntax)))
 
-(defun cfengine3-documentation-function ()
+(defun cfengine3-documentation-function (&rest _ignored)
   "Document CFengine 3 functions around point.
 Intended as the value of `eldoc-documentation-function', which see.
 Use it by enabling `eldoc-mode'."
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index d37eb8c152..d7865a7319 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1402,8 +1402,10 @@ elisp--eldoc-last-data
       or argument string for functions.
   2 - `function' if function args, `variable' if variable documentation.")
 
-(defun elisp-eldoc-documentation-function ()
-  "`eldoc-documentation-function' (which see) for Emacs Lisp."
+(defun elisp-eldoc-documentation-function (_ignored &rest _also-ignored)
+  "Contextual documentation function for Emacs Lisp.
+Intended to be placed in `eldoc-documentation-functions' (which
+see)."
   (let ((current-symbol (elisp--current-symbol))
 	(current-fnsym  (elisp--fnsym-in-current-sexp)))
     (cond ((null current-fnsym)
diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index 352c1810d1..2cf305c404 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -1639,8 +1639,8 @@ octave-eldoc-function-signatures
                   (nreverse result)))))
   (cdr octave-eldoc-cache))
 
-(defun octave-eldoc-function ()
-  "A function for `eldoc-documentation-function' (which see)."
+(defun octave-eldoc-function (&rest _ignored)
+  "A function for `eldoc-documentation-functions' (which see)."
   (when (inferior-octave-process-live-p)
     (let* ((ppss (syntax-ppss))
            (paren-pos (cadr ppss))
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 1ca9f01963..404a67ba9f 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -4571,7 +4571,7 @@ python-eldoc-function-timeout-permanent
   :type 'boolean
   :version "25.1")
 
-(defun python-eldoc-function ()
+(defun python-eldoc-function (&rest _ignored)
   "`eldoc-documentation-function' for Python.
 For this to work as best as possible you should call
 `python-shell-send-buffer' from time to time so context in
-- 
2.20.1


--=-=-=--

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#41531: Acknowledgement (27.0.91; Better handle asynchronous
 eldoc backends)
Message-ID: <handler.41531.B.159042626013324.ack <at> debbugs.gnu.org>
References: <875zckuet9.fsf@HIDDEN>
X-Gnu-PR-Message: ack 41531
X-Gnu-PR-Package: emacs
Reply-To: 41531 <at> debbugs.gnu.org
Date: Mon, 25 May 2020 17:05:01 +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.

As you requested using X-Debbugs-CC, your message was also forwarded to
  Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN=
>, andreyk.mad@HIDDEN
(after having been given a bug report number, if it did not have one).

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 41531 <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
41531: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 25 May 2020 23:54:01 +0000
Resent-Message-ID: <handler.41531.B41531.159045080127761 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, 41531 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
References: <875zckuet9.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
Date: Tue, 26 May 2020 02:52:58 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <875zckuet9.fsf@HIDDEN>
Content-Type: multipart/mixed; boundary="------------F14F2C2007861A590D9DCEA9"
Content-Language: en-US
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

This is a multi-part message in MIME format.
--------------F14F2C2007861A590D9DCEA9
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 25.05.2020 20:04, João Távora wrote:
> Hi Stefan, Dmitry, Andrii and maintainers,
> 
> Moving the discussion that started in
> https://github.com/joaotavora/eglot/pull/459  to the bug tracker, and
> attaching the two patches that contain what I think is a decent
> short-term solution to the eldoc/async problems.

Here's a modified approach that doesn't use a global var and should make 
it easier to transition to using futures.

Patch attached. Example of usage:

(add-hook 'eldoc-documentation-functions
           #'test-eldoc-async 0 t)

(defun test-eldoc-async ()
   (cons :async
         (lambda (cb)
           (funcall cb "doc here!"))))

If you like, we could simplify the returned objects to be just FETCHER 
(as documented in the patch) rather than (:async . FETCHER). But the 
latter seems more explicit.

There also exist a possible modification of this patch with a bit of 
functional programming where both calls to eldoc--handle-multiline 
happen from inside of eldoc-documentation-default's definition.

--------------F14F2C2007861A590D9DCEA9
Content-Type: text/x-patch; charset=UTF-8;
 name="eldoc-async-with-lexical-callback.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="eldoc-async-with-lexical-callback.diff"

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index ef5dbf8103..8909e8d431 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -5,7 +5,7 @@
 ;; Author: Noah Friedman <friedman@HIDDEN>
 ;; Keywords: extensions
 ;; Created: 1995-10-06
-;; Version: 1.0.0
+;; Version: 1.1.0
 ;; Package-Requires: ((emacs "26.3"))
 
 ;; This is a GNU ELPA :core package.  Avoid functionality that is not
@@ -338,12 +338,26 @@ eldoc-display-message-no-interference-p
 
 
 (defvar eldoc-documentation-functions nil
-  "Hook for functions to call to return doc string.
-Each function should accept no arguments and return a one-line
-string for displaying doc about a function etc. appropriate to
-the context around point.  It should return nil if there's no doc
-appropriate for the context.  Typically doc is returned if point
-is on a function-like name or in its arg list.
+  "Hook of functions that produce doc strings.
+Each hook function should accept no arguments and decide whether
+to display a doc short string about the context around point.
+
+Typically doc is returned if point is on a function-like name or
+in its arg list.
+
+If the decision and the doc string can be produced quickly, the
+hook function should immediately return the doc string, or nil if
+there's no doc appropriate for the context.  Otherwise, if its
+computation is expensive or can't be performed directly, the
+function can instead return a cons (:async . FETCHER) where where
+FETCHER is a function of one argument, CALLBACK.  When the result
+arrives, FETCHER must call CALLBACK and pass it the doc string to
+be displayed.
+
+A current limitation of the asynchronous case is that it is only
+guaranteed to work correctly if the value of
+`eldoc-documentation-function' (notice the singular) is
+`eldoc-documentation-default'.
 
 Major modes should modify this hook locally, for example:
   (add-hook \\='eldoc-documentation-functions #\\='foo-mode-eldoc nil t)
@@ -351,14 +365,18 @@ eldoc-documentation-functions
 taken into account if the major mode specific function does not
 return any documentation.")
 
+(defun eldoc--handle-multiline (res)
+  "Helper for handling a bit of `eldoc-echo-area-use-multiline-p'."
+  (if eldoc-echo-area-use-multiline-p res
+    (truncate-string-to-width
+     res (1- (window-width (minibuffer-window))))))
+
 (defun eldoc-documentation-default ()
   "Show first doc string for item at point.
 Default value for `eldoc-documentation-function'."
   (let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
-    (when res
-      (if eldoc-echo-area-use-multiline-p res
-        (truncate-string-to-width
-         res (1- (window-width (minibuffer-window))))))))
+    (cond ((stringp res) (eldoc--handle-multiline res))
+          (t res))))
 
 (defun eldoc-documentation-compose ()
   "Show multiple doc string results at once.
@@ -368,13 +386,11 @@ eldoc-documentation-compose
      'eldoc-documentation-functions
      (lambda (f)
        (let ((str (funcall f)))
-         (when str (push str res))
+         (when (stringp str) (push str res))
          nil)))
     (when res
       (setq res (mapconcat #'identity (nreverse res) ", "))
-      (if eldoc-echo-area-use-multiline-p res
-        (truncate-string-to-width
-         res (1- (window-width (minibuffer-window))))))))
+      (eldoc--handle-multiline res))))
 
 (defcustom eldoc-documentation-function #'eldoc-documentation-default
   "Function to call to return doc string.
@@ -417,11 +433,30 @@ eldoc-print-current-symbol-info
         ;; Erase the last message if we won't display a new one.
         (when eldoc-last-message
           (eldoc-message nil))
-      (let ((non-essential t))
+      (let ((non-essential t)
+            (buffer (current-buffer)))
         ;; Only keep looking for the info as long as the user hasn't
         ;; requested our attention.  This also locally disables inhibit-quit.
         (while-no-input
-          (eldoc-message (funcall eldoc-documentation-function)))))))
+          (let*
+              ((waiting-for-callback t)
+               (callback
+                (lambda (string)
+                  (with-current-buffer buffer
+                    ;; JT@2020-05-25: Currently, we expect one single
+                    ;; docstring from the client, we silently swallow
+                    ;; anything the client unexpectedly gives us,
+                    ;; including updates.  This could change.
+                    (when waiting-for-callback
+                      (setq waiting-for-callback nil)
+                      (eldoc-message (eldoc--handle-multiline string))))))
+               (res
+                (funcall eldoc-documentation-function)))
+            (cond ((stringp res) (eldoc-message res))
+                  ((and (consp res)
+                        (eq (car res) :async))
+                   (funcall (cdr res) callback))
+                  (t (eldoc-message nil)))))))))
 
 ;; If the entire line cannot fit in the echo area, the symbol name may be
 ;; truncated or eliminated entirely from the output to make room for the

--------------F14F2C2007861A590D9DCEA9--

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 01:22:02 +0000
Resent-Message-ID: <handler.41531.B41531.15904560863213 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
Date: Tue, 26 May 2020 02:21:14 +0100
In-Reply-To: <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> (Dmitry Gutov's
 message of "Tue, 26 May 2020 02:52:58 +0300")
Message-ID: <87k10zsd85.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (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>

Dmitry Gutov <dgutov@HIDDEN> writes:

> On 25.05.2020 20:04, Jo=C3=A3o T=C3=A1vora wrote:
> (add-hook 'eldoc-documentation-functions
>           #'test-eldoc-async 0 t)
>
> (defun test-eldoc-async ()
>   (cons :async
>         (lambda (cb)
>           (funcall cb "doc here!"))))

Thanks.  As I told you, it's not bad.  These aren't exactly "futures"
though, they're a way to simulate argument passing.  I prefer my
version, which matches what flymake.el, url.el, jsonrpc.el, sly.el and
others do.

> If you like, we could simplify the returned objects to be just FETCHER
> (as documented in the patch) rather than (:async . FETCHER). But the=20
> latter seems more explicit.

Yes, if we do go with your version, I'd like that.  The latter is hard
to read and understand from the docstring.

Before I go any further I'd like Stefan and Andrey (or others) to weigh
in.  I don't have a lot of time to invest here, so if there is another
vote for your proposal, I'm not going to wrestle here.

To simplify, hopefully you agree that your proposal can be summarized
as:

  "return a function that receives a function that you
   should call with the docstring"

whereas my proposal can be summarized as:

  "receive a function that you should call with the docstring"

> There also exist a possible modification of this patch with a bit of
> functional programming where both calls to eldoc--handle-multiline=20
> happen from inside of eldoc-documentation-default's definition.

Yes, that's independent of the shape of the callback we want to use.
I'll leave that for later.  Specifically, eldoc--handle-multiline has to
do quite a bit more handling (to satisfy Andrey's expectations).

Replying to parts from the other discussion in the Github tracker now.

> OK, another question: if the result still /valid/?
                        ^^ Assuming you mean "is".

Well, if the client discovers the result to be invalid, it can not call
the callback, or signal an error.  If it is valid, call the callback.

> No idea, a hypothetical one. It's an open API, not everybody is or
> will be using LSP until the end of time. And it doesn't really have to
> be huge. A saving is a saving.

There's no free lunch.  A very small saving in time for more complexity
is bad.  That's what overengineered means.

> You can certainly kill the external process outside of it. Saving on
> CPU expenses in general.

The future's creditor is the only one who could do that to any useful
effect.  Does it have access to the process?  Probably not.  You would
have to return a complex future with a kill switch.  That's possible,
but tricky, because you'd then have to be ready in the sentinel for
another source of unexpected kills.

> > For a poor man's async primitive, I prefer my version

> So even the code savings didn't convince you? Both in eldoc.el,

I do see minimal code savings in eldoc.  You do remove a special
variable (which is _not_ the same as a global variable, btw).

I do see a much more complicated docstring, where the reader has to wrap
his head around a 2-deep functional conundrum, whereas my version was
1-deep.  Nothing special, but a VERY common source of headaches.

Let's take your trivial example:

    (defun test-eldoc-async ()
       (cons :async
            (lambda (cb)
               (funcall cb "doc here!"))))

It isn't really representative of what a function that needs async would
have to do, is it?  Because, if you really wanted this very example,
then it's much better to do the one-liner:

   (defun test-eldoc-async () "doc here!")

Rather, presumably you would use this to fetch something from an HTTP
server or so:

    (defun test-eldoc-async ()
      (cons :async
        (lambda (cb)
           (url-retrieve-thingy "http://test-signature" cb))))

Where url-retrieve-thingy is very similar to our url-retrieve. Right?
But why have that awkward :async there when a function is a first class
object that we can identify with the functionp predicate?  Let's just:

    (defun test-eldoc-async ()
       (lambda (cb)
          (url-retrieve-thingy "http://test-signature" cb)))

And at this point one wonders why the heck not

  (defun test-eldoc-async (cb)
     (url-retrieve-thingy "http://test-signature" cb))

?

> and likely in doc functions as well

No.  Unless I am completely mistaken (I might be), in the "doc function"
not only are there no savings, but complication.  This makes sense
because you just inverted the responsibility: the doc function now has
to "beg" for the argument that used to be given to it naturally.

So, it's just a functional gimmick.  As good as the next one, but a
gimmick all the same.  Until the "futures" are here, people will
potentially bang heads in an anguished "WHY??".

Why indeed?  Your other argument, that this makes the transition to
proper futures (such as the ones in https://github.com/skeeto/emacs-aio)
easier, is questionable, too.  There are two scenarios here:

- You want to keep backward compatibility to this API published in eldoc
  1.1.0 until the time of the Emacs 28 release:

  This is something that I -- and Stefan, if I'm not mistaken, -- don't
  think we should worry about.  Just because a package is :core GNU ELPA
  doesn't necessarily mean we guarantee stability of its API.

  But if we do, then we'll have to explain in the docstring that there
  is a fourth return value for the hook functions.  In my version we'll
  have to do exactly the same.

- You don't want to keep backward compatibility until Emacs 28:

  Then, when the super-futures are here, you can just kill the CALLBACK
  arg if we find it doesn't fit and rewrite the docstring without
  concerns.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 May 2020 02:39:01 +0000
Resent-Message-ID: <handler.41531.B41531.159046072511029 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159046072511029
          (code B ref 41531); Tue, 26 May 2020 02:39:01 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 02:38:45 +0000
Received: from localhost ([127.0.0.1]:43139 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdPUK-0002ro-Ox
	for submit <at> debbugs.gnu.org; Mon, 25 May 2020 22:38:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19369)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jdPUJ-0002ra-Jj
 for 41531 <at> debbugs.gnu.org; Mon, 25 May 2020 22:38:43 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id C34D8440900;
 Mon, 25 May 2020 22:38:37 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 93FB0440489;
 Mon, 25 May 2020 22:38:36 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1590460716;
 bh=BX5kSxsHSUDGHi8VaPxEXa6QVuTt7cLS7ESsnxnYATo=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=oFkQxzIusNZmJpKE7H9ODqM/sNwzGDCifg53gTgd/rA8tmQQW64Ay5zktDey+BBJy
 MnuX7npY9+3ImI1HmFVLbDk+VztVps5IQDMDHIf+KJrguQTSXKAFe3XGTGpwWvrd5H
 jbtAB/vb/z3wE4wLgNuRtP0BiIAijucbhVVUTVD+yKQnPJ2elxzhRtU8aIySS8Y3sq
 9j4ipj/RByCXCKzsbzO+WGqcniRKgmRN2k8TH+95E97oW3itUSTnK+iYWtHJSybj3d
 DeNoij2sc4oXaeq/1QhNR0vylMnXu4z0v3Uxef0CX1ub/770iO6aVAhs4kANdJmhpX
 2J97uBYOxP7Xg==
Received: from milanesa (unknown [216.154.27.250])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4FA73120281;
 Mon, 25 May 2020 22:38:36 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwv367nqv52.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
Date: Mon, 25 May 2020 22:38:35 -0400
In-Reply-To: <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> (Dmitry Gutov's
 message of "Tue, 26 May 2020 02:52:58 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.098 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

> Here's a modified approach that doesn't use a global var and should make it
> easier to transition to using futures.

I think at this stage, we should either start using futures or we should
forget about ever using them.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 11:24:01 +0000
Resent-Message-ID: <handler.41531.B41531.159049218712905 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159049218712905
          (code B ref 41531); Tue, 26 May 2020 11:24:01 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 11:23:07 +0000
Received: from localhost ([127.0.0.1]:44262 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdXfn-0003M5-9w
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 07:23:07 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:54047)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jdXfl-0003LH-8S
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 07:23:05 -0400
Received: by mail-wm1-f45.google.com with SMTP id l26so2758938wme.3
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 04:23:05 -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=W3TMvTnBp0vPiqvcpfuun0JUeRi3RYi9OL1IR0CHXb8=;
 b=K0O0XnoJlcrVlqoRij2a8WTqMntphDVW3Boz/RknHOfBMTeLEBAFNPTsHTbHnV6sNo
 FflhtUdhOQb5U1ePfrY/NogWS1yn0iJqnJRA0enXg61GjK50cqAioZfL2z3vnN5iH6SP
 ehr+IV7FgWhKMxOOz9axg//33P5pOn9smViBI0EPfSI3zsZEBUpN18rF15HkGQcn1mMQ
 j/2ENk1qbkqOthjuKDJKf3cxLyYSy8EZnIsxXodIrkSRlCKta8FrPX8X8fht8UTUg5UZ
 bq+lQ7gfqaxpVHTQcLnpWJnv78tQ57hvkw3dAGSCcupnNgtZOsYJFi3cAPxp0WUJermC
 f3aQ==
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=W3TMvTnBp0vPiqvcpfuun0JUeRi3RYi9OL1IR0CHXb8=;
 b=gX19a5onF/eokUWP1wCxxnl1TFlv+aOT1g2mLWBxnhv4c5waKy6tpOqJXTXzkAYAu9
 Y7uLc2ziwOJWUGE0lllmgDGUEtNyT2/zmvHHer22fDH6lq86uubxS8Q2wPTRhGHgGdqM
 wEExJKuk8p75qVxcZ8gsExalRQ3hmKVmT8X5JXF7mpxOAaFnhEBo5ctk2lhTt6o2CGyT
 z5C6vx7Btgwgs0ozSse5Acf8kLNnnpI4FP1KhazoP/TTKjvX9BjmJGS6OdwlqjVwBE9I
 qZNq0b8nNl2yHFPMjpm/HQZ4Ts0RJkvxhLyfdjzmUnWzmZGeHQOgSgASWjv3sjHgQX29
 yTMw==
X-Gm-Message-State: AOAM532VOoezfOIREq/DX7dN28QvvBT64swietcJWTltuNKJW77RuIWS
 zZGHkUvCXZoDzNBs/ueKlXU=
X-Google-Smtp-Source: ABdhPJxTy1pS6oOUB7AJ0LADaW0AA9nzEtdGo5o95ELPvvMNWMdz1vuYO3DjtTw18dFx7anYJo62zQ==
X-Received: by 2002:a1c:117:: with SMTP id 23mr1027711wmb.90.1590492179406;
 Tue, 26 May 2020 04:22:59 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id r4sm844621wro.32.2020.05.26.04.22.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 May 2020 04:22:58 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN>
Date: Tue, 26 May 2020 12:22:57 +0100
In-Reply-To: <jwv367nqv52.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Mon, 25 May 2020 22:38:35 -0400")
Message-ID: <87blmbrlda.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (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 (-)

Stefan Monnier <monnier@HIDDEN> writes:

>> Here's a modified approach that doesn't use a global var and should make=
 it
>> easier to transition to using futures.
> I think at this stage, we should either start using futures or we should
> forget about ever using them.

<DRAMATIC MUSIC PLAYS>

But really: now we have deadlock too?  I just want to solve this
problem: please let's commit something, and move on to the next bug.  It
can be functions that return functions that receive functions with the
airplane.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 13:33:01 +0000
Resent-Message-ID: <handler.41531.B41531.1590499959600 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.1590499959600
          (code B ref 41531); Tue, 26 May 2020 13:33:01 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 13:32:39 +0000
Received: from localhost ([127.0.0.1]:44421 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdZh8-00009c-UJ
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 09:32:39 -0400
Received: from mail-wr1-f41.google.com ([209.85.221.41]:32938)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jdZh7-00009P-ES
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 09:32:38 -0400
Received: by mail-wr1-f41.google.com with SMTP id l11so20467610wru.0
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 06:32:37 -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=UPfhAfS7kdMLfVcbyYc8ssasrrGiELu2mWteZ5nypYw=;
 b=dylSPGqLbiLLYfxtzap47N3AlNih4VLBwO+MJ/TGt/IXmP8l1FUdjy9odAgjYiMTck
 cs1i++dgvAbGBz/3yllXRgvbpRxvy9Bl9pzmQqz6b8Ngk6dFFHaASw2EKApV+eU5pzJQ
 hgZKoniCNTabsjcPVlRj5DMMEg7qKLtJOXERE0KqKlHUT2hU8fIcaqJPwZ6rJFVt6JE1
 GJvnyW8AEwr2Qhad5ATda390d0gkm0b43wt5gKgr7+4d5MmpI4hEWq/fEjO8GJ6QWBDi
 Hk06xV7jOMcGE5l1c4GkR6ly8Z5w40mfMM2qB0iVTNy2eGHABNNDVRHoq/m2ykllucFj
 3xkQ==
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=UPfhAfS7kdMLfVcbyYc8ssasrrGiELu2mWteZ5nypYw=;
 b=jywV/1+TmfoukT5S8RHffrsdSUwMgF35C9LsB1RTEXPBB5Et9KQlfHoMt898f/6cXQ
 Dt8j35QxbfTUpmk62Cep/vnx2PjZqOUYEa1MalDrrSCqwUQbwNvjoqrW5m/E9/Fu3t+D
 AjaEYKTlmTf5FKFNR+FQPq5AGOYH9a2ZlbN6wpVNOxKsOWW88/s6PWVAF6+3FDnRziT8
 Audt7U2Kx2uB5Kbxc/HTbF04qKLWXfyv7JxR8+BopKD1APijaMQ3fyDUfcc1O8gednmL
 Y0thqV/y7AS/2jqdopt0dR7ww5fljA9AzoGK+sWxsiThYFd84xxispHUNrdzT0QktYol
 JNCg==
X-Gm-Message-State: AOAM531bAjpBdiEIOkartLYOrqabP7Le23VOX51L/vdfWbxadrYw5yy3
 J0mcejnTtjzQyF6j4pinb/k=
X-Google-Smtp-Source: ABdhPJygi00v1iVC99ZGPNnX2w9RzJgklkRhUPFSomEFslqJiemHyn6PL+dZIhA1sa+lDbISTVNX8A==
X-Received: by 2002:adf:9545:: with SMTP id 63mr18545049wrs.303.1590499951479; 
 Tue, 26 May 2020 06:32:31 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id a14sm3037074wrv.20.2020.05.26.06.32.29
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 May 2020 06:32:30 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <563f298a-a0cb-044d-2619-068e8d30f119@HIDDEN>
Date: Tue, 26 May 2020 16:32:28 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <jwv367nqv52.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
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: -0.5 (/)

On 26.05.2020 05:38, Stefan Monnier wrote:
>> Here's a modified approach that doesn't use a global var and should make it
>> easier to transition to using futures.
> 
> I think at this stage, we should either start using futures or we should
> forget about ever using them.

We should certainly do it before Emacs 28 is released (so we won't have 
to support whatever ad-hoc option is currently being proposed).

I just don't have the time to work on futures right now. If this bug can 
wait until this weekend, at least, we can reconvene after.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 13:58:02 +0000
Resent-Message-ID: <handler.41531.B41531.15905014444333 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15905014444333
          (code B ref 41531); Tue, 26 May 2020 13:58:02 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 13:57:24 +0000
Received: from localhost ([127.0.0.1]:46014 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jda55-00017p-FU
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 09:57:23 -0400
Received: from mail-wr1-f42.google.com ([209.85.221.42]:37588)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jda53-00017a-98
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 09:57:22 -0400
Received: by mail-wr1-f42.google.com with SMTP id x13so5845015wrv.4
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 06:57:21 -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=EybqiaDOwRdFbRmxeL7fOULWe099yWtPh4HpMgOSU5s=;
 b=Jv/7hSkBiji4dtzzBpsFfglD+CE9nLg36c8rbvZurcVHSvJ/Ff7NdnAkcU/dae5Zy8
 jkYOhlpHbuenwK5Mp7C+/Y3Xoj7/dhrH/q8q4PzKQ617tI9wsYEY9m4CgytZCjTzJ7SO
 93LDj6d0ZT3BVc75TuheH+gA0RPm6Mu/DXB9/H0CRC5piitfsl1Ym//moZNOWSzB1r2j
 eefGK88+hjqp++87fuNOoCkcfaGQadFVTiwqW/Bvl8oEeQBGP0qaWME707F7gdfUWQ45
 J6MRJNMTn5q1AkB8DQTsPJbtMwNBKjkYX2fCm+V9QD41424smvU7pENB4xoLBGPZtzrf
 FCsQ==
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=EybqiaDOwRdFbRmxeL7fOULWe099yWtPh4HpMgOSU5s=;
 b=N8U7zz8gxXvZ1FwRuRsg9NB5Mipk8Y5VoZOq3+jPV8Xk3RdLXwqdaU3LZJEsKsWjDY
 3BS+nWRRWlclGSin/ala9bEAlHU0Pqivqon2kzr9yOQUny66lFsIXWeQjJ8HgzRJfCr9
 4bXwO3JCFrizerqKxZ+F8adjW804zl/rpqFELLjLR7YCy5zXwRK03SXxxxsdj7xDHikF
 2+NE7EwIwB0E0ErWm76xo15LprWPJzOY5NnkEo4BejMj9fMKz7pYYy9deTpMqD+CUZcT
 oXB34cEA8Xv6/ZpP8fQgS0pyh/WAdEVKwb2lLGO/MVvRV2kcISV4NknC0lSef/uhh7oj
 oYsQ==
X-Gm-Message-State: AOAM53012N/1OLkz+e2vAC3cEzMxK6/qgZmfMS/q3YjVTVGVS5Ei73+J
 itFjafl0iSEj1pnMX2Hn520=
X-Google-Smtp-Source: ABdhPJxhtJ1qsbGvCEuos2NEsO/bHWQOzPNs0rpPF9EUEoQ7KvniqrzaVFm9iUTt6RrprvSU9Cadbg==
X-Received: by 2002:a05:6000:11ca:: with SMTP id
 i10mr20825580wrx.10.1590501435159; 
 Tue, 26 May 2020 06:57:15 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id o20sm9571670wra.29.2020.05.26.06.57.13
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 May 2020 06:57:14 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN>
Date: Tue, 26 May 2020 16:57:13 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <87k10zsd85.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
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: -0.5 (/)

On 26.05.2020 04:21, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>> On 25.05.2020 20:04, João Távora wrote:
>> (add-hook 'eldoc-documentation-functions
>>            #'test-eldoc-async 0 t)
>>
>> (defun test-eldoc-async ()
>>    (cons :async
>>          (lambda (cb)
>>            (funcall cb "doc here!"))))
> 
> Thanks.  As I told you, it's not bad.  These aren't exactly "futures"
> though, they're a way to simulate argument passing.

It's a simple stand-in, easy to replace.

> I prefer my
> version, which matches what flymake.el, url.el, jsonrpc.el, sly.el and
> others do.

They also use *special* variables? Flymake's API looks fairly clean (you 
call back to REPORTER-FN, that's very reasonable), but I haven't looked 
under the covers yet.

>> If you like, we could simplify the returned objects to be just FETCHER
>> (as documented in the patch) rather than (:async . FETCHER). But the
>> latter seems more explicit.
> 
> Yes, if we do go with your version, I'd like that.  The latter is hard
> to read and understand from the docstring.

I think it's more explicit, and once you understand it, it clicks. But 
that choice is not important to me.

> To simplify, hopefully you agree that your proposal can be summarized
> as:
> 
>    "return a function that receives a function that you
>     should call with the docstring"
> 
> whereas my proposal can be summarized as:
> 
>    "receive a function that you should call with the docstring"

To clarify, you actually included two proposals (behavior with patch 1, 
and with both patch 1 and patch 2 applied). The first one is the one I 
really didn't like. The second one is better, API-wise, but will 
conflict with the futures-based approach.

>> There also exist a possible modification of this patch with a bit of
>> functional programming where both calls to eldoc--handle-multiline
>> happen from inside of eldoc-documentation-default's definition.
> 
> Yes, that's independent of the shape of the callback we want to use.
> I'll leave that for later.  Specifically, eldoc--handle-multiline has to
> do quite a bit more handling (to satisfy Andrey's expectations).

I'm not so such it's independent. The complexity of implementing that 
would certainly vary.

BTW, maybe eldoc-message should handle this after all? Since it's the 
last link in the chain. Or even do that in the default value of 
eldoc-message-function (create a wrapper for minibuffer-message).

> Replying to parts from the other discussion in the Github tracker now.
> 
>> OK, another question: if the result still /valid/?
>                          ^^ Assuming you mean "is".
> 
> Well, if the client discovers the result to be invalid, ...

So the client will have to save and then compare the current buffer, the 
value of point and buffer-chars-modification-tick now?

>> No idea, a hypothetical one. It's an open API, not everybody is or
>> will be using LSP until the end of time. And it doesn't really have to
>> be huge. A saving is a saving.
> 
> There's no free lunch.  A very small saving in time for more complexity
> is bad.  That's what overengineered means.

Futures are not particularly more complex to use.

>> You can certainly kill the external process outside of it. Saving on
>> CPU expenses in general.
> 
> The future's creditor is the only one who could do that to any useful
> effect.  Does it have access to the process?  Probably not.

It can (barring any complex abstractions). It created the process, after 
all.

> You would
> have to return a complex future with a kill switch.  That's possible,
> but tricky, because you'd then have to be ready in the sentinel for
> another source of unexpected kills.

That would be none of ElDoc's business, though. But the implementation 
will get to be as complex as it needs.

> Why indeed?  Your other argument, that this makes the transition to
> proper futures (such as the ones in https://github.com/skeeto/emacs-aio)
> easier, is questionable, too.  There are two scenarios here:
> 
> - You want to keep backward compatibility to this API published in eldoc
>    1.1.0 until the time of the Emacs 28 release:

The one thing I want to avoid doing is changing the callsig of every 
documentation function, and then changing them back when we switch to 
futures.

>    This is something that I -- and Stefan, if I'm not mistaken, -- don't
>    think we should worry about.  Just because a package is :core GNU ELPA
>    doesn't necessarily mean we guarantee stability of its API.

Um, I'm pretty sure we guarantee a fair amount of stability.

>    But if we do, then we'll have to explain in the docstring that there
>    is a fourth return value for the hook functions.  In my version we'll
>    have to do exactly the same.
> 
> - You don't want to keep backward compatibility until Emacs 28:
> 
>    Then, when the super-futures are here, you can just kill the CALLBACK
>    arg if we find it doesn't fit and rewrite the docstring without
>    concerns.

Kill the arg in all built-in functions, as well as in external consumers?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 May 2020 14:54:02 +0000
Resent-Message-ID: <handler.41531.B41531.15905048299521 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15905048299521
          (code B ref 41531); Tue, 26 May 2020 14:54:02 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 14:53:49 +0000
Received: from localhost ([127.0.0.1]:46070 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdaxh-0002TV-5i
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 10:53:49 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:39073)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jdaxg-0002TJ-EM
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 10:53:48 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E44641008C8;
 Tue, 26 May 2020 10:53:42 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5DB34100419;
 Tue, 26 May 2020 10:53:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1590504821;
 bh=yVMSWbimjhFivPQURnXogzG4H4cbhGPSW34L9PqFU6E=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=CKsf0RELl1wEHYov0YeqOL5R2QPZFWJHgdqbe2mEBqPFTG4TdO66sfzfUjpnlf7pS
 W9Yvt8m7Q3h/KARDxjuJPr5aOoDLPLThWyvMbyty2TAT8hj07Nn2ic19ZNzwjkKOBd
 rpOEPi1cjZ15YZ5rTe6SRCLIVjfOIT/38yFSt8ZFjbJ7cqhczeI5X0g/lhQviAqULw
 EqdO4F8nJS3BxctK5GaedvLX24PifWUTwy7pOA3kTAUpzfjv6ik69wtxlzw8dPfSzt
 pxgtx+bSnbKZdPDQ2Mku/n/ZiZoAjVNMhgBarFSpebcDXK+2NGhvRXRDhdLP0x0Y2a
 6jVSZSJWaBKYg==
Received: from milanesa (unknown [216.154.27.250])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E46401204BD;
 Tue, 26 May 2020 10:53:40 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
Date: Tue, 26 May 2020 10:53:38 -0400
In-Reply-To: <87blmbrlda.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 26
 May 2020 12:22:57 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.088 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

> But really: now we have deadlock too?  I just want to solve this
> problem: please let's commit something, and move on to the next bug.

Can you use the sample `eldoc-future-*` code I sent earlier?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 15:21:01 +0000
Resent-Message-ID: <handler.41531.B41531.159050642512018 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159050642512018
          (code B ref 41531); Tue, 26 May 2020 15:21:01 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 15:20:25 +0000
Received: from localhost ([127.0.0.1]:46112 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdbNC-000372-9u
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 11:20:25 -0400
Received: from mail-wr1-f54.google.com ([209.85.221.54]:46551)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jdbN9-00036E-2f
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 11:20:09 -0400
Received: by mail-wr1-f54.google.com with SMTP id x6so7160918wrm.13
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 08:20:07 -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;
 bh=g2a6+wAc582ZwT22C/XySWFfWQZiYYypJZAtnJ6rs3w=;
 b=BlXhZx5gWj3DdIi5TMSH3h3WTOn0JVmRz4rmySZpD2GsY1SMohDYsz2ACRsZoyzdil
 +GMOWs5/sdmGE9PzJe9hYXPXAcY7lii2HWI54RloMgzgLpxZPFBlWE1FmzPYcvrYPPTg
 HZ00De0LKK0vNG4Dr1ZNBpyY9S5MUAIFeqirQrosfha9hxpNPhTesDHlOJrUykh9dmPP
 GVFyYDwZIJvnGAYOuWkW7kKttaeQYhsVVodjw/bx1GU8S3URsVSfjUwLh1lBAMzP/ris
 xH+5OYcwGVxKKnmtYXMQxed5oVglldpwHIKEu4S0NBx+RieUozCIT5xrAXf4PfYVHzV+
 kTUw==
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;
 bh=g2a6+wAc582ZwT22C/XySWFfWQZiYYypJZAtnJ6rs3w=;
 b=P0SPDiN4F4koodadboMzAlt9r4zle9dY3I67/GAmozCg7DkdtBu4tPejsjSb4I9VOd
 8WFymY8inPGeUQjBzKlL6/Fhj2U8u2XIas4y1CVAkmapigns+Z/TMmE0M7rRtC4z5Hvn
 DsCxdGoeAYk7medG2YZnlbGyT74nH25ns9CxeSA2L4LOwSooLQaMDxPz4cCPX+mIMkFj
 PtukhNbUVM8kFwASt1i45FGKmMsWwAn5DcaENX37OaaWsaWAMI71t+X9DN1A2/SbT4vV
 IabwWxIepMAunjcjY83cWtLksJEskdBnsZa9lE3h+AznjUsxpzjqaIWi5cwRzBbHyprw
 4A1A==
X-Gm-Message-State: AOAM532lJDFL/LINs+8g5V5hLHK/LaLBdLpnqg3LeNa3FB6hmiJV1J+J
 ch9vt7VhZKjDGQXD/YF0fBI=
X-Google-Smtp-Source: ABdhPJzUKF/j7Cz0Sfpe4V0NSE0JGpq2wrin2k/8K7DHBLdquQQPUhTv84F6JQ2azxn4kNZuinir9g==
X-Received: by 2002:adf:e5c8:: with SMTP id a8mr19575622wrn.335.1590506401280; 
 Tue, 26 May 2020 08:20:01 -0700 (PDT)
Received: from krug ([89.180.149.243])
 by smtp.gmail.com with ESMTPSA id k13sm20992843wmj.40.2020.05.26.08.19.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 May 2020 08:20:00 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN>
Date: Tue, 26 May 2020 16:19:58 +0100
In-Reply-To: <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Tue, 26 May 2020 10:53:38 -0400")
Message-ID: <87pnaqrae9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
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 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Stefan Monnier <monnier@HIDDEN> writes:

>> But really: now we have deadlock too?  I just want to solve this
>> problem: please let's commit something, and move on to the next bug.
>
> Can you use the sample `eldoc-future-*` code I sent earlier?
>
>         Stefan

It's not complete, is it?  And how to I use it to solve the
eldoc-documentation-compose problem?  I suppose it's possible, anything
is.  But do we really want to hand-roll futures in eldoc.el when we got
this nice https://github.com/skeeto/emacs-aio/commits/master that we
could be looking into?

Also the latest patch I attach solves the eldoc-documentation-compose
problem decently (should actually be less LOC than previous versions).
I suggest we go with this tried-and-tested well-understood solution and
then adjust as more sophisticated solutions come along and we evaluate
their merits.

Jo=C3=A3o


--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=0001-eldoc-async-v3.patch

From 0227a048cc7f88c5e4d773eac2ec8366056f3a6b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 16:39:40 +0100
Subject: [PATCH] Better handle asynchronously produced eldoc docstrings

No longer do clients of eldoc need to call eldoc-message (an internal
function) directly.  They may return any non-nil, non-string value and
call a callback afterwards.  This enables eldoc.el to exert control
over how (and crucially also when) to display the docstrings to the
user.

* lisp/emacs-lisp/eldoc.el (eldoc-documentation-functions):
Overhaul docstring.
(eldoc-documentation-compose, eldoc-documentation-default): Handle
non-nil, non-string values of elements of
eldoc-documentation-functions.
(eldoc-print-current-symbol-info): Redesign.
(eldoc--handle-multiline): New helper.
(eldoc--callback): New internal special var.
(Version): Bump to 1.1.0.

* lisp/hexl.el (hexl-print-current-point-info): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/cfengine.el (cfengine3-documentation-function):
Adjust to new eldoc-documentation-functions protocol.

* lisp/progmodes/elisp-mode.el
(elisp-eldoc-documentation-function): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/octave.el (octave-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/python.el (python-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
---
 lisp/emacs-lisp/eldoc.el     | 101 ++++++++++++++++++++++++++---------
 lisp/hexl.el                 |   2 +-
 lisp/progmodes/cfengine.el   |   2 +-
 lisp/progmodes/elisp-mode.el |   6 ++-
 lisp/progmodes/octave.el     |   4 +-
 lisp/progmodes/python.el     |   2 +-
 6 files changed, 84 insertions(+), 33 deletions(-)

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index ef5dbf8103..dcd28fb082 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -5,7 +5,7 @@
 ;; Author: Noah Friedman <friedman@HIDDEN>
 ;; Keywords: extensions
 ;; Created: 1995-10-06
-;; Version: 1.0.0
+;; Version: 1.1.0
 ;; Package-Requires: ((emacs "26.3"))
 
 ;; This is a GNU ELPA :core package.  Avoid functionality that is not
@@ -338,12 +338,24 @@ eldoc-display-message-no-interference-p
 
 
 (defvar eldoc-documentation-functions nil
-  "Hook for functions to call to return doc string.
-Each function should accept no arguments and return a one-line
-string for displaying doc about a function etc. appropriate to
-the context around point.  It should return nil if there's no doc
-appropriate for the context.  Typically doc is returned if point
-is on a function-like name or in its arg list.
+  "Hook of functions that produce doc strings.
+Each hook function should accept at least one argument CALLBACK
+and decide whether to display a doc short string about the
+context around point.  If the decision and the doc string can be
+produced quickly, the hook function can ignore CALLBACK and
+immediately return the doc string, or nil if there's no doc
+appropriate for the context.  Otherwise, if its computation is
+expensive or can't be performed directly, the hook function
+should arrange for CALLBACK to be asynchronously called at a
+later time, passing it either nil or the desired doc string.  The
+hook function should then return a non-nil, non-string value.
+
+Note that this hook is only in effect if the value of
+`eldoc-documentation-function' (notice the singular) is bound to
+one of its pre-set values.
+
+Typically doc is returned if point is on a function-like name or
+in its arg list.
 
 Major modes should modify this hook locally, for example:
   (add-hook \\='eldoc-documentation-functions #\\='foo-mode-eldoc nil t)
@@ -351,30 +363,30 @@ eldoc-documentation-functions
 taken into account if the major mode specific function does not
 return any documentation.")
 
+(defun eldoc--handle-multiline (res)
+  "Helper for handling a bit of `eldoc-echo-area-use-multiline-p'."
+  (if eldoc-echo-area-use-multiline-p res
+    (truncate-string-to-width
+     res (1- (window-width (minibuffer-window))))))
+
 (defun eldoc-documentation-default ()
   "Show first doc string for item at point.
 Default value for `eldoc-documentation-function'."
-  (let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
-    (when res
-      (if eldoc-echo-area-use-multiline-p res
-        (truncate-string-to-width
-         res (1- (window-width (minibuffer-window))))))))
+  (run-hook-with-args-until-success 'eldoc-documentation-functions
+   eldoc--callback))
 
 (defun eldoc-documentation-compose ()
   "Show multiple doc string results at once.
 Meant as a value for `eldoc-documentation-function'."
-  (let (res)
-    (run-hook-wrapped
-     'eldoc-documentation-functions
-     (lambda (f)
-       (let ((str (funcall f)))
-         (when str (push str res))
-         nil)))
-    (when res
-      (setq res (mapconcat #'identity (nreverse res) ", "))
-      (if eldoc-echo-area-use-multiline-p res
-        (truncate-string-to-width
-         res (1- (window-width (minibuffer-window))))))))
+  (let ((res 0))
+    (run-hook-wrapped 'eldoc-documentation-functions
+                      (lambda (f)
+                        (let ((str (funcall f eldoc--callback)))
+                          (if (stringp str) (funcall eldoc--callback str)
+                            (setq res (1+ res)))
+                          nil)))
+    ;; play ball with `eldoc-print-current-symbol-info'
+    (if (plusp res) (1- res) "")))
 
 (defcustom eldoc-documentation-function #'eldoc-documentation-default
   "Function to call to return doc string.
@@ -408,6 +420,11 @@ eldoc--supported-p
            ;; there's some eldoc support in the current buffer.
            (local-variable-p 'eldoc-documentation-function))))
 
+;; this variable should be unbound, but that confuses
+;; `describe-symbol' for some reason.
+(defvar eldoc--callback nil
+  "Dynamically bound.  Passed to  `eldoc-documentation-functions'.")
+
 (defun eldoc-print-current-symbol-info ()
   "Print the text produced by `eldoc-documentation-function'."
   ;; This is run from post-command-hook or some idle timer thing,
@@ -417,11 +434,43 @@ eldoc-print-current-symbol-info
         ;; Erase the last message if we won't display a new one.
         (when eldoc-last-message
           (eldoc-message nil))
-      (let ((non-essential t))
+      (let ((non-essential t)
+            (buffer (current-buffer)))
         ;; Only keep looking for the info as long as the user hasn't
         ;; requested our attention.  This also locally disables inhibit-quit.
         (while-no-input
-          (eldoc-message (funcall eldoc-documentation-function)))))))
+          (let* (;; `wanted' and `received' keep track of how many
+                 ;; docstrings we expect from the clients.  negative
+                 ;; `wanted' means store docstring for later but don't
+                 ;; message yet; likewise for a positive value, but we
+                 ;; decrease it by one.  Any other value (including 0)
+                 ;; means the next time the callback is called we're
+                 ;; composing and outputting whatever we got.
+                 (wanted -1) (received '())
+                 (eldoc--callback
+                  (lambda (string)
+                    (with-current-buffer buffer
+                      (cond ((and (numberp wanted) (not (zerop wanted)))
+                             (if (plusp wanted)
+                                 (setq wanted (1- wanted))) ; decf where art thou?
+                             (push string received))
+                            (wanted
+                             (unless (string= string "") (push string received))
+                             (setq wanted nil)
+                             (eldoc-message
+                              (eldoc--handle-multiline
+                               (mapconcat #'identity (nreverse received) ", "))))
+                            (t
+                             ;; For now, silently swallow anything the
+                             ;; client unexpectedly gives us
+                             )))))
+                 (res (funcall eldoc-documentation-function)))
+            (cond (;; we got a string, we should output immediately
+                   (stringp res) (setq wanted t) (funcall eldoc--callback res))
+                  (;; got something else, trust eldoc--callback will be called
+                   res           (setq wanted res))
+                  (;; got nil, clear the echo area
+                   t             (eldoc-message nil)))))))))
 
 ;; If the entire line cannot fit in the echo area, the symbol name may be
 ;; truncated or eliminated entirely from the output to make room for the
diff --git a/lisp/hexl.el b/lisp/hexl.el
index cf7118f208..38eca77e26 100644
--- a/lisp/hexl.el
+++ b/lisp/hexl.el
@@ -515,7 +515,7 @@ hexl-current-address
       (message "Current address is %d/0x%08x" hexl-address hexl-address))
     hexl-address))
 
-(defun hexl-print-current-point-info ()
+(defun hexl-print-current-point-info (&rest _ignored)
   "Return current hexl-address in string.
 This function is intended to be used as eldoc callback."
   (let ((addr (hexl-current-address)))
diff --git a/lisp/progmodes/cfengine.el b/lisp/progmodes/cfengine.el
index f25b3cb9e2..9a6d81ce06 100644
--- a/lisp/progmodes/cfengine.el
+++ b/lisp/progmodes/cfengine.el
@@ -1294,7 +1294,7 @@ cfengine3-make-syntax-cache
                           'symbols))
         syntax)))
 
-(defun cfengine3-documentation-function ()
+(defun cfengine3-documentation-function (&rest _ignored)
   "Document CFengine 3 functions around point.
 Intended as the value of `eldoc-documentation-function', which see.
 Use it by enabling `eldoc-mode'."
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index d37eb8c152..d7865a7319 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1402,8 +1402,10 @@ elisp--eldoc-last-data
       or argument string for functions.
   2 - `function' if function args, `variable' if variable documentation.")
 
-(defun elisp-eldoc-documentation-function ()
-  "`eldoc-documentation-function' (which see) for Emacs Lisp."
+(defun elisp-eldoc-documentation-function (_ignored &rest _also-ignored)
+  "Contextual documentation function for Emacs Lisp.
+Intended to be placed in `eldoc-documentation-functions' (which
+see)."
   (let ((current-symbol (elisp--current-symbol))
 	(current-fnsym  (elisp--fnsym-in-current-sexp)))
     (cond ((null current-fnsym)
diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index 352c1810d1..2cf305c404 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -1639,8 +1639,8 @@ octave-eldoc-function-signatures
                   (nreverse result)))))
   (cdr octave-eldoc-cache))
 
-(defun octave-eldoc-function ()
-  "A function for `eldoc-documentation-function' (which see)."
+(defun octave-eldoc-function (&rest _ignored)
+  "A function for `eldoc-documentation-functions' (which see)."
   (when (inferior-octave-process-live-p)
     (let* ((ppss (syntax-ppss))
            (paren-pos (cadr ppss))
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 1ca9f01963..404a67ba9f 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -4571,7 +4571,7 @@ python-eldoc-function-timeout-permanent
   :type 'boolean
   :version "25.1")
 
-(defun python-eldoc-function ()
+(defun python-eldoc-function (&rest _ignored)
   "`eldoc-documentation-function' for Python.
 For this to work as best as possible you should call
 `python-shell-send-buffer' from time to time so context in
-- 
2.20.1


--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 May 2020 15:57:02 +0000
Resent-Message-ID: <handler.41531.B41531.159050858823674 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159050858823674
          (code B ref 41531); Tue, 26 May 2020 15:57:02 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 15:56:28 +0000
Received: from localhost ([127.0.0.1]:46237 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdbwJ-00069m-Le
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 11:56:28 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13073)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jdbwI-00069Q-Az
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 11:56:26 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D459344095C;
 Tue, 26 May 2020 11:56:19 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F2A6D440947;
 Tue, 26 May 2020 11:56:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1590508573;
 bh=tjT3VvlwmGlj8Sh6s0htvR9NsecfKOfIJZoasKN3nVo=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=CeLv/2WgzyOp8ABYIzkROZgf1RRwBNINnHv5HP27lgbtMKozOtRsZ7JwYqZBWytAJ
 1ad8TmFuUEqGxZ83SHtVbOtPjixwRqSNcO0dTm913qY/M2ny7K6xd6go0POOXB3s0W
 0lPrqk/Nux28RmYyCHB5FC6PM4Gk47z9l2Y6/wKm0PQQ0ht3gecSNK/+8dqopbFFfX
 qOdYMoT+0telLfpMVXUbAtzVhLREANn7VA/NEo+H1EbfwvA4MO7OIXkrob3SIurSKe
 fZfsMeBlra8p70v4WSCBny3WybteNZa/44tb5ZD1cL41HxUt0f5dewvj0i8T3ouA/V
 u8EG3I1jahqVQ==
Received: from milanesa (unknown [216.154.27.250])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6D7ED120388;
 Tue, 26 May 2020 11:56:13 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
Date: Tue, 26 May 2020 11:56:12 -0400
In-Reply-To: <87pnaqrae9.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 26
 May 2020 16:19:58 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.097 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

> It's not complete, is it?

Don't know.  I have the impression that it's complete enough to give you
the same "power" as the callback argument.

I.e. instead of (funcall BACKEND CALLBACK)
you (eldoc-future-set-callback (funcall BACKEND) CALLBACK) and instead
of (funcall CALLBACK VALUE) you (eldoc-future-set-value FUT VALUE).

> And how to I use it to solve the
> eldoc-documentation-compose problem?

AFAIK this is orthogonal to the technique we use for the backend to run
eldoc's callback code.

> I suppose it's possible, anything
> is.  But do we really want to hand-roll futures in eldoc.el when we got
> this nice https://github.com/skeeto/emacs-aio/commits/master that we
> could be looking into?

I'm not familiar with that package, so I can't judge.  It might be an
even better option, indeed.

> Also the latest patch I attach solves the eldoc-documentation-compose
> problem decently (should actually be less LOC than previous versions).
> I suggest we go with this tried-and-tested well-understood solution and
> then adjust as more sophisticated solutions come along and we evaluate
> their merits.

The use of futures has been discussed forever in the context of
several packages.  That's why at this stage, I think either we decide to
drop the idea or to start using it.
I'm OK with either option.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 16:04:01 +0000
Resent-Message-ID: <handler.41531.B41531.159050903824400 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159050903824400
          (code B ref 41531); Tue, 26 May 2020 16:04:01 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 16:03:58 +0000
Received: from localhost ([127.0.0.1]:46241 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdc3Z-0006LT-Lh
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 12:03:58 -0400
Received: from mail-wm1-f66.google.com ([209.85.128.66]:34509)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jdc3X-0006LD-4Q
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 12:03:56 -0400
Received: by mail-wm1-f66.google.com with SMTP id u26so308556wmn.1
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 09:03:55 -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=cI9f1J+GfuIjdJGbEjW+fz6xOAvD28VIvKEEWidEceI=;
 b=B0llQ/l4s9l/UAERZAMb1s6XeQvZkcOUktjlecX5wK8zGmigEbKr2FEGo364EeRqD4
 VbUT4yc3lUK9wd9H2fNJmdxZcyPSud23VQNDxkkR1Ee7L383Vxe9V4mXxe1EygUwkDHY
 N2fZDxCpzN6eLU9NGts+oOZqdP9ybcuPJIeQWWXqXRr60qEIImYaVk698ny2kinoVyzJ
 0HafZQHT4MXcs6oLbcfE/1UhZR01zmJc4ZyI2Sj84Jb8my98VBYTpepdd3T1oPWffncM
 oxfBVM4jq6Nn983z8PYAfTbaPrlM0ZivlJcB7JCcSetINinogNKaerk4J8C1Peefb8ch
 j9RQ==
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=cI9f1J+GfuIjdJGbEjW+fz6xOAvD28VIvKEEWidEceI=;
 b=JpPBnX2YJvPviUVntujWE3J72COhoZoaTBpksz8mrjlzY6OoJ/cR341ABFVGWg6fDj
 SkndG/VqOHuo555fKnFsaBVEH4nM9lEeUq53NspiWemld9da3Pvia0HpGlXOA8oR9uyU
 GeYErK31GHpBjl1CST/uI+Fc7SF5EpOTpyllh7hMbApA7wqE9wyC8ga3zdeKJpmjndxL
 rXBBPn9hU3IBS5OqUGv4OxaQxzISY745gJh9JPiMVIXmzHMQGB/5V7+izf1jROPIwtAG
 ewpY3UNx1wnnCQzQjLqN1L4p2iLZ4KuTTFB77pI5qXk1Fj/xnvhRofigcb34u4lBnToH
 WvPg==
X-Gm-Message-State: AOAM532KW+WUGIpot+bhpWo1saw3Hs8hi753Z9cAspBKn58uuA7a0E13
 WDW+3BCzrLz7y3Zkt1D8+Ds=
X-Google-Smtp-Source: ABdhPJzQgEEmr1vJOAI+uQVRfXDn9e2MOeR8YghOaLiN6CDsq41ltdzyY+LjaMmhbDh40vE3tvDrwA==
X-Received: by 2002:a05:600c:34c:: with SMTP id
 u12mr2039218wmd.4.1590509029091; 
 Tue, 26 May 2020 09:03:49 -0700 (PDT)
Received: from krug ([89.180.149.243])
 by smtp.gmail.com with ESMTPSA id p10sm266989wra.78.2020.05.26.09.03.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 May 2020 09:03:48 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <87k10zsd85.fsf@HIDDEN>
 <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN>
Date: Tue, 26 May 2020 17:03:46 +0100
In-Reply-To: <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> (Dmitry Gutov's
 message of "Tue, 26 May 2020 16:57:13 +0300")
Message-ID: <87ftbmr8d9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (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 26.05.2020 04:21, Jo=C3=A3o T=C3=A1vora wrote:
>> Dmitry Gutov <dgutov@HIDDEN> writes:
> They also use *special* variables? Flymake's API looks fairly clean
> (you call back to REPORTER-FN, that's very reasonable), but I haven't
> looked under the covers yet.

REPORTER-FN, is just another name for CALLBACK.  Flymake doesn't need
these special variables because its API doesn't go through an old,
argless shim like eldoc-documentation-function, singular.  If it did, it
would need a special variable, which is not such a ghoulish thing
either.

>> To simplify, hopefully you agree that your proposal can be summarized
>> as:
>>    "return a function that receives a function that you
>>     should call with the docstring"
>> whereas my proposal can be summarized as:
>>    "receive a function that you should call with the docstring"
>
> To clarify, you actually included two proposals (behavior with patch
> 1, and with both patch 1 and patch 2 applied). The first one is the
> one I really didn't like. The second one is better, API-wise, but will=20
> conflict with the futures-based approach.

It's not a conflict at all.  When you do the futures-based approach
you're going to rewrite the docstring to augment the API.  You do the
same here: just add this to the docstring:

   "If you prefer, ignore CALBACK and return a `future-future' object from
    this function".

How is that different from:

   "If you prefer, instead of returning a (:ASYNC . FUNCTION) cons,
   return a `future-future' object from this function""

???

>> I'll leave that for later.  Specifically, eldoc--handle-multiline has to
>> do quite a bit more handling (to satisfy Andrey's expectations).
> I'm not so such it's independent. The complexity of implementing that
> would certainly vary.

It is quite independent.  Just look at the last patch I sent Stefan.
There's only one call to eldoc--handle-multiline (in fact we could ditch
it entirely).

> BTW, maybe eldoc-message should handle this after all? Since it's the
> last link in the chain. Or even do that in the default value of=20
> eldoc-message-function (create a wrapper for minibuffer-message).

Doesn't work well becasue eldoc-message is called by both the produced
_and_ the backend, as I showed you earlier.  And it certainly doesn't
work with eldoc-documentation-compose.

>> Replying to parts from the other discussion in the Github tracker now.
>>=20
>>> OK, another question: if the result still /valid/?
>>                          ^^ Assuming you mean "is".
>> Well, if the client discovers the result to be invalid, ...
>
> So the client will have to save and then compare the current buffer,
> the value of point and buffer-chars-modification-tick now?

Ah, _that_ validity.  No, no, never do that.  The client should have no
idea of it.  In the framework you either make the callback a noop, or
you set it aborted for the client to save some work.  Or both.

>>> No idea, a hypothetical one. It's an open API, not everybody is or
>>> will be using LSP until the end of time. And it doesn't really have to
>>> be huge. A saving is a saving.
>> There's no free lunch.  A very small saving in time for more
>> complexity
>> is bad.  That's what overengineered means.
>
> Futures are not particularly more complex to use.

Sure, but they are _more_ complex.  And you're mixing up two things:
futures _aren't_ the only way -- or even a particularly easy way -- to
signal to the clients that thety can give up their efforts.  All the
client needs to have is access to an object that's shared between it and
the framework.  That object _needn't_ be a first-class CLOS object or
struct.  It can be a function.

>>> You can certainly kill the external process outside of it. Saving on
>>> CPU expenses in general.
>> The future's creditor is the only one who could do that to any
>> useful
>> effect.  Does it have access to the process?  Probably not.
>
> It can (barring any complex abstractions). It created the process,
> after all.

Not really, it asked a client to solve a problem, doesn't know how the
client if the client is doing by async process or cointoss.

>> You would have to return a complex future with a kill switch.  That's
>> possible, but tricky, because you'd then have to be ready in the
>> sentinel for another source of unexpected kills.
>
> That would be none of ElDoc's business, though. But the implementation
> will get to be as complex as it needs.

_That's_ why an abort switch whose contract is "kill this immediately"
is a bad idea.  An abort switch whose contract is "just letting you know
I don't need this anymore" is better.  But again, in eldoc, not so
useful.  And again, nothing to do with futures here.

>> Why indeed?  Your other argument, that this makes the transition to
>> proper futures (such as the ones in https://github.com/skeeto/emacs-aio)
>> easier, is questionable, too.  There are two scenarios here:
>> - You want to keep backward compatibility to this API published in
>> eldoc
>>    1.1.0 until the time of the Emacs 28 release:
>
> The one thing I want to avoid doing is changing the callsig of every
> documentation function, and then changing them back when we switch to=20
> futures.

So _don't_ change the "callsig".  If you implement futures you _are_
going to change the protocol anyway, i.e. write new stuff in the
docstring.

>>    This is something that I -- and Stefan, if I'm not mistaken, -- don't
>>    think we should worry about.  Just because a package is :core GNU ELPA
>>    doesn't necessarily mean we guarantee stability of its API.
>
> Um, I'm pretty sure we guarantee a fair amount of stability.

That's not what Stefan said here:

   https://github.com/joaotavora/eglot/pull/459#issuecomment-633634034

And that's not what the Dmitry from 2016 wrote in xref.el

   +;; NOTE: The xref API is still experimental and can change in major,
   +;; backward-incompatible ways.  Everyone is encouraged to try it, and
   +;; report to us any problems or use cases we hadn't anticiated, by
   +;; sending an email to emacs-devel, or `M-x report-emacs-bug'.

That has been sitting there for almost three Emacs major versions (in
fact you added it after the initial 25 release).  All I'm asking is for
a little such flexibility with eldoc.

>>    But if we do, then we'll have to explain in the docstring that there
>>    is a fourth return value for the hook functions.  In my version we'll
>>    have to do exactly the same.
>> - You don't want to keep backward compatibility until Emacs 28:
>>    Then, when the super-futures are here, you can just kill the
>> CALLBACK
>>    arg if we find it doesn't fit and rewrite the docstring without
>>    concerns.
>
> Kill the arg in all built-in functions, as well as in external
> consumers?

Yes, if we discover there aren't so many.  Currently there are 5 users
in Emacs proper, 0 in GNU ELPA and quite sure 0 elsewhere in the world.
So 0 external consumers.  Do you really think if I push my patch there
will be hordes of eldoc-documentation-functions users out there using
this horrible futureless API that I'm proposing?  There won't, and I'm
happy to add a big disclaimer to the top of the eldoc.el file.

But if you really think we wouldn't be able to bring ourselves to kill
the arg, then just reintroduce eldoc-documentation-callback, and kill
_that_ later on.  Or just don't kill the arg, period.

It just looks like you're holding this problem hostage to introducing
some kind of rushed futures solution.  I don't agree with either of
these things.  I think this particular problem shouldn't be held hostage
to rearchitecting async in Emacs, laudable and useful a goal as that
might be.  And I think a futures library should be well thought out: I'd
like to discuss this in emacs-devel, at least get some opinions on
Christopher Wellon's solution, which seems very elegant.

In the meantime, I have a working patch that follows current coding
practice, solves this problem and in no way prevents or interferes with
future work.

Anyway, see the patch I sent to Stefan.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 16:27:01 +0000
Resent-Message-ID: <handler.41531.B41531.159051040526518 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159051040526518
          (code B ref 41531); Tue, 26 May 2020 16:27:01 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 16:26:45 +0000
Received: from localhost ([127.0.0.1]:46271 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdcPc-0006td-Hq
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 12:26:44 -0400
Received: from mail-wm1-f41.google.com ([209.85.128.41]:50455)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jdcPa-0006tQ-7M
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 12:26:42 -0400
Received: by mail-wm1-f41.google.com with SMTP id v19so156919wmj.0
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 09:26:42 -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=zvBDeXnk2okeXkDsnXkMMpzL27SA7cke2aPe6AJflFM=;
 b=Jc7dJUjIQfRXUOPi1PmKYE6iEYE9KXC1ysRHtVgGGkk0Hmx7VBo4W+kTX3NYyZKFMb
 yHTt9+t1U1q534uwowqNitgKVlQ+VVK6GxckF3ckqaA4MjQ3Z53QnqUxlqJwWDscgRaZ
 G12HBA/M0xnpZREwgwFARmXoAGcSN71oHFT26/INWQFbHlR5ypnbZWFJOLCUY5FX2LFz
 V32h+Xw3J7S8SVnGIkXyjHV6CCvpAsB8bM10ulq3a+/CXLKp+qVuVYffUEMVxh3fPTNG
 iSLtIx/9DVkcetFYpmMn1tCnpZvhPjdYd/x34WeRCT2DftQG+i4JeMnpTeSzz5NweZRO
 +bQw==
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=zvBDeXnk2okeXkDsnXkMMpzL27SA7cke2aPe6AJflFM=;
 b=bKCgYVv0NC7oQJI5TMWTgVxMYKl26W7REVwortpBBFGiSPYaat24zVYmNbia56POl9
 kjtZwvzQ/8an5UuE5EmicGkzqfdQ00vq8NsXGTc9dS6Xhrm9nnPwvDOKzyWO49m1k0GC
 phA3+UDAfvEtX+yYwVMqwJMCRPb6qObFmq14duARRm6/Udl2/13+JiuXqjz79p4tsDZS
 9dTwzHnDFKbq0F0Hov3jcm/wfne4GA1AUkYCe3gDfvwGtrkWJrc0YcVorv7pQOwQWNiT
 7hgVOgYOFUySNyUd0z8WxXw8mMPXb1Zk4wSqcz9mTlM+FjnQLeNFlHTEzLTHWEb/c2X+
 LqoQ==
X-Gm-Message-State: AOAM531iEzAxfN2RxbiaoqfOxiEuZOSDJBMnJENZYH1yNIMVGOtlYMc+
 f/2DO3gWlkJXUY4PpckWNiE=
X-Google-Smtp-Source: ABdhPJyNEh2FX7z0woLM5mk1p2ezYIkheraSMXnb92EnCp9xY+DkInAKJf3SyTzDos35N0+EWqOySQ==
X-Received: by 2002:a05:600c:2255:: with SMTP id
 a21mr33335wmm.67.1590510396329; 
 Tue, 26 May 2020 09:26:36 -0700 (PDT)
Received: from krug ([89.180.149.243])
 by smtp.gmail.com with ESMTPSA id g18sm32386wme.17.2020.05.26.09.26.35
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 May 2020 09:26:35 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN>
Date: Tue, 26 May 2020 17:26:34 +0100
In-Reply-To: <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Tue, 26 May 2020 11:56:12 -0400")
Message-ID: <877dwyr7b9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (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 (-)

[  Christopher, I'm CC-ing you in this discussion becasue we've been
discussing adding futures to Emacs, and I came across your aio.el
library which seems very promising.  (I am, however, proposing a
pragmatic intermediate solution to the particular problem in the subject) ]

Stefan Monnier <monnier@HIDDEN> writes:

>> It's not complete, is it?
>
> Don't know.  I have the impression that it's complete enough to give you
> the same "power" as the callback argument.

> I.e. instead of (funcall BACKEND CALLBACK)
> you (eldoc-future-set-callback (funcall BACKEND) CALLBACK) and instead
> of (funcall CALLBACK VALUE) you (eldoc-future-set-value FUT VALUE).

It is, yes.  The code is clear, not transcendental at all.  But writing
docstrings is hard.  In fact, it's possibly the hardest part of the
game.  Tell you what: you write the docstring for
eldoc-documentation-functions, I'll do the implementation.

Deal?

>> And how to I use it to solve the
>> eldoc-documentation-compose problem?
>
> AFAIK this is orthogonal to the technique we use for the backend to run
> eldoc's callback code.

Not really.  A "proper" futures library will have primitives that handle
this very elegantly.  I.e. a future that depends on multiple futures, a
future that applies a function to the first available future.  The kind
of stuff I'm sure you'll love, academically.  That would be the thing to
use there, otherwise we're just playing legos with structs and
functions.

>> I suppose it's possible, anything
>> is.  But do we really want to hand-roll futures in eldoc.el when we got
>> this nice https://github.com/skeeto/emacs-aio/commits/master that we
>> could be looking into?
>
> I'm not familiar with that package, so I can't judge.  It might be an
> even better option, indeed.

I believe it has such functionality that I mentioned before.  And then
some.  I don't understand it filly but it seems nicely coded, has two
authors that have (99% sure) assigned copyright.  The library calls
futures "promises", by the way.

>> Also the latest patch I attach solves the eldoc-documentation-compose
>> problem decently (should actually be less LOC than previous versions).
>> I suggest we go with this tried-and-tested well-understood solution and
>> then adjust as more sophisticated solutions come along and we evaluate
>> their merits.
> The use of futures has been discussed forever in the context of
> several packages.  That's why at this stage, I think either we decide
> to drop the idea or to start using it.

> I'm OK with either option.

Black and white, do or die? Nah, I don't buy it :-)

Let me be honest: the thing I'm not crazy about in futures is that if we
go the handrolled eldoc.el route that creates another distraction to
maintain separately.  Eldoc's problem lie elsewhere.

Let's use futures in the new completion API thingy, or in an elisp json
library, where they might brutally speed up parsing, by doing parsing
only parts of the document that users access.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 16:58:02 +0000
Resent-Message-ID: <handler.41531.B41531.159051223529260 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159051223529260
          (code B ref 41531); Tue, 26 May 2020 16:58:02 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 16:57:15 +0000
Received: from localhost ([127.0.0.1]:46302 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdct9-0007bs-AB
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 12:57:15 -0400
Received: from mail-il1-f174.google.com ([209.85.166.174]:38824)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jdct7-0007be-PP
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 12:57:14 -0400
Received: by mail-il1-f174.google.com with SMTP id q18so33207ilm.5
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 09:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=ofp2oyKW8Zd+/QfNc+lJxDSt3eLPlfJ09m8Mgqyl/Tk=;
 b=bCUL8juBO5fgE0Ci4WJU6QGd7PpZlyy2v8u8tgEcyYhDxFse4eNJewsESR9Mu94Q/1
 XWglMkIdWVgmeUY91UhN9igCaFUiFd9mazmwEU/yxj0Z/KHrMUqQ4TspBDiC4E2aC6Yo
 I8Sm8QJbX+u+4m9PMCrio8TLD1zAt+Q0b4gq5NybteCHF4wWK/8Qt8ZfHsRzrcKgDC5t
 0U3C+GAm4psC3enWX7bBl7Xu4+6QCNSbMlGDevHdhim/NwSYdMxEQTnaSDlpfFtRyWxw
 zmlsRFM0XheukB3LH/CkbE01KN844n3YOXDzu/LLjxUzm3ycWrcG9IQMD96GHABm2QTt
 acRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=ofp2oyKW8Zd+/QfNc+lJxDSt3eLPlfJ09m8Mgqyl/Tk=;
 b=q8pV4hRgrqA7s3hJ1152jH4UHUXlQj2ds7/6OpktmmboD7+xFC32qP7QWqX71SQ+wC
 MbxCxc1sLdKlNnvi1mdc3vqpULH7AMTRliqcnTst0btW4V9zK56wrp7PTo0aNP0FPXqG
 m5gFVHLrCeKV9TevbHj3jeWkVCAS0acgDJmdJPil7pmX3aqQQLpavnrEJ5aRWgdfQsM1
 Re6VO3BKJXLdtTyqnKlI12NSw0R80FNOFESMuqxuz/DNy1c6talwX4RZds85vgb/SxHv
 9VpXmzoGQZ9ABl1KMVP7yYp03ja6D/zcCPUB3cllT3phxpbGV4KcF7YJLNQEVZlc24mF
 Z/Pg==
X-Gm-Message-State: AOAM531qa82XycN/WcdcURh4Xtmw8b3OZEz8MjwJ9DeKiEVjsNaumsZR
 sMemiUXWSoajkaqspGiBZDFv7aJ0Cgv1w3a22u0=
X-Google-Smtp-Source: ABdhPJydgR/UtyU2dkfu/Lz7ObzMIYGroCU9OVnq3qlECKpxHlHpzdwg79nbaBNc6WiUmai03nNoC4uGqkL4npdwBX8=
X-Received: by 2002:a92:485d:: with SMTP id v90mr1974528ila.125.1590512228093; 
 Tue, 26 May 2020 09:57:08 -0700 (PDT)
MIME-Version: 1.0
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN>
 <563f298a-a0cb-044d-2619-068e8d30f119@HIDDEN>
In-Reply-To: <563f298a-a0cb-044d-2619-068e8d30f119@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 26 May 2020 17:56:56 +0100
Message-ID: <CALDnm5224yxMwJed-qwjzV0+Q7A-P437VS=kf-jJZFmc7uruxQ@HIDDEN>
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 (-)

On Tue, May 26, 2020 at 2:32 PM Dmitry Gutov <dgutov@HIDDEN> wrote:
> On 26.05.2020 05:38, Stefan Monnier wrote:
> >> Here's a modified approach that doesn't use a global var and should ma=
ke it
> >> easier to transition to using futures.
> > I think at this stage, we should either start using futures or we shoul=
d
> > forget about ever using them.
> We should certainly do it before Emacs 28 is released (so we won't have
> to support whatever ad-hoc option is currently being proposed).

Agree.  By my estimate we have ~2 years to go, tho.  And ad-hoc
is a value judgement that you could apply to every part of Emacs
could be improved (then someone else might call _that_ ad-hoc).

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 26 May 2020 17:40:01 +0000
Resent-Message-ID: <handler.41531.B41531.1590514785576 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.1590514785576
          (code B ref 41531); Tue, 26 May 2020 17:40:01 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 17:39:45 +0000
Received: from localhost ([127.0.0.1]:46319 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jddYG-00009E-J3
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 13:39:45 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12584)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jddYF-00008z-1e
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 13:39:43 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 333EA10093D;
 Tue, 26 May 2020 13:39:37 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9DE7410083A;
 Tue, 26 May 2020 13:39:35 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1590514775;
 bh=p6zB6oKprJhduHuautFivhvJfVzI5seNS0GCne0f02M=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=USclucUES8WnHdnRR9vnyxhVRPQf/gvdxKbvraYnsDY8MoIuhfJn0fEoCZrIbI1fm
 N5/keIf5ApZSzcIlO9ALcUUuvGRbz2FhmQbnG7ZBLCuLI8DvQ7Y+ExDFcLUHgncjQ8
 6QHkLysqf90NY66P+6esvd02Ib6R2nLlJKTmtnFr8ehHxSjpmxM5bjA4/aFxk9k5V2
 vflUOfy/yH5ouwpo3kNyQgB6T52/3iUmIlEnxrPXTyB0reM/dWVAJhHnRc/kEj0KUI
 wALwj/htktWBDsW6x/wvGQWJtpFY1XvhhL5HM9xBOKm1eMVlgORJ2aHVJ51cwbshHG
 P9q4gHHzstsnA==
Received: from milanesa (unknown [216.154.27.250])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 50EE91207D6;
 Tue, 26 May 2020 13:39:35 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwv1rn64n38.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
Date: Tue, 26 May 2020 13:39:34 -0400
In-Reply-To: <877dwyr7b9.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 26
 May 2020 17:26:34 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.086 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

> It is, yes.  The code is clear, not transcendental at all.  But writing
> docstrings is hard.  In fact, it's possibly the hardest part of the
> game.  Tell you what: you write the docstring for
> eldoc-documentation-functions, I'll do the implementation.
>
> Deal?

Deal, at the condition that the code comes before I write the docstrings ;-)
[ I like this deal: it's always better for someone else to write the
  docstrings, so at least 2 persons need to agree on what they think the
  code does (assuming the author of the code checks the resulting docstrings).  ]

> I believe it has such functionality that I mentioned before.  And then
> some.  I don't understand it filly but it seems nicely coded, has two
> authors that have (99% sure) assigned copyright.  The library calls
> futures "promises", by the way.

I'm willing to tweak my vocabulary.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 18:50:02 +0000
Resent-Message-ID: <handler.41531.B41531.15905189636904 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15905189636904
          (code B ref 41531); Tue, 26 May 2020 18:50:02 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 18:49:23 +0000
Received: from localhost ([127.0.0.1]:46381 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdeda-0001nE-SB
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 14:49:23 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:51398)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jdedW-0001my-QD
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 14:49:17 -0400
Received: by mail-wm1-f45.google.com with SMTP id u13so622593wml.1
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 11:49:14 -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;
 bh=qKDBWxM5ME9WV0JKLHRjiPEUyHxSlaspu6+8OnRo83E=;
 b=ub5lbg9otsw8uTPDkuHd1EaEGblIvZt8cYkwWtw2lQD1Rz7rfN68a2bJHFCTNQFP4L
 vDD3E6+tP7XjCUA2JqSZTZN0lrbWQQ0vkiWZIB97r/kG8YTdBT83DzsCA/C5hldois5M
 oNw5agIUxNIe6PDBqgUUMf+5QDCkhyt7/jTydiT0m73EKD2K6DtRl5+5vz4lI2J/2IQh
 o3+W4H+LjKCyl/XY74gSCHO9IIJVtdrm/MZZs15bj3Ig3WVhwtTnjRpsp4+yqVAzUayK
 cIGLkeJK+3d4PocCTS2Intn+EN4vJjUi+iK+hxc6dlQOuAdtfMaANljXz+2oB9oqqy8Q
 zztA==
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;
 bh=qKDBWxM5ME9WV0JKLHRjiPEUyHxSlaspu6+8OnRo83E=;
 b=neDY4h+PDDJyZW/STN0PPJA9E1PboIHtkFl4mZaOLN4XW8z2Iu2x9H6boy8ENUdqGg
 kGjG6TOevah6xdAZteYzX98WfyTjyHAMOFZS2Jbq0jFKqvfqaLkjXbHOxOpAvrioqWHJ
 h1+tEBvNdZWISMv0/rXHvexgizgz9p5G2jeQk0wf4IqvGgFy54/Qa5AMRjlq4ciJUorZ
 H8a6fg44foT9nUKoBlvhCUktjcnakHXwga8KYWmUlEjFwC8pCp7X1B17kaxVGiz3JhzE
 1b9EJyWJDC4FoeJ+rAWnM4dwV3MhW+oS2y5AHa86rFMyAFh+rJSDAVC6PnkbgzXsAOH/
 4FHQ==
X-Gm-Message-State: AOAM530ePQE8ZOIdjDjtShHr23dlaR3Mp4UgNCe1+6+KDpu6byFot2Vh
 JpbeRF3Y0yHmYhlHujtufJw=
X-Google-Smtp-Source: ABdhPJz2Eu2NW9XgG0G3QUjxyTZKsy0ybbQZ8EnW9zdYFXo7vkXCEUa8/mwg0bVQVOmzjl/JJPUDCA==
X-Received: by 2002:a1c:f301:: with SMTP id q1mr519221wmq.109.1590518947774;
 Tue, 26 May 2020 11:49:07 -0700 (PDT)
Received: from krug ([89.180.149.243])
 by smtp.gmail.com with ESMTPSA id 190sm387910wmb.23.2020.05.26.11.49.05
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 May 2020 11:49:06 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
 <jwv1rn64n38.fsf-monnier+emacs@HIDDEN>
Date: Tue, 26 May 2020 19:49:04 +0100
In-Reply-To: <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Tue, 26 May 2020 13:39:34 -0400")
Message-ID: <871rn6r0pr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
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 (-)

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Stefan Monnier <monnier@HIDDEN> writes:

>> It is, yes.  The code is clear, not transcendental at all.  But writing
>> docstrings is hard.  In fact, it's possibly the hardest part of the
>> game.  Tell you what: you write the docstring for
>> eldoc-documentation-functions, I'll do the implementation.
>>
>> Deal?
>
> Deal, at the condition that the code comes before I write the docstrings =
;-)

Okay. 2 patches attached (my version + your futures).  Just search for
'WORLD CLASS DOCSTRING' and fill in your part.

For my part, really feels like I've reimplemented funcall.

Anyway both approaches lightly tested on this foo.el file:

;;; foo.el --- foobarbaz  -*- lexical-binding:t; -*-
(setq-local eldoc-documentation-function #'eldoc-documentation-compose)

;; Callback approach
;;
(setq-local eldoc-documentation-functions nil)
(defun eldoc-cback-0 (cback &rest _)
  (run-with-timer 0.22 nil
                  (lambda () (funcall cback (symbol-name (gensym "cback-0-"=
))))))
(defun eldoc-cback-1 (&rest _) (symbol-name (gensym "cback-1-")))
(defun eldoc-cback-2 (cback &rest _)
  (run-with-timer 2.22 nil
                  (lambda () (funcall cback (symbol-name (gensym "cback-2-"=
))))))

(add-hook 'eldoc-documentation-functions #'eldoc-cback-0 00 t)
(add-hook 'eldoc-documentation-functions #'eldoc-cback-1 10 t)
(add-hook 'eldoc-documentation-functions #'eldoc-cback-2 20 t)

;; Very futuristic approach
;;
(setq-local eldoc-documentation-functions nil)
(defun eldoc-future-0 ()
  (let ((f (eldoc-future-make)))=20
    (run-with-timer 0.22 nil (lambda () (eldoc-future-set
                                         f (symbol-name (gensym "future-0-"=
)))))
    f))
(defun eldoc-future-1 () (symbol-name (gensym "future-1-")))
(defun eldoc-future-2 ()
  (let ((f (eldoc-future-make)))
    (run-with-timer 2.22 nil (lambda () (eldoc-future-set
                                         f (symbol-name (gensym "future-2-"=
)))))
    f))

(add-hook 'eldoc-documentation-functions #'eldoc-future-0 00 t)
(add-hook 'eldoc-documentation-functions #'eldoc-future-1 10 t)
(add-hook 'eldoc-documentation-functions #'eldoc-future-2 20 t)

> [ I like this deal: it's always better for someone else to write the
>   docstrings, so at least 2 persons need to agree on what they think the
>   code does (assuming the author of the code checks the resulting docstri=
ngs).  ]

Yes, it's called cascade dev, and it gets a bad rep nowadays.  Tho the
person who writes the docstrings usually goes first ;-)

Jo=C3=A3o


--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
 filename=0001-Better-handle-asynchronously-produced-eldoc-docstrin.patch

From b97c0cfb0cbfea20cbf75ad7ea8abf9f4c51ec54 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Mon, 25 May 2020 16:39:40 +0100
Subject: [PATCH 1/2] Better handle asynchronously produced eldoc docstrings

No longer do clients of eldoc need to call eldoc-message (an internal
function) directly.  They may return any non-nil, non-string value and
call a callback afterwards.  This enables eldoc.el to exert control
over how (and crucially also when) to display the docstrings to the
user.

* lisp/emacs-lisp/eldoc.el (eldoc-documentation-functions):
Overhaul docstring.
(eldoc-documentation-compose, eldoc-documentation-default): Handle
non-nil, non-string values of elements of
eldoc-documentation-functions.
(eldoc-print-current-symbol-info): Redesign.
(eldoc--handle-multiline): New helper.
(eldoc--callback): New internal special var.
(Version): Bump to 1.1.0.

* lisp/hexl.el (hexl-print-current-point-info): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/cfengine.el (cfengine3-documentation-function):
Adjust to new eldoc-documentation-functions protocol.

* lisp/progmodes/elisp-mode.el
(elisp-eldoc-documentation-function): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/octave.el (octave-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.

* lisp/progmodes/python.el (python-eldoc-function): Adjust to new
eldoc-documentation-functions protocol.
---
 lisp/emacs-lisp/eldoc.el     | 101 ++++++++++++++++++++++++++---------
 lisp/hexl.el                 |   2 +-
 lisp/progmodes/cfengine.el   |   2 +-
 lisp/progmodes/elisp-mode.el |   6 ++-
 lisp/progmodes/octave.el     |   4 +-
 lisp/progmodes/python.el     |   2 +-
 6 files changed, 84 insertions(+), 33 deletions(-)

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index ef5dbf8103..fa36987014 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -5,7 +5,7 @@
 ;; Author: Noah Friedman <friedman@HIDDEN>
 ;; Keywords: extensions
 ;; Created: 1995-10-06
-;; Version: 1.0.0
+;; Version: 1.1.0
 ;; Package-Requires: ((emacs "26.3"))
 
 ;; This is a GNU ELPA :core package.  Avoid functionality that is not
@@ -338,12 +338,24 @@ eldoc-display-message-no-interference-p
 
 
 (defvar eldoc-documentation-functions nil
-  "Hook for functions to call to return doc string.
-Each function should accept no arguments and return a one-line
-string for displaying doc about a function etc. appropriate to
-the context around point.  It should return nil if there's no doc
-appropriate for the context.  Typically doc is returned if point
-is on a function-like name or in its arg list.
+  "Hook of functions that produce doc strings.
+Each hook function should accept at least one argument CALLBACK
+and decide whether to display a doc short string about the
+context around point.  If the decision and the doc string can be
+produced quickly, the hook function can ignore CALLBACK and
+immediately return the doc string, or nil if there's no doc
+appropriate for the context.  Otherwise, if its computation is
+expensive or can't be performed directly, the hook function
+should arrange for CALLBACK to be asynchronously called at a
+later time, passing it either nil or the desired doc string.  The
+hook function should then return a non-nil, non-string value.
+
+Note that this hook is only in effect if the value of
+`eldoc-documentation-function' (notice the singular) is bound to
+one of its pre-set values.
+
+Typically doc is returned if point is on a function-like name or
+in its arg list.
 
 Major modes should modify this hook locally, for example:
   (add-hook \\='eldoc-documentation-functions #\\='foo-mode-eldoc nil t)
@@ -351,30 +363,30 @@ eldoc-documentation-functions
 taken into account if the major mode specific function does not
 return any documentation.")
 
+(defun eldoc--handle-multiline (res)
+  "Helper for handling a bit of `eldoc-echo-area-use-multiline-p'."
+  (if eldoc-echo-area-use-multiline-p res
+    (truncate-string-to-width
+     res (1- (window-width (minibuffer-window))))))
+
 (defun eldoc-documentation-default ()
   "Show first doc string for item at point.
 Default value for `eldoc-documentation-function'."
-  (let ((res (run-hook-with-args-until-success 'eldoc-documentation-functions)))
-    (when res
-      (if eldoc-echo-area-use-multiline-p res
-        (truncate-string-to-width
-         res (1- (window-width (minibuffer-window))))))))
+  (run-hook-with-args-until-success 'eldoc-documentation-functions
+   eldoc--callback))
 
 (defun eldoc-documentation-compose ()
   "Show multiple doc string results at once.
 Meant as a value for `eldoc-documentation-function'."
-  (let (res)
-    (run-hook-wrapped
-     'eldoc-documentation-functions
-     (lambda (f)
-       (let ((str (funcall f)))
-         (when str (push str res))
-         nil)))
-    (when res
-      (setq res (mapconcat #'identity (nreverse res) ", "))
-      (if eldoc-echo-area-use-multiline-p res
-        (truncate-string-to-width
-         res (1- (window-width (minibuffer-window))))))))
+  (let ((res 0))
+    (run-hook-wrapped 'eldoc-documentation-functions
+                      (lambda (f)
+                        (let ((str (funcall f eldoc--callback)))
+                          (if (stringp str) (funcall eldoc--callback str)
+                            (when str (setq res (1+ res))))
+                          nil)))
+    ;; play ball with `eldoc-print-current-symbol-info'
+    (if (plusp res) (1- res) "")))
 
 (defcustom eldoc-documentation-function #'eldoc-documentation-default
   "Function to call to return doc string.
@@ -408,6 +420,11 @@ eldoc--supported-p
            ;; there's some eldoc support in the current buffer.
            (local-variable-p 'eldoc-documentation-function))))
 
+;; this variable should be unbound, but that confuses
+;; `describe-symbol' for some reason.
+(defvar eldoc--callback nil
+  "Dynamically bound.  Passed to  `eldoc-documentation-functions'.")
+
 (defun eldoc-print-current-symbol-info ()
   "Print the text produced by `eldoc-documentation-function'."
   ;; This is run from post-command-hook or some idle timer thing,
@@ -417,11 +434,43 @@ eldoc-print-current-symbol-info
         ;; Erase the last message if we won't display a new one.
         (when eldoc-last-message
           (eldoc-message nil))
-      (let ((non-essential t))
+      (let ((non-essential t)
+            (buffer (current-buffer)))
         ;; Only keep looking for the info as long as the user hasn't
         ;; requested our attention.  This also locally disables inhibit-quit.
         (while-no-input
-          (eldoc-message (funcall eldoc-documentation-function)))))))
+          (let* (;; `wanted' and `received' keep track of how many
+                 ;; docstrings we expect from the clients.  negative
+                 ;; `wanted' means store docstring for later but don't
+                 ;; message yet; likewise for a positive value, but we
+                 ;; decrease it by one.  Any other value (including 0)
+                 ;; means the next time the callback is called we're
+                 ;; composing and outputting whatever we got.
+                 (wanted -1) (received '())
+                 (eldoc--callback
+                  (lambda (string)
+                    (with-current-buffer buffer
+                      (cond ((and (numberp wanted) (not (zerop wanted)))
+                             (if (plusp wanted)
+                                 (setq wanted (1- wanted))) ; decf where art thou?
+                             (push string received))
+                            (wanted
+                             (unless (string= string "") (push string received))
+                             (setq wanted nil)
+                             (eldoc-message
+                              (eldoc--handle-multiline
+                               (mapconcat #'identity (nreverse received) ", "))))
+                            (t
+                             ;; For now, silently swallow anything the
+                             ;; client unexpectedly gives us
+                             )))))
+                 (res (funcall eldoc-documentation-function)))
+            (cond (;; we got a string, we should output immediately
+                   (stringp res) (setq wanted t) (funcall eldoc--callback res))
+                  (;; got something else, trust eldoc--callback will be called
+                   res           (setq wanted res))
+                  (;; got nil, clear the echo area
+                   t             (eldoc-message nil)))))))))
 
 ;; If the entire line cannot fit in the echo area, the symbol name may be
 ;; truncated or eliminated entirely from the output to make room for the
diff --git a/lisp/hexl.el b/lisp/hexl.el
index cf7118f208..38eca77e26 100644
--- a/lisp/hexl.el
+++ b/lisp/hexl.el
@@ -515,7 +515,7 @@ hexl-current-address
       (message "Current address is %d/0x%08x" hexl-address hexl-address))
     hexl-address))
 
-(defun hexl-print-current-point-info ()
+(defun hexl-print-current-point-info (&rest _ignored)
   "Return current hexl-address in string.
 This function is intended to be used as eldoc callback."
   (let ((addr (hexl-current-address)))
diff --git a/lisp/progmodes/cfengine.el b/lisp/progmodes/cfengine.el
index f25b3cb9e2..9a6d81ce06 100644
--- a/lisp/progmodes/cfengine.el
+++ b/lisp/progmodes/cfengine.el
@@ -1294,7 +1294,7 @@ cfengine3-make-syntax-cache
                           'symbols))
         syntax)))
 
-(defun cfengine3-documentation-function ()
+(defun cfengine3-documentation-function (&rest _ignored)
   "Document CFengine 3 functions around point.
 Intended as the value of `eldoc-documentation-function', which see.
 Use it by enabling `eldoc-mode'."
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index d37eb8c152..d7865a7319 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -1402,8 +1402,10 @@ elisp--eldoc-last-data
       or argument string for functions.
   2 - `function' if function args, `variable' if variable documentation.")
 
-(defun elisp-eldoc-documentation-function ()
-  "`eldoc-documentation-function' (which see) for Emacs Lisp."
+(defun elisp-eldoc-documentation-function (_ignored &rest _also-ignored)
+  "Contextual documentation function for Emacs Lisp.
+Intended to be placed in `eldoc-documentation-functions' (which
+see)."
   (let ((current-symbol (elisp--current-symbol))
 	(current-fnsym  (elisp--fnsym-in-current-sexp)))
     (cond ((null current-fnsym)
diff --git a/lisp/progmodes/octave.el b/lisp/progmodes/octave.el
index 352c1810d1..2cf305c404 100644
--- a/lisp/progmodes/octave.el
+++ b/lisp/progmodes/octave.el
@@ -1639,8 +1639,8 @@ octave-eldoc-function-signatures
                   (nreverse result)))))
   (cdr octave-eldoc-cache))
 
-(defun octave-eldoc-function ()
-  "A function for `eldoc-documentation-function' (which see)."
+(defun octave-eldoc-function (&rest _ignored)
+  "A function for `eldoc-documentation-functions' (which see)."
   (when (inferior-octave-process-live-p)
     (let* ((ppss (syntax-ppss))
            (paren-pos (cadr ppss))
diff --git a/lisp/progmodes/python.el b/lisp/progmodes/python.el
index 1ca9f01963..404a67ba9f 100644
--- a/lisp/progmodes/python.el
+++ b/lisp/progmodes/python.el
@@ -4571,7 +4571,7 @@ python-eldoc-function-timeout-permanent
   :type 'boolean
   :version "25.1")
 
-(defun python-eldoc-function ()
+(defun python-eldoc-function (&rest _ignored)
   "`eldoc-documentation-function' for Python.
 For this to work as best as possible you should call
 `python-shell-send-buffer' from time to time so context in
-- 
2.20.1


--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline;
 filename=0002-Reimplement-funcall-but-in-the-future.patch

From c039a4356fa363ef10b8320c3856eb3466eb32f9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Tue, 26 May 2020 19:38:08 +0100
Subject: [PATCH 2/2] Reimplement funcall, but in the future

* lisp/emacs-lisp/eldoc.el (eldoc-future, eldoc-future-set)
(eldoc-future-set-call):  New functions.
(eldoc-documentation-functions): Prepare for Stefan's genius
docstring.
(eldoc-documentation-default, eldoc-documentation-compose): Use
futuristic stuff.
---
 lisp/emacs-lisp/eldoc.el | 54 ++++++++++++++++++++++++++--------------
 1 file changed, 36 insertions(+), 18 deletions(-)

diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el
index fa36987014..e015076c4d 100644
--- a/lisp/emacs-lisp/eldoc.el
+++ b/lisp/emacs-lisp/eldoc.el
@@ -337,18 +337,32 @@ eldoc-display-message-no-interference-p
   (not (or executing-kbd-macro (bound-and-true-p edebug-active))))
 
 
+;;;; Futuristic interlude
+(cl-defstruct (eldoc-future
+               (:conc-name eldoc-future--)
+               (:constructor eldoc-future-make ())) ; become Yoda we?
+  "<WORLD CLASS DOCSTRING>"
+  (value 'eldoc-future--unset)
+  callback)
+
+(defun eldoc-future-set (f v)
+  "<WORLD CLASS DOCSTRING>"
+  (cl-assert (eq (eldoc-future--value f) 'eldoc-future--unset))
+  (setf (eldoc-future--value f) v)
+  (when (eldoc-future--callback f)
+    (funcall (eldoc-future--callback f) v)))
+
+(defun eldoc-future-set-callback (f c)
+  "<WORLD CLASS DOCSTRING>"
+  (cl-assert (null (eldoc-future--callback f)))
+  (setf (eldoc-future--callback f) c)
+  (unless (eq (eldoc-future--value f) 'eldoc-future--unset)
+    (funcall c (eldoc-future--value f))))
+
+
 (defvar eldoc-documentation-functions nil
   "Hook of functions that produce doc strings.
-Each hook function should accept at least one argument CALLBACK
-and decide whether to display a doc short string about the
-context around point.  If the decision and the doc string can be
-produced quickly, the hook function can ignore CALLBACK and
-immediately return the doc string, or nil if there's no doc
-appropriate for the context.  Otherwise, if its computation is
-expensive or can't be performed directly, the hook function
-should arrange for CALLBACK to be asynchronously called at a
-later time, passing it either nil or the desired doc string.  The
-hook function should then return a non-nil, non-string value.
+<WORLD CLASS DOCSTRING GOES HERE>
 
 Note that this hook is only in effect if the value of
 `eldoc-documentation-function' (notice the singular) is bound to
@@ -372,19 +386,23 @@ eldoc--handle-multiline
 (defun eldoc-documentation-default ()
   "Show first doc string for item at point.
 Default value for `eldoc-documentation-function'."
-  (run-hook-with-args-until-success 'eldoc-documentation-functions
-   eldoc--callback))
+  (let ((x (run-hook-with-args-until-success 'eldoc-documentation-functions)))
+    (if (eldoc-future-p x) (eldoc-future-set-callback x eldoc--callback)
+      x)))
 
 (defun eldoc-documentation-compose ()
   "Show multiple doc string results at once.
 Meant as a value for `eldoc-documentation-function'."
   (let ((res 0))
-    (run-hook-wrapped 'eldoc-documentation-functions
-                      (lambda (f)
-                        (let ((str (funcall f eldoc--callback)))
-                          (if (stringp str) (funcall eldoc--callback str)
-                            (when str (setq res (1+ res))))
-                          nil)))
+    (run-hook-wrapped
+     'eldoc-documentation-functions
+     (lambda (f)
+       (let ((x (funcall f)))
+         (cond ((stringp x) (funcall eldoc--callback x))
+               ((eldoc-future-p x)
+                (eldoc-future-set-callback x eldoc--callback)
+                (setq res (1+ res))))
+         nil)))
     ;; play ball with `eldoc-print-current-symbol-info'
     (if (plusp res) (1- res) "")))
 
-- 
2.20.1


--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 19:15:01 +0000
Resent-Message-ID: <handler.41531.B41531.15905204869099 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15905204869099
          (code B ref 41531); Tue, 26 May 2020 19:15:01 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 19:14:46 +0000
Received: from localhost ([127.0.0.1]:46390 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdf2E-0002Mh-3B
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 15:14:46 -0400
Received: from mail-wr1-f52.google.com ([209.85.221.52]:37948)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jdf28-0002MO-2l
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 15:14:44 -0400
Received: by mail-wr1-f52.google.com with SMTP id e1so21591948wrt.5
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 12:14:40 -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=wNUlAVh+byE4GVU7DSGyAc6JfvSwOICisVScZZ+D/Ic=;
 b=JArWoVfXjXSHiOnMZkj6GTHK3PKd78O8jHFeeo2JNOHgT+qWNspZUHGHdsAa/fXVUS
 hXWvu803rLSk98b/QXAVjaATNw/1MZc/FvLX3MU/uFhlnLTwxTUaWUsx5L/gagBat86B
 5tkwZAXnNKd5GCstJ+si+FPGPh+6VZUe0eFK4DenRtGRDHt3rdOog78akCRJ6PMhfkmB
 Pku4ZpeWAqQJ5gcdHVJtY6noVYCAkbfXzh6elSoPIxpobo/zgTWtZpiQ6r8l7dDYTUO0
 FfEweWGpY7bw0wgeqxfotM838wN2q33kJozhUai5bZMMQ07FNEI6fP32Hq97mAjOl40K
 DP4A==
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=wNUlAVh+byE4GVU7DSGyAc6JfvSwOICisVScZZ+D/Ic=;
 b=HUQKaUPb/2+R1R0LqchDqP+44rjvQruo9KTYNHyYgtQDnJKI71DW9dPGwbgimPjySm
 vVRhqtjFnraj69BSZYUVvos2Cd443C8PAtBOdejyZaisEdRVcOrK4f0z86lXllk9+iwy
 QWN9jySnpIBB1oIIFknZfCbIOAhBiz/jQe8vfBntq8EcQcUbxXaPTnCj3I6T4caq9dzI
 cpK+odtjjUxx0iCNH99zdwfisEscKOCr8Ng5PcuDJzz2II+Xfv75096eHClHuNcHP4qg
 lXRySFWu9R8fJgEtYPljurDwrRvOuXKkbBx8CT1suF0yLAYVIdubB2Hfj1rbCqsIkjSo
 g1gQ==
X-Gm-Message-State: AOAM531AoRZXZB7JzT9NpLuOpLr8r8drbDBdm3PsPCV2BDEFid4tDYfJ
 PPSx9rGBTSNKNg8gjLdXgYE=
X-Google-Smtp-Source: ABdhPJx5haLX+fJZhAV3cGu8tmmbs/ArxE/JIbRnyH4FrMFYN86Uqczk5O10kEcYJU4M6xs0kruaKg==
X-Received: by 2002:adf:f651:: with SMTP id x17mr22656210wrp.277.1590520474022; 
 Tue, 26 May 2020 12:14:34 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id w15sm399520wmi.35.2020.05.26.12.14.32
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 26 May 2020 12:14:33 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN>
 <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN>
Date: Tue, 26 May 2020 22:14:31 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <87ftbmr8d9.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
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: -0.5 (/)

On 26.05.2020 19:03, João Távora wrote:

>>> To simplify, hopefully you agree that your proposal can be summarized
>>> as:
>>>     "return a function that receives a function that you
>>>      should call with the docstring"
>>> whereas my proposal can be summarized as:
>>>     "receive a function that you should call with the docstring"
>>
>> To clarify, you actually included two proposals (behavior with patch
>> 1, and with both patch 1 and patch 2 applied). The first one is the
>> one I really didn't like. The second one is better, API-wise, but will
>> conflict with the futures-based approach.
> 
> It's not a conflict at all.  When you do the futures-based approach
> you're going to rewrite the docstring to augment the API.  You do the
> same here: just add this to the docstring:
> 
>     "If you prefer, ignore CALBACK and return a `future-future' object from
>      this function".
> 
> How is that different from:
> 
>     "If you prefer, instead of returning a (:ASYNC . FUNCTION) cons,
>     return a `future-future' object from this function""
> 
> ???

We're not going to do either. The :async option is only for those tho 
need async _right this second_. It would be fully replaced by the 
"futures" option. Or we can implement it right now.

And hopefully we won't have to maintain the eldoc-specific futures 
"forever" either.

>> BTW, maybe eldoc-message should handle this after all? Since it's the
>> last link in the chain. Or even do that in the default value of
>> eldoc-message-function (create a wrapper for minibuffer-message).
> 
> Doesn't work well becasue eldoc-message is called by both the produced
> _and_ the backend, as I showed you earlier.  And it certainly doesn't
> work with eldoc-documentation-compose.

We could split it apart, I guess. Or make two versions.

>>> Replying to parts from the other discussion in the Github tracker now.
>>>
>>>> OK, another question: if the result still /valid/?
>>>                           ^^ Assuming you mean "is".
>>> Well, if the client discovers the result to be invalid, ...
>>
>> So the client will have to save and then compare the current buffer,
>> the value of point and buffer-chars-modification-tick now?
> 
> Ah, _that_ validity.  No, no, never do that.  The client should have no
> idea of it.  In the framework you either make the callback a noop, or
> you set it aborted for the client to save some work.  Or both.

So the abort thing. In pre-command-hook?

>>>> No idea, a hypothetical one. It's an open API, not everybody is or
>>>> will be using LSP until the end of time. And it doesn't really have to
>>>> be huge. A saving is a saving.
>>> There's no free lunch.  A very small saving in time for more
>>> complexity
>>> is bad.  That's what overengineered means.
>>
>> Futures are not particularly more complex to use.
> 
> Sure, but they are _more_ complex.  And you're mixing up two things:
> futures _aren't_ the only way -- or even a particularly easy way -- to
> signal to the clients that thety can give up their efforts.  All the
> client needs to have is access to an object that's shared between it and
> the framework.  That object _needn't_ be a first-class CLOS object or
> struct.  It can be a function.

It's good to have a well-documented contract. Functions do _everything_. 
They can't be optimal for everything.

And this way we don't add extra arguments, so whoever doesn't need 
async, doesn't need to change a thing.

>>>> You can certainly kill the external process outside of it. Saving on
>>>> CPU expenses in general.
>>> The future's creditor is the only one who could do that to any
>>> useful
>>> effect.  Does it have access to the process?  Probably not.
>>
>> It can (barring any complex abstractions). It created the process,
>> after all.
> 
> Not really, it asked a client to solve a problem, doesn't know how the
> client if the client is doing by async process or cointoss.

Seems like we're miscommunicating.

>>> You would have to return a complex future with a kill switch.  That's
>>> possible, but tricky, because you'd then have to be ready in the
>>> sentinel for another source of unexpected kills.
>>
>> That would be none of ElDoc's business, though. But the implementation
>> will get to be as complex as it needs.
> 
> _That's_ why an abort switch whose contract is "kill this immediately"
> is a bad idea.  An abort switch whose contract is "just letting you know
> I don't need this anymore" is better.  But again, in eldoc, not so
> useful.  And again, nothing to do with futures here.

Here as well.

>>> Why indeed?  Your other argument, that this makes the transition to
>>> proper futures (such as the ones in https://github.com/skeeto/emacs-aio)
>>> easier, is questionable, too.  There are two scenarios here:
>>> - You want to keep backward compatibility to this API published in
>>> eldoc
>>>     1.1.0 until the time of the Emacs 28 release:
>>
>> The one thing I want to avoid doing is changing the callsig of every
>> documentation function, and then changing them back when we switch to
>> futures.
> 
> So _don't_ change the "callsig".  If you implement futures you _are_
> going to change the protocol anyway, i.e. write new stuff in the
> docstring.

See above about not having to change anything.

>>>     This is something that I -- and Stefan, if I'm not mistaken, -- don't
>>>     think we should worry about.  Just because a package is :core GNU ELPA
>>>     doesn't necessarily mean we guarantee stability of its API.
>>
>> Um, I'm pretty sure we guarantee a fair amount of stability.
> 
> That's not what Stefan said here:
> 
>     https://github.com/joaotavora/eglot/pull/459#issuecomment-633634034
> 
> And that's not what the Dmitry from 2016 wrote in xref.el
> 
>     +;; NOTE: The xref API is still experimental and can change in major,
>     +;; backward-incompatible ways.  Everyone is encouraged to try it, and
>     +;; report to us any problems or use cases we hadn't anticiated, by
>     +;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
> 
> That has been sitting there for almost three Emacs major versions (in
> fact you added it after the initial 25 release).  All I'm asking is for
> a little such flexibility with eldoc.

I wrote that for xref.el because that was the state of affairs, and xref 
was relatively new. Especially compared to eldoc.

But we're probably miscommunicating here as well.

>>>     But if we do, then we'll have to explain in the docstring that there
>>>     is a fourth return value for the hook functions.  In my version we'll
>>>     have to do exactly the same.
>>> - You don't want to keep backward compatibility until Emacs 28:
>>>     Then, when the super-futures are here, you can just kill the
>>> CALLBACK
>>>     arg if we find it doesn't fit and rewrite the docstring without
>>>     concerns.
>>
>> Kill the arg in all built-in functions, as well as in external
>> consumers?
> 
> Yes, if we discover there aren't so many.  Currently there are 5 users
> in Emacs proper, 0 in GNU ELPA and quite sure 0 elsewhere in the world.

OK, I see your point: eldoc-documentation-functions is new. And 
apparently you don't intend to add this feature to the variable without "s".

> It just looks like you're holding this problem hostage to introducing
> some kind of rushed futures solution.  I don't agree with either of
> these things.

Who's holding what hostage? I showed a smoother approach, you didn't 
like it. No big surprise about that.

> I think this particular problem shouldn't be held hostage
> to rearchitecting async in Emacs, laudable and useful a goal as that
> might be.  And I think a futures library should be well thought out: I'd
> like to discuss this in emacs-devel, at least get some opinions on
> Christopher Wellon's solution, which seems very elegant.

We should certainly take a look at it. But the built-in futures don't 
have to provide all the options. Just be functionally compatible. 
Christopher could pick up from that.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 26 May 2020 20:01:02 +0000
Resent-Message-ID: <handler.41531.B41531.159052325713204 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159052325713204
          (code B ref 41531); Tue, 26 May 2020 20:01:02 +0000
Received: (at 41531) by debbugs.gnu.org; 26 May 2020 20:00:57 +0000
Received: from localhost ([127.0.0.1]:46399 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jdfku-0003Qu-Sm
	for submit <at> debbugs.gnu.org; Tue, 26 May 2020 16:00:57 -0400
Received: from mail-wm1-f41.google.com ([209.85.128.41]:40678)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jdfkt-0003Qh-GK
 for 41531 <at> debbugs.gnu.org; Tue, 26 May 2020 16:00:56 -0400
Received: by mail-wm1-f41.google.com with SMTP id r15so817199wmh.5
 for <41531 <at> debbugs.gnu.org>; Tue, 26 May 2020 13:00:55 -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=65wzmJ4kjjeU7kCUFUtgkrtM8NVFnj72JMijcRB8Zf8=;
 b=kCsZ8DIMZFAgJY8V2IaQPFREYAEdn+IhPBlTi7/hqVuJnKXumJELc2oh8JHJtzifrN
 n6kWzT5tdrgNJyUutv9wipkBFBzR8gGx77uPFIhTvJ6QFpIs3R9moewemGIsrBpm9Fyt
 9s1Ry8896UFMXmIocciUfv4okrtG8d22uJ7AzW2CuWYpOj5zxAgwOV5+qpQt1fMsrDRM
 mCmi/AJZf7hq67IR8EdxZuFrevpL8usWDgljNRywElss789ncJ+tk9+Kkuf8ib7X8BQ3
 gOlmZ7P+yFMPlKhFfKGI4irlbB9cGxT/R/C1B1fzsDHU/fE5L0YUwJnLe0+mVxYlgL9V
 aLjw==
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=65wzmJ4kjjeU7kCUFUtgkrtM8NVFnj72JMijcRB8Zf8=;
 b=YHZMnulDNkWYnOy08a4PJjwo6fuGOknm/SB4yJQuN1+c58FNmAjTVfdJPfIP5bp3Ho
 DAkvsbexc7HJAda8qQppnn5A2yO7j9U1R9j4GvnSfa1DrTpk49wubvLJWZj5qnIlyeuN
 0TbNIPdKhtmjXDGtJB6hul/XuSyOmunv70+9kC1fvk67Jx9dSW3w2x2gz9h06nlIrMZg
 t96vHaiBCVCc6pkWdpImzTSnuKX2B3iQR0Sjuz2zSl0M/Xocqa4wTEbt/gDUDDxKvNcN
 D0GkNf1Mc2WMr0EAVDsHA49ntL+HMh+8zKot+yRey0y8MjAnknQGCxEyd3cniZZ7Bg5w
 xCVA==
X-Gm-Message-State: AOAM531sO/x2uOt5q5zYH+o0SLtfQOef4wio/XDQF7yySTE7DKMwrZ+l
 g//y9bmwUC+YJ4nsmpNNJD8=
X-Google-Smtp-Source: ABdhPJwYed0lXewX0Cse12zQ+mK6KP+Wc6FPf84Q7bZATDnSk+Hy5wNzxiMDvExcQflSNRknT18DPA==
X-Received: by 2002:a1c:7c0e:: with SMTP id x14mr751698wmc.1.1590523249276;
 Tue, 26 May 2020 13:00:49 -0700 (PDT)
Received: from krug (89-180-149-243.net.novis.pt. [89.180.149.243])
 by smtp.gmail.com with ESMTPSA id z132sm598398wmc.29.2020.05.26.13.00.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 26 May 2020 13:00:48 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <87k10zsd85.fsf@HIDDEN>
 <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN>
 <87ftbmr8d9.fsf@HIDDEN>
 <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN>
Date: Tue, 26 May 2020 21:00:47 +0100
In-Reply-To: <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> (Dmitry Gutov's
 message of "Tue, 26 May 2020 22:14:31 +0300")
Message-ID: <87tv02pits.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (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:

>> no idea of it.  In the framework you either make the callback a noop,
>> or you set it aborted for the client to save some work.  Or both.
>
> So the abort thing. In pre-command-hook?

No, the creditor of the future or issuer of the callback aborts or
invalidates the previous version just before issuing a new one.  Nothing
pre-command-hook here.  Invalidation may or may not entail letting the
holder of the callback know that the previous call became invalid.
Flymake does this: by invoking a backend again with a new callback
instance it is signalling that the preceding one became invalid.  If the
backend tries to call the previous callback, it is an error and the
backend is disabled.

> It's good to have a well-documented contract. Functions do
> _everything_. They can't be optimal for everything.

You're missing a Lisp point here.  It doesn't matter if it's an CLOS
object, a struct, a function or my beautiful singing voice: it just has
to be an object which you can make unique instances of and can respond
to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf
errored-p).  That's the contract.  A function fits perfectly.

>>>> The future's creditor is the only one who could do that to any
>>>> useful effect.  Does it have access to the process?  Probably not.
>>> It can (barring any complex abstractions). It created the process,
>>> after all.
>> Not really, it asked a client to solve a problem, doesn't know how
>> the client if the client is doing by async process or cointoss.
> Seems like we're miscommunicating.

Well you implied that the creditor of the future (the caller who
received) created the process.  It does not.  See the patch to Stefan.

>> is a bad idea.  An abort switch whose contract is "just letting you know
>> I don't need this anymore" is better.  But again, in eldoc, not so
>> useful.  And again, nothing to do with futures here.
>
> Here as well.

OK. The takeaway is that "aborting a future" doesn't need any constructs
specific to futures, is all.

> See above about not having to change anything.

But then we don't have to change anything in any case!  I already
changed EVERY user of eldoc-documentation-functions: every single one of
the 5 in existence in the entire world.  So we're all good.

>>     +;; NOTE: The xref API is still experimental and can change in
>> major,
>>     +;; backward-incompatible ways.  Everyone is encouraged to try it, a=
nd
>>     +;; report to us any problems or use cases we hadn't anticiated, by
>>     +;; sending an email to emacs-devel, or `M-x report-emacs-bug'.
>> That has been sitting there for almost three Emacs major versions
>> (in
>> fact you added it after the initial 25 release).  All I'm asking is for
>> a little such flexibility with eldoc.
>
> I wrote that for xref.el because that was the state of affairs, and
> xref was relatively new. Especially compared to eldoc.

This part of eldoc.el is probably newer than xref.el was when you wrote
that.

> But we're probably miscommunicating here as well.

Doubt it.

> OK, I see your point: eldoc-documentation-functions is new. And
> apparently you don't intend to add this feature to the variable
> without "s".

Yes, exactly.  eldoc-documentation-function should be obsoleted IMO.

>> It just looks like you're holding this problem hostage to introducing
>> some kind of rushed futures solution.  I don't agree with either of
>> these things.
>
> Who's holding what hostage? I showed a smoother approach, you didn't
> like it. No big surprise about that.

Let me explain. First: it's clearly not "smoother", your're asking users
to wrap their heads around a function that returns a function taking a
function.  That's not what I want to present to Eglot contributors, for
instance.  And I'm not too crazy with presenting them this "future
thing" that is completely different from Eglot's use of Flymake,
jsonrpc.el, completion-at-point, etc...  In other words, my ambition is
consistency and you seem to be denying it for reasons I can't
understand, because nothing in the steps I am taking denies _your_
ambitions, which seem to be futures.  That's why I speak of "hostage".

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 27 May 2020 21:15:02 +0000
Resent-Message-ID: <handler.41531.B41531.159061405021403 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159061405021403
          (code B ref 41531); Wed, 27 May 2020 21:15:02 +0000
Received: (at 41531) by debbugs.gnu.org; 27 May 2020 21:14:10 +0000
Received: from localhost ([127.0.0.1]:50132 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1je3NK-0005Z8-B8
	for submit <at> debbugs.gnu.org; Wed, 27 May 2020 17:14:10 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:39434)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1je3NI-0005Yu-G9
 for 41531 <at> debbugs.gnu.org; Wed, 27 May 2020 17:14:09 -0400
Received: by mail-wm1-f45.google.com with SMTP id k26so995325wmi.4
 for <41531 <at> debbugs.gnu.org>; Wed, 27 May 2020 14:14: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=ToU3oVOpgrnFc3ErbFYGXrSJMEfsfZtE5OOMHRZbsCA=;
 b=ZvDJRe8fD6O26Mhwi0llsBS1CIwvHNa2ti/QgdA2WsqyhB3lZmf0tlRbA2pTYxO8Fo
 nhEAh4DlbkTcT+JwlQJ3J07buAKHOjNYkYt9BptzNEFB5JHRqZmZYE+jQ/+XQ7Df7f18
 /PSm7JuW7SPEvdmWbt2MgTUnt74NqjVS0KWppTBjTjm0IpBSzhhMmu5+M0Vbvv4R7fM/
 J1UwaAT4yRNdPZyEX4msn54o4AIN5FUih8gEljWpr6kjT5J7JpyAFG6hG1KJRoNivu2V
 FFyPiLcCCxeH0r6LyUkb85Var6Xvnhomar65FEMF8bnE+sZBE7ZFZTuPQRF+BVEOI8p8
 5opA==
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=ToU3oVOpgrnFc3ErbFYGXrSJMEfsfZtE5OOMHRZbsCA=;
 b=mXvQqPZxBF1YUSSTW2PJjjZF36yXhEeUYMHFs/TqS+mbvTBujkosibWRLB56Ti3l9P
 5krqpyKRWv6S5E7myZYsIQ7hbisD+6NxapljXub0ho+EM1FVlv08ci6nw2s2i8xpcLgY
 rqPPCMrl0U7Gh0pgPZ+AO25OaN4/nsL/139OOFhEr2rbJNB5s4YE6ASBjzaGheC08x5q
 5F9SFdAZQiyz++cMk31knon6jc/RrVdwYnne9fOT1+RbADcMyoXrjCwhIwACpNXp9bTJ
 cssVl7bkdzA07rPqE2iFz+UaydUCd2s0rGXXeS3pFZBkth60+CtGLX2OTPN4U2ClM2a+
 n39Q==
X-Gm-Message-State: AOAM531aWUuwhBXGkX7kdu202kpssgZFxW/7p5wYC3nU6L9KWr9Q99FG
 ttoHBhSB6BgovmzcYINpxFE=
X-Google-Smtp-Source: ABdhPJydkmWNT4zstF310tG1jnryu3yOfMT8t+xsZwVg5rcp/n98dvlkPeirbokSs3GllSBDIkqAHA==
X-Received: by 2002:a1c:de46:: with SMTP id v67mr62188wmg.146.1590614042414;
 Wed, 27 May 2020 14:14:02 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id d4sm3766517wre.22.2020.05.27.14.14.00
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 May 2020 14:14:01 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN>
 <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN>
 <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> <87tv02pits.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN>
Date: Thu, 28 May 2020 00:14:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87tv02pits.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
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: -0.5 (/)

On 26.05.2020 23:00, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>>> no idea of it.  In the framework you either make the callback a noop,
>>> or you set it aborted for the client to save some work.  Or both.
>>
>> So the abort thing. In pre-command-hook?
> 
> No, the creditor of the future or issuer of the callback aborts or
> invalidates the previous version just before issuing a new one. Nothing
> pre-command-hook here.

Where/when would eldoc-mode do it?

> Invalidation may or may not entail letting the
> holder of the callback know that the previous call became invalid.

Letting know the issuer of the future, you mean.

> Flymake does this: by invoking a backend again with a new callback
> instance it is signalling that the preceding one became invalid.  If the
> backend tries to call the previous callback, it is an error and the
> backend is disabled.

Worse is sometimes better, we know.

>> It's good to have a well-documented contract. Functions do
>> _everything_. They can't be optimal for everything.
> 
> You're missing a Lisp point here.  It doesn't matter if it's an CLOS
> object, a struct, a function or my beautiful singing voice: it just has
> to be an object which you can make unique instances of and can respond
> to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf
> errored-p).  That's the contract.  A function fits perfectly.

That would be my "alternative" suggestion: for 
eldoc-documentation-functions elements to return a function (denoted as 
FETCHER in the docstring) if they want the async convention.

>>>>> The future's creditor is the only one who could do that to any
>>>>> useful effect.  Does it have access to the process?  Probably not.
>>>> It can (barring any complex abstractions). It created the process,
>>>> after all.
>>> Not really, it asked a client to solve a problem, doesn't know how
>>> the client if the client is doing by async process or cointoss.
>> Seems like we're miscommunicating.
> 
> Well you implied that the creditor of the future (the caller who
> received) created the process.  It does not.  See the patch to Stefan.

Okay, creditor != creator. But what you've said a few messages back 
(seen at the top of the quotes chain above) doesn't make sense: the 
creditor will call (future-abort fut), and the issuer of the future can 
make sure that this operation will indeed kill the process.

That's the main idea behind aborting futures. Or canceling. Whatever 
term we're going to pick.

>> See above about not having to change anything.
> 
> But then we don't have to change anything in any case!  I already
> changed EVERY user of eldoc-documentation-functions: every single one of
> the 5 in existence in the entire world.  So we're all good.

And then we'll need to change them back. And in the meantime, the new 
convention could get external users (some people do live on the bleeding 
edge), and this will get messier.

>> OK, I see your point: eldoc-documentation-functions is new. And
>> apparently you don't intend to add this feature to the variable
>> without "s".
> 
> Yes, exactly.  eldoc-documentation-function should be obsoleted IMO.

Perhaps. I'm also not buying the usefulness of eldoc-documentation-compose.

>>> It just looks like you're holding this problem hostage to introducing
>>> some kind of rushed futures solution.  I don't agree with either of
>>> these things.
>>
>> Who's holding what hostage? I showed a smoother approach, you didn't
>> like it. No big surprise about that.
> 
> Let me explain. First: it's clearly not "smoother", your're asking users
> to wrap their heads around a function that returns a function taking a
> function.  That's not what I want to present to Eglot contributors, for
> instance.

Would they need to? As soon as an existing Eglot's implementation is in 
place, that exact part of the code wouldn't need to be touched often.

In any case, you are over-exaggerating. This exact design has been a 
part of "asynchronous" backend calling convention in Company for years. 
And not once have I seen a complaint that it's overly complex.

> And I'm not too crazy with presenting them this "future
> thing" that is completely different from Eglot's use of Flymake,
> jsonrpc.el, completion-at-point, etc...

Didn't you say that Flymake could use futures as well?

> In other words, my ambition is
> consistency and you seem to be denying it for reasons I can't
> understand, because nothing in the steps I am taking denies _your_
> ambitions, which seem to be futures.  That's why I speak of "hostage".

See above. But perhaps we should after all suspend this discussion until 
we had a chance to reach a better mutual understanding of the futures 
API, and how we expect it to help (or not). I promise to show some 
proposals in the near future.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 27 May 2020 22:14:02 +0000
Resent-Message-ID: <handler.41531.B41531.159061760211146 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159061760211146
          (code B ref 41531); Wed, 27 May 2020 22:14:02 +0000
Received: (at 41531) by debbugs.gnu.org; 27 May 2020 22:13:22 +0000
Received: from localhost ([127.0.0.1]:50237 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1je4Ib-0002th-UM
	for submit <at> debbugs.gnu.org; Wed, 27 May 2020 18:13:22 -0400
Received: from mail-io1-f66.google.com ([209.85.166.66]:44509)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1je4IZ-0002tU-Q9
 for 41531 <at> debbugs.gnu.org; Wed, 27 May 2020 18:13:20 -0400
Received: by mail-io1-f66.google.com with SMTP id p20so14424422iop.11
 for <41531 <at> debbugs.gnu.org>; Wed, 27 May 2020 15:13:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=LwrfUoDvfE+n2dkcmKuNsC5pty6sxSvmNzbwjulIRqY=;
 b=N4OQBEHn1eb5Abid5nnsoqvgIBwWNgyCd5u9ixijX3fIELEGPxIOfGEY5fylm9ZJ2b
 jKiFs7MYXIoKmGKb8xnSAbAywaAHt1buGKAhxTdWFR/mEcuNvizAbcwntp+znlMl1zYW
 M1AljRvxYolOCpUyYTYTz4ClZlcDo78vpZIW0N9HhhLmOiyRs9Nqwb3D67GSwnj/N6qt
 ttnBkC/netHaupbeKDGRoTxG+PipzXW6ZKOYyPA+dRKkXWryA853v8zV9P8OQR/iRmO4
 6VRTlX9mYBmjY6kE+prSHlbBp00o3uY0SB+QX8dQwyfDBA6K1rJysUglAa8/XDnrcr4c
 F0ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=LwrfUoDvfE+n2dkcmKuNsC5pty6sxSvmNzbwjulIRqY=;
 b=aTB5TaIpTpQfBQcdwjbGrJk0YFYTa/hdOSHv1QUXDN7DsN52fmijt0t9JnVwDiYbCg
 TM/5JwfJvQG3WlsukRG98fucBnXfbkQTSlT1CgCuWlXocrPAdKEgRXinlIGJE+nuta7b
 2soCOUOQNlCgMK861+eTS/drdbtPm2fNgtbX5uJYdCjrkAoCjnUJQU09DQcHelG4yvMY
 ICetSj1BRtW0hzOBDZSi/w5lKOczLiGS9Ry/TSERwV6YZOAG1wHU0Q8CZKMyANZokQpT
 822h33VdCKGAqW4gffPknIY5NBsXsyfG5TCY0wJWQtzMWfJUf3sxrgwygfbm6WRLcJQY
 oROA==
X-Gm-Message-State: AOAM5336eR7fyRPEZU0BL2/8n2rqpspp1I94tPp/xbCakR+ITmbif4X4
 SPWV8aqXCfRKIBp9jYpKqqnvdeUtkErY2el80fw=
X-Google-Smtp-Source: ABdhPJyUofjkipzHaGZVSySR1k97DYZibO85DIbvTHtEUvlYuj+d8BPT7grOm66Rk0sFOT8d9Qxde37EoHqtPexh2QE=
X-Received: by 2002:a6b:6818:: with SMTP id d24mr63731ioc.57.1590617593970;
 Wed, 27 May 2020 15:13:13 -0700 (PDT)
MIME-Version: 1.0
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <87k10zsd85.fsf@HIDDEN> <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN>
 <87ftbmr8d9.fsf@HIDDEN> <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN>
 <87tv02pits.fsf@HIDDEN> <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN>
In-Reply-To: <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Wed, 27 May 2020 23:13:02 +0100
Message-ID: <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@HIDDEN>
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 (-)

On Wed, May 27, 2020 at 10:14 PM Dmitry Gutov <dgutov@HIDDEN> wrote:
> > No, the creditor of the future or issuer of the callback aborts or
> > invalidates the previous version just before issuing a new one. Nothing
> > pre-command-hook here.
>
> Where/when would eldoc-mode do it?

In the idle timer function.  That's when it decides it wants
new info, and so any old info that hasn't arrived yet is probably
out of date.

But I think I understnad what you mean pre-command-hook.
You suggested pre-command-hook because that's where you
can check if point is far enough away from the place where
the original request originated?  That could work, but I'd prefer
that the info to _do_ come in, because after that info is about
the  last time my point hung out at a particular position long
enough to trigger a request.  This is how Eglot, SLY and
SLIME work, btw.

> > Invalidation may or may not entail letting the
> > holder of the callback know that the previous call became invalid.
>
> Letting know the issuer of the future, you mean.

Or the holder of the callback depending on which abstraction
we're talking about.  I define the holder of the callback as
he who is about to call it.

> > Flymake does this: by invoking a backend again with a new callback
> > instance it is signalling that the preceding one became invalid.  If th=
e
> > backend tries to call the previous callback, it is an error and the
> > backend is disabled.
>
> Worse is sometimes better, we know.

That is a very confusing statement.

> >> It's good to have a well-documented contract. Functions do
> >> _everything_. They can't be optimal for everything.
> >
> > You're missing a Lisp point here.  It doesn't matter if it's an CLOS
> > object, a struct, a function or my beautiful singing voice: it just has
> > to be an object which you can make unique instances of and can respond
> > to funcall, still-wanted-p, (setf still-wanted-p), errored-p, and (setf
> > errored-p).  That's the contract.  A function fits perfectly.
>
> That would be my "alternative" suggestion: for
> eldoc-documentation-functions elements to return a function (denoted as
> FETCHER in the docstring) if they want the async convention.

They need to _receive_ an object produced externally, somhow.
If they return a function as youv suggest, they are only doing so
they can later _receive_ another object.  This is needlessly
complicated.  To receive objects in some place, just use argument
the argument list of that place.
>
> >>>>> The future's creditor is the only one who could do that to any
> >>>>> useful effect.  Does it have access to the process?  Probably not.
> >>>> It can (barring any complex abstractions). It created the process,
> >>>> after all.
> >>> Not really, it asked a client to solve a problem, doesn't know how
> >>> the client if the client is doing by async process or cointoss.
> >> Seems like we're miscommunicating.
> >
> > Well you implied that the creditor of the future (the caller who
> > received) created the process.  It does not.  See the patch to Stefan.
>
> Okay, creditor !=3D creator. But what you've said a few messages back
> (seen at the top of the quotes chain above) doesn't make sense: the
> creditor will call (future-abort fut), and the issuer of the future can
> make sure that this operation will indeed kill the process.

No, it does make sense. Read it again. What you're saying is what I
meant. But that still means that the process sentinel will have to deal
with out-of-band kills that it must distinguish from other out-of-band
kills (such as, say, a kill -9 from the shell). That is added complexity.

It is better, in my opinion, to make this softer.  Let the creditor
signal, I don't need this anymore, and the issuer will take appropriate
measures synchronously, i.e. in the process filter and not in the
process sentinel.

> That's the main idea behind aborting futures. Or canceling. Whatever
> term we're going to pick.

But, again, nothing you're describing here can't be implemented
with passing a callback in the arglist. It's independent.  Futures
particularly the versions you and Stefan are proposing are just
other places to type basically the same sexps.  They're a stylistic
change over callbacks, but nothing more, fundamentally.

> >> See above about not having to change anything.
> >
> > But then we don't have to change anything in any case!  I already
> > changed EVERY user of eldoc-documentation-functions: every single one o=
f
> > the 5 in existence in the entire world.  So we're all good.
>
> And then we'll need to change them back.

Nothing of the sort.

> And in the meantime, the new
> convention could get external users (some people do live on the bleeding
> edge), and this will get messier.

That's only if you assume you'll break compatibility, because you
dislike callbacks so much that you want to close off the arglist
forever.  But not only may users may not dislike them, they may
even prefer them. And keeping the arglist open, not closed, is a
very good idea for extensibility functional API's anyway.

> >> OK, I see your point: eldoc-documentation-functions is new. And
> >> apparently you don't intend to add this feature to the variable
> >> without "s".
> >
> > Yes, exactly.  eldoc-documentation-function should be obsoleted IMO.
>
> Perhaps. I'm also not buying the usefulness of eldoc-documentation-compos=
e.

Yeah,I don't get it particularly, either.  I mean, I can see its uses.
but I'm glad you're finally getting the overengineered feeling :-)
And it's waay more useful than futures here.

> >>> It just looks like you're holding this problem hostage to introducing
> >>> some kind of rushed futures solution.  I don't agree with either of
> >>> these things.
> >>
> >> Who's holding what hostage? I showed a smoother approach, you didn't
> >> like it. No big surprise about that.
> >
> > Let me explain. First: it's clearly not "smoother", your're asking user=
s
> > to wrap their heads around a function that returns a function taking a
> > function.  That's not what I want to present to Eglot contributors, for
> > instance.
>
> Would they need to? As soon as an existing Eglot's implementation is in
> place, that exact part of the code wouldn't need to be touched often.

Code is read much, much more than is is written.  And WTF per minute
_are_ a measure of code quality.  I would like to avoid this particular
WTF please.

> In any case, you are over-exaggerating. This exact design has been a

"over-exaggerating".  Very meta.

> part of "asynchronous" backend calling convention in Company for years.

People will use what you give them, if you they have no other option.

> And not once have I seen a complaint that it's overly complex.

Anyway, count one now.  Or don't.  I mean, I really dislike
company-backends throughout, but I don't use it, either. I mean
I know you inherited it and I had to hack on it to add flex support
for the capf thing, but it's a strange re-implementation of functions
to have one single function that does wildly different things based
on one argument.   I guess at the time there weren't generic
functions. And the cons :async thing is equally confusing to me.
Sorry to be frank. But I guess some people will love it, for some
equally legitimate reason: it will seem "right" to them, or "clever".

> > And I'm not too crazy with presenting them this "future
> > thing" that is completely different from Eglot's use of Flymake,
> > jsonrpc.el, completion-at-point, etc...
>
> Didn't you say that Flymake could use futures as well?

It could, sure, especially if you have a thousand futuristic devs
itching to write backends but not grokking callbacks.  But let's
not kill the existing API, please.

> > In other words, my ambition is
> > consistency and you seem to be denying it for reasons I can't
> > understand, because nothing in the steps I am taking denies _your_
> > ambitions, which seem to be futures.  That's why I speak of "hostage".
>
> See above. But perhaps we should after all suspend this discussion until
> we had a chance to reach a better mutual understanding of the futures
> API, and how we expect it to help (or not). I promise to show some
> proposals in the near future.

Suspend this discussion?  Sure, this discussion yes, if your want.
But not this bugfix: that would be exactly what "holding hostage"
means. Don't hold this bugfix hostage: it has nothing to do with
futures.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 27 May 2020 23:36:02 +0000
Resent-Message-ID: <handler.41531.B41531.159062254627188 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159062254627188
          (code B ref 41531); Wed, 27 May 2020 23:36:02 +0000
Received: (at 41531) by debbugs.gnu.org; 27 May 2020 23:35:46 +0000
Received: from localhost ([127.0.0.1]:50316 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1je5aL-00074R-Js
	for submit <at> debbugs.gnu.org; Wed, 27 May 2020 19:35:46 -0400
Received: from mail-wm1-f46.google.com ([209.85.128.46]:50362)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1je5aK-00074F-An
 for 41531 <at> debbugs.gnu.org; Wed, 27 May 2020 19:35:45 -0400
Received: by mail-wm1-f46.google.com with SMTP id v19so1361443wmj.0
 for <41531 <at> debbugs.gnu.org>; Wed, 27 May 2020 16:35:44 -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=R5S9j4wWBT0hiIP+jN0OM7D04Jr1lwwSHN/mgxgqvUo=;
 b=j2OkaFNijkVVdjev9FzMqMb7hs2ZVfbJg/h7fRjcj9JqTOikJFtmhJ3uXMELQu+7fH
 siw26Pc3qp2rhxgOtgmFI75yF+sDN2VQ1ceJjv9Nsj2UgMd63j8eHTNNVoDMfP5Se7hO
 h0/cJS9+zSafVLZJFtV+5IrhZImQp9VqBLPfqUuSRxCaR/9Pm5St6QSqpPGoRfV2aG24
 Cdfclq3hBXaBDnyNRn9jveTvO/sZF4WLiVjeKfGWvorBE6iHjnzhWWpS3xxKy1agOCFk
 rA8lK585xC6yTYBvVCbj3ikv0XUM6UVkr3eU8TVS+f+1ulZHrEMgE8+8fgIvTWMsKoZi
 iN5A==
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=R5S9j4wWBT0hiIP+jN0OM7D04Jr1lwwSHN/mgxgqvUo=;
 b=JGW9ZbFxth6VqTpgvh/6+d6z/cDZy6dVbM5y/7uHcowBcZgIZwClBrg3AKd71njUIP
 7c4ZhVg80q6aaY3fOSG0Ab6/cxQGoPrLp9qHGWBLpOU8k2jmFDOtHXtL/0eFa5/QVNjl
 ynCeA0bkHfoyNOZ4mxnNab34nwBPKkFvop+zIYoOEPrePeBvmPMo642QOWLbvUcMqF6t
 hVJeYJ7M2gpgoHTIeE8crl8MAC9xjGRhJIq7UZJqT37rOcwfjbbKzBBMEb9ExAL1+9tM
 BiVErC5oiQn0XIRd7HkcDPwMGupckRhDYF9JUWvo8u2hqxj6snyrOBgkhsVgfdVKnWku
 9qsQ==
X-Gm-Message-State: AOAM531TRzEeuCyPp/4dc3yNuRHf7d+vyIyJ6sUeJBuLCV67M7P5l5m9
 VG6FqaerBO42XjG30jXVvYM=
X-Google-Smtp-Source: ABdhPJxPRxdVJxWlHIciIgUWgLqss+UhywQG7ESVaTIpfcmfTylhWNg35q2oHsG3wpb+oA73CCQpLg==
X-Received: by 2002:a1c:1983:: with SMTP id 125mr462202wmz.43.1590622538223;
 Wed, 27 May 2020 16:35:38 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id s2sm4017811wmh.11.2020.05.27.16.35.36
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 27 May 2020 16:35:37 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN> <87k10zsd85.fsf@HIDDEN>
 <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN> <87ftbmr8d9.fsf@HIDDEN>
 <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN> <87tv02pits.fsf@HIDDEN>
 <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN>
 <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <919188b1-154a-668a-7b0a-82fb96121c9e@HIDDEN>
Date: Thu, 28 May 2020 02:35:36 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
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: -0.5 (/)

On 28.05.2020 01:13, João Távora wrote:
> On Wed, May 27, 2020 at 10:14 PM Dmitry Gutov <dgutov@HIDDEN> wrote:
>>> No, the creditor of the future or issuer of the callback aborts or
>>> invalidates the previous version just before issuing a new one. Nothing
>>> pre-command-hook here.
>>
>> Where/when would eldoc-mode do it?
> 
> In the idle timer function.  That's when it decides it wants
> new info, and so any old info that hasn't arrived yet is probably
> out of date.

Then eldoc might shows some info when it's no longer pertaining to the 
context around the point.

> But I think I understnad what you mean pre-command-hook.
> You suggested pre-command-hook because that's where you
> can check if point is far enough away from the place where
> the original request originated?

Or always abort, as soon as the user invokes the next command.

>>> Flymake does this: by invoking a backend again with a new callback
>>> instance it is signalling that the preceding one became invalid.  If the
>>> backend tries to call the previous callback, it is an error and the
>>> backend is disabled.
>>
>> Worse is sometimes better, we know.
> 
> That is a very confusing statement.

It's a somewhat incorrect behavior that is, however, easier to implement.

Which is fully along the lines of Richard P. Gabriel's "The Rise of 
Worse Is Better".

>> That would be my "alternative" suggestion: for
>> eldoc-documentation-functions elements to return a function (denoted as
>> FETCHER in the docstring) if they want the async convention.
> 
> They need to _receive_ an object produced externally, somhow.
> If they return a function as youv suggest, they are only doing so
> they can later _receive_ another object.  This is needlessly
> complicated.  To receive objects in some place, just use argument
> the argument list of that place.

"Returning a value" is meaningful semantic. Even when that value is a 
function.

>> Okay, creditor != creator. But what you've said a few messages back
>> (seen at the top of the quotes chain above) doesn't make sense: the
>> creditor will call (future-abort fut), and the issuer of the future can
>> make sure that this operation will indeed kill the process.
> 
> No, it does make sense. Read it again. What you're saying is what I
> meant.

Perhaps you could have agreed then.

> But that still means that the process sentinel will have to deal
> with out-of-band kills that it must distinguish from other out-of-band
> kills (such as, say, a kill -9 from the shell). That is added complexity.

It's their choice. Some processes might run too long in certain cases. 
So that would be a safeguard.

> It is better, in my opinion, to make this softer.  Let the creditor
> signal, I don't need this anymore, and the issuer will take appropriate
> measures synchronously, i.e. in the process filter and not in the
> process sentinel.

Either way, that would require an additional way to signal. Try to fit 
this into your proposal. It won't match so well.

>> That's the main idea behind aborting futures. Or canceling. Whatever
>> term we're going to pick.
> 
> But, again, nothing you're describing here can't be implemented
> with passing a callback in the arglist. It's independent.  Futures
> particularly the versions you and Stefan are proposing are just
> other places to type basically the same sexps.  They're a stylistic
> change over callbacks, but nothing more, fundamentally.

Hence my request to wait a little.

Stefan suggested the simplest version because it both fits your current 
requirements, and it can be extended without breaking that usage.

>> Perhaps. I'm also not buying the usefulness of eldoc-documentation-compose.
> 
> Yeah,I don't get it particularly, either.  I mean, I can see its uses.
> but I'm glad you're finally getting the overengineered feeling :-)

No "finally", that was my opinion of it from the outset.

> And it's waay more useful than futures here.

Way to extend the bridge and then kick it down.

>> Would they need to? As soon as an existing Eglot's implementation is in
>> place, that exact part of the code wouldn't need to be touched often.
> 
> Code is read much, much more than is is written.  And WTF per minute
> _are_ a measure of code quality.  I would like to avoid this particular
> WTF please.

Okay, here's another argument: "Promise", or a "Future", or "Deferred" 
or whatever, are common notions across many programming languages now.

When a programmer encounters an idea familiar to them, they understand a 
program more easily. No WTFs.

>> In any case, you are over-exaggerating. This exact design has been a
> 
> "over-exaggerating".  Very meta.

Plain English.

>> And not once have I seen a complaint that it's overly complex.
> 
> Anyway, count one now.  Or don't.  I mean, I really dislike
> company-backends throughout, but I don't use it, either.

Noted.

> I mean
> I know you inherited it and I had to hack on it to add flex support
> for the capf thing, but it's a strange re-implementation of functions
> to have one single function that does wildly different things based
> on one argument.   I guess at the time there weren't generic
> functions. And the cons :async thing is equally confusing to me.
> Sorry to be frank. But I guess some people will love it, for some
> equally legitimate reason: it will seem "right" to them, or "clever".

It's very simple. Much simpler than generic functions or c-a-p-f.

So I'm surprised to see you disparage both ideas (one simpler than what 
you do, another a tiny bit more complex) as complex and outlandish.

>> Didn't you say that Flymake could use futures as well?
> 
> It could, sure, especially if you have a thousand futuristic devs
> itching to write backends but not grokking callbacks.  But let's
> not kill the existing API, please.

Probably not. Unless we find a good use in it for the extra capabilities 
provided by futures.

> Suspend this discussion?  Sure, this discussion yes, if your want.
> But not this bugfix: that would be exactly what "holding hostage"
> means. Don't hold this bugfix hostage: it has nothing to do with
> futures.

It's a new feature, not a bugfix.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 27 May 2020 23:59:02 +0000
Resent-Message-ID: <handler.41531.B41531.159062390029204 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159062390029204
          (code B ref 41531); Wed, 27 May 2020 23:59:02 +0000
Received: (at 41531) by debbugs.gnu.org; 27 May 2020 23:58:20 +0000
Received: from localhost ([127.0.0.1]:50336 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1je5wB-0007ay-VZ
	for submit <at> debbugs.gnu.org; Wed, 27 May 2020 19:58:20 -0400
Received: from mail-io1-f53.google.com ([209.85.166.53]:36582)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1je5w6-0007af-DZ
 for 41531 <at> debbugs.gnu.org; Wed, 27 May 2020 19:58:18 -0400
Received: by mail-io1-f53.google.com with SMTP id y18so7634558iow.3
 for <41531 <at> debbugs.gnu.org>; Wed, 27 May 2020 16:58:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=4ZisIWOGePaVkPJtqrM6MtOFQis99I73k2d/arP9AKk=;
 b=IqzgYZdLViTOVxwwlvExT3TIRk0ppj9euM28JIr0rqBLhjbS1l4bQqlvQuIX1PjlqP
 ULV+CYg1Thkg8Un8dOfGYvTnHFDCRuWONqGmN067KER8Ckv0vf3fig545+nint7rbO0y
 HyTvz3iaswy/sDVJR8YSoBHEG2OxdEbCIhEl9lCIv/nheW8U4NJVeU/60x/Lf5N1amJZ
 EZMlLMfZQIyRFI0S2Xq0FiAEDYq//7ySAs8pry9EaC1RjaqMrrmZ5UhDyoHuep1wpsuH
 /4nC/EblqvEpuQxeZjgUgqXuK91mfbin7JHeGRmFne7TWhHkF/MMb5XLLL8Z3cMmNV7S
 usKA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=4ZisIWOGePaVkPJtqrM6MtOFQis99I73k2d/arP9AKk=;
 b=DLqw6trWnHB6yeG+fIEBFGfK5Smne9e163urKV4YDSgZ+Ph2GcqpaHXK8cn6qCNt8s
 bYec4JIzLEUQ89Zyjer5VhHMzML1NOXL/dBHqOYSMQrSAXDbnrIiCOIJxr6jSnoGmrNF
 VbKkusHhiWrZV8y2Lpn4WpnPDxw/OnQonUrXhBF4KtHRtuWlGviXqk0ozOVe9WyXIDTn
 9C3qfw2ziQaFc5vLABcqMd6eB3HFzi3WaLZKXZIyZMRGLmNBMsaGB1DkY7yHxT/EG4Ov
 PMjWxiSzXwZJS6wTy4Kr8Jq9kS9arKk/8tQ5A9k+0nPOWWADLLkyycGDZ0g94fFJGsBM
 uRxA==
X-Gm-Message-State: AOAM530wDK9DvVLt4hTyYhksFLvn/3mjQXUxHDaa0xvpUshTh3K4kAQK
 4nPvixSf19TPIjNn59hlCi4UtzuSR8mARKp+l5E=
X-Google-Smtp-Source: ABdhPJySypImtBw2v1DvVkVl44dbzs9eBTxpsDJ6GOKTmTmd5lLCIjla5mTAMb94SSZKx8sgFQDW35Oc0Vv2ubN4onw=
X-Received: by 2002:a6b:6818:: with SMTP id d24mr341223ioc.57.1590623888644;
 Wed, 27 May 2020 16:58:08 -0700 (PDT)
MIME-Version: 1.0
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <87k10zsd85.fsf@HIDDEN> <384e543b-61fd-fe10-605c-b511499ecec2@HIDDEN>
 <87ftbmr8d9.fsf@HIDDEN> <8a1901d4-d8f1-ff45-ee2c-57e6770755bc@HIDDEN>
 <87tv02pits.fsf@HIDDEN> <31721651-6c51-8c34-22cf-f68c0269016a@HIDDEN>
 <CALDnm53mBbnxr6gd2P97mOo2zMvHNOUYKa1y-Qm6PbL340_2aw@HIDDEN>
 <919188b1-154a-668a-7b0a-82fb96121c9e@HIDDEN>
In-Reply-To: <919188b1-154a-668a-7b0a-82fb96121c9e@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Thu, 28 May 2020 00:57:56 +0100
Message-ID: <CALDnm53tkR-mm=6frJh9nq8_=7vAvMbC2ehc4oC4D_pDy5h+mg@HIDDEN>
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 (-)

On Thu, May 28, 2020 at 12:35 AM Dmitry Gutov <dgutov@HIDDEN> wrote:

> It's a somewhat incorrect behavior that is, however, easier to implement.

In the futures, how would you prevent a client from giving you
a stale future? You have the very same problem. Callbacks
aren't "easier" to implement than futures, either.  I'm not saying
they are "superior", as you seem to be pretending with futures,
They just happen to be the style that's most used in Emacs.

Futures are really good when you bring in continuations:
i.e. functions that can halt and resume their processing, so
you can write normally, as if there was no async, but still have
it happen automatically. But that requires an evaluator, which
is what generator.el does, and that's what enables proper
futures like the ones in emacs-aio. Anything other than
that is just moving objects and funcalls around, for style
(or lack thereof, to some people)

> Either way, that would require an additional way to signal. Try to fit
> this into your proposal. It won't match so well.

I've already shown you're mistaken.

> > Suspend this discussion?  Sure, this discussion yes, if your want.
> > But not this bugfix: that would be exactly what "holding hostage"
> > means. Don't hold this bugfix hostage: it has nothing to do with
> > futures.
>
> It's a new feature, not a bugfix.

No it's not.  Async clients are using internal functions.
eldoc-message is an internal function. eldoc is broken
for async clients, always has been. You know this, of
course. I worked on a fix and your're holding it up because
of a longing for an abstraction that you kinda like but
are still having doubts about.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 03 Jun 2020 02:46:02 +0000
Resent-Message-ID: <handler.41531.B41531.159115235332559 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159115235332559
          (code B ref 41531); Wed, 03 Jun 2020 02:46:02 +0000
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 02:45:53 +0000
Received: from localhost ([127.0.0.1]:41543 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgJPc-0008T5-NM
	for submit <at> debbugs.gnu.org; Tue, 02 Jun 2020 22:45:52 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64798)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jgJPa-0008Sr-H6
 for 41531 <at> debbugs.gnu.org; Tue, 02 Jun 2020 22:45:51 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id CF62E10050D;
 Tue,  2 Jun 2020 22:45:44 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1C3A51001CB;
 Tue,  2 Jun 2020 22:45:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1591152343;
 bh=tRAT4wE/oz9Jtp50xzy2iH1Ts+ixAfEdB++6xP6C/BA=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=DYDnGwGme8tfoS01TspSPm+HuQDevgPDdrvMS1IYF2/9PjMJ6XjO66rd6bRrs0n0g
 DdZgp+I2hK7rYXG/I6mzSLV+USWlz5W+bAAZgggz1lBnMD+5cgroRwC3HVmDFle+46
 IlJqgEiNF86nASphjeBUCGkLw5iYJZBmb+6hZtY72WbUpqanvXnogl2kl6emxDwV7U
 kuiolMGyuEuJGoLode2LXOnWt04JvWWN/MOsv+vVgIhGnMwU7Gmw2rxOq3ifvzqwiz
 nAPPY/oBD9cEamuWQ9LRfdGiE15pzz3GZr8qE1dM2Y50YVmCJiIwgvT1d4X9V2cZ/r
 TZXZ7S6IYgA9A==
Received: from alfajor (76-10-137-254.dsl.teksavvy.com [76.10.137.254])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A6CEB120328;
 Tue,  2 Jun 2020 22:45:42 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
 <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
Date: Tue, 02 Jun 2020 22:45:42 -0400
In-Reply-To: <871rn6r0pr.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 26
 May 2020 19:49:04 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.002 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

> --- a/lisp/emacs-lisp/eldoc.el
> +++ b/lisp/emacs-lisp/eldoc.el
> @@ -337,18 +337,32 @@ eldoc-display-message-no-interference-p
>    (not (or executing-kbd-macro (bound-and-true-p edebug-active))))
>  
>  
> +;;;; Futuristic interlude
> +(cl-defstruct (eldoc-future
> +               (:conc-name eldoc-future--)
> +               (:constructor eldoc-future-make ())) ; become Yoda we?
> +  "<WORLD CLASS DOCSTRING>"
"Future object."
> +  (value 'eldoc-future--unset)
> +  callback)
> +
> +(defun eldoc-future-set (f v)
> +  "<WORLD CLASS DOCSTRING>"
> +  (cl-assert (eq (eldoc-future--value f) 'eldoc-future--unset))
> +  (setf (eldoc-future--value f) v)
> +  (when (eldoc-future--callback f)
> +    (funcall (eldoc-future--callback f) v)))
> +
> +(defun eldoc-future-set-callback (f c)
> +  "<WORLD CLASS DOCSTRING>"
> +  (cl-assert (null (eldoc-future--callback f)))
> +  (setf (eldoc-future--callback f) c)
> +  (unless (eq (eldoc-future--value f) 'eldoc-future--unset)
> +    (funcall c (eldoc-future--value f))))
> +
> +
>  (defvar eldoc-documentation-functions nil
>    "Hook of functions that produce doc strings.
> -Each hook function should accept at least one argument CALLBACK
> -and decide whether to display a doc short string about the
> -context around point.  If the decision and the doc string can be
> -produced quickly, the hook function can ignore CALLBACK and
> -immediately return the doc string, or nil if there's no doc
> -appropriate for the context.  Otherwise, if its computation is
> -expensive or can't be performed directly, the hook function
> -should arrange for CALLBACK to be asynchronously called at a
> -later time, passing it either nil or the desired doc string.  The
> -hook function should then return a non-nil, non-string value.
> +<WORLD CLASS DOCSTRING GOES HERE>

  "Special hook run to get the documentation string at point.
Each function is called with no argument and should return either nil
or an `eldoc-future` object that should have its `value` set as soon
as possible via `eldoc-future-set-value` (it can be set before
returning the future or at a later time).
This value should be a string, typically occupying only a single line.
In case the function ends up finding no information it is allowed
not to `eldoc-future-set-value` at all."

> +  (let ((x (run-hook-with-args-until-success 'eldoc-documentation-functions)))
> +    (if (eldoc-future-p x) (eldoc-future-set-callback x eldoc--callback)
> +      x)))

I'd simplify this to:

    (let ((x (run-hook-with-args-until-success 'eldoc-documentation-functions)))
      (when x (eldoc-future-set-callback x eldoc--callback)))

But I'd expect that there would be no `eldoc--callback` and that it's
each `eldoc-documentation-function` which chooses its own callback
rather than being chosen by their caller.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 03 Jun 2020 18:08:01 +0000
Resent-Message-ID: <handler.41531.B41531.159120766925170 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159120766925170
          (code B ref 41531); Wed, 03 Jun 2020 18:08:01 +0000
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 18:07:49 +0000
Received: from localhost ([127.0.0.1]:44539 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgXno-0006Xu-Mh
	for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 14:07:48 -0400
Received: from mail-wm1-f51.google.com ([209.85.128.51]:55821)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jgXnm-0006Xd-06
 for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 14:07:47 -0400
Received: by mail-wm1-f51.google.com with SMTP id c71so2792899wmd.5
 for <41531 <at> debbugs.gnu.org>; Wed, 03 Jun 2020 11:07:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:in-reply-to:references:user-agent:date
 :message-id:mime-version:content-transfer-encoding;
 bh=YhkHaOYvVZReJOV3EtfsOXmD0b1cweClyD2c5FNJIac=;
 b=YNwNLjLbO9wr/Ou7MsnAIfhYa0FRT5ZB85LeBIDsSl/OSYhRev+/Snqu8rU2KdPFGJ
 fq9H5vWppxScEOQqGi7tveVxq+io5fSNwFqGQqHj6MS59UVLw5DzyIz54u/f+1bJjMyI
 uqG3EOLsJIcLugmhb8OPVG9H6/sKs7s9o1shMa6MjHfy6qe/P2aojfjwGonfDW/YHMLh
 uSy02W5D8mr8lXzF5h4AImeesDL+8D8+xjuYfc9b3vADw3Ys+IttFi+ZBh1PBCx1b3MM
 l6QsGcJTES3N3EoWGUUWVjRoCniaqVMj6OPNFkA71/mhH0kmxIA5RTJWAMzcCbRkN0db
 r06A==
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:in-reply-to:references
 :user-agent:date:message-id:mime-version:content-transfer-encoding;
 bh=YhkHaOYvVZReJOV3EtfsOXmD0b1cweClyD2c5FNJIac=;
 b=nvi6GLVQY3rJkCCaEXLrzMkLIkyK1phDy+vqU13iFL8sA22u3vpOkwzXsG5Vu1MSKk
 XUBCtDCAwv6Ssa6FCUvoyuN69ijUPeN9uImQPcoK2m2Jz3coA/UKOjrmlaQ4KPYyHfXh
 ecvGdQVSJuQao4KLdM6FeipVQy358er9wbSZnERDjJS2DX0DmFA66HU458/s+i4X/Z0t
 22+1NvbOcZTANagRmsX4qsFG6jrN+rlXF4gNUeUN2b/SjUAXM3IaPAPEAiTclTW8zeSs
 VxcMycsUI6qZPCCDNdyD6rUchKdwk/+gA/m4I7XyrZ8vo3JG1qeZrq/tLMhev8AB6SAI
 vFcg==
X-Gm-Message-State: AOAM531xPZcP73ipB55lI1EgO+6yrD2yXMe9ki+2tXVLNlRL+UDOX7by
 vPwa8tKylw2fe41FClLPFNE=
X-Google-Smtp-Source: ABdhPJz9t1LiBgrdBlk36ZJJlhfpYORQaZa7Sc1JHOzckX9XS+FJ8oWn3x9UpdkgcVAdIiewJsYhgQ==
X-Received: by 2002:a1c:544d:: with SMTP id p13mr376788wmi.25.1591207660103;
 Wed, 03 Jun 2020 11:07:40 -0700 (PDT)
Received: from krug ([89.180.148.153])
 by smtp.gmail.com with ESMTPSA id b187sm4193939wmd.26.2020.06.03.11.07.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 03 Jun 2020 11:07:38 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Tue, 02 Jun 2020 22:45:42 -0400")
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
 <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
 <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Date: Wed, 03 Jun 2020 19:07:37 +0100
Message-ID: <875zc8nhue.fsf@HIDDEN>
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 (-)

Stefan Monnier <monnier@HIDDEN> writes:

> "Future object."
>> +  (value 'eldoc-future--unset)
>> +  callback)
>> +
>> +(defun eldoc-future-set (f v)
>> +  "<WORLD CLASS DOCSTRING>"

Ahem.

>> +  (cl-assert (eq (eldoc-future--value f) 'eldoc-future--unset))
>> +  (setf (eldoc-future--value f) v)
>> +  (when (eldoc-future--callback f)
>> +    (funcall (eldoc-future--callback f) v)))
>> +
>> +(defun eldoc-future-set-callback (f c)
>> +  "<WORLD CLASS DOCSTRING>"

Ahem hem  :-)

>> +<WORLD CLASS DOCSTRING GOES HERE>
>
>   "Special hook run to get the documentation string at point.
> Each function is called with no argument and should return either nil
> or an `eldoc-future` object that should have its `value` set as soon
> as possible via `eldoc-future-set-value` (it can be set before
> returning the future or at a later time).
> This value should be a string, typically occupying only a single line.

Sometimes clients want to return more than one value, i.e. set more than
one value.  In this case it would be, for instance, the type of the
docstring being returns (function signature, value of a variable, etc).
The callback strategy makes it easy because there are lambda lists of
all shapes and sizes.  How does the future approach handle this?  Do
clients return structured lists of things?

> In case the function ends up finding no information it is allowed
> not to `eldoc-future-set-value` at all."

This is problematic.  In the eldoc-documentation-compose situation we
need to wait for every backend to reply before composing.  In other
situation, indeed we can be greedy.  But I don't think you can just say
to clients they dont'need to do anything.  If they returned the future
they are making _a promise_.  If they don't fullfil it something goes
wrong.

The callback case is the same, if you return non-nil non-string, you,
the eldoc function, are _required_, by Eldoc law, to call it, even if
with nil.

The equivalent in futures is just to say clients can set the value nil,
or some other application-specific indication of "sorry, I failed".

> each `eldoc-documentation-function` which chooses its own callback
> rather than being chosen by their caller.

For this to work, i.e. to be able to handle multiple responses, I think
it has to be set by their caller, i.e. eldoc-print-current-symbol-info:
that's the central "hub" that maintains information about how many
backends have responded and how many haven't.

But indeed that's only an implementation detail.  If you can make the
defined behaviour work work in some other simpler way, I have no
objections, of course.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
References: <875zckuet9.fsf@HIDDEN>
In-Reply-To: <875zckuet9.fsf@HIDDEN>
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: Wed, 03 Jun 2020 18:57:01 +0000
Resent-Message-ID: <handler.41531.B41531.159121061629539 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>, mvoteiza@HIDDEN
Cc: 41531 <at> debbugs.gnu.org
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159121061629539
          (code B ref 41531); Wed, 03 Jun 2020 18:57:01 +0000
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 18:56:56 +0000
Received: from localhost ([127.0.0.1]:44556 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgYZM-0007gN-3C
	for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 14:56:56 -0400
Received: from mail-wm1-f46.google.com ([209.85.128.46]:51523)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jgYZL-0007g6-2W
 for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 14:56:55 -0400
Received: by mail-wm1-f46.google.com with SMTP id u13so2936072wml.1
 for <41531 <at> debbugs.gnu.org>; Wed, 03 Jun 2020 11:56:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:date:message-id:mime-version
 :content-transfer-encoding;
 bh=Za6Xfh8TpSblVWbnvn+Ep7XieO81rpeTYCKxycWgDHY=;
 b=pot5BMIKcgObyqZNJ5b4lM6rJra6NLsMb2VEVYljDGaoAjBV10HBaR4SBWdKyzsj9Y
 HHkP1khwnWs6wgNqhM5JVO3tp2/LD+8pxw8TGgvfTvk6MIA7a1Mre+tp92HjYobi87jC
 wiZAJVUai6ASHzBrtuw5I6K/EOxAL5vA7WTRiQ00Kgiq0sQesl24MJS65+NhR0uTR2jG
 2OLPvb22XQ7U7kpt9uCcErLB+a8WzbB1US0sHQocjR6UI+WLo7Xco2f8/YMRaU7gJHm8
 i3u8PeCMhG42lNBWYDNViJgWR4MS7IUdykR9+ECowZwF0wRcaDt9isvPAk6mKSroicFo
 1IfQ==
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:date:message-id:mime-version
 :content-transfer-encoding;
 bh=Za6Xfh8TpSblVWbnvn+Ep7XieO81rpeTYCKxycWgDHY=;
 b=tqadmucdo+dMwgry2o9HzQ89azytpOVuyHo2SicVws52nEcOchDyr9s82U7/+f+D+t
 YNsJhpUWAxHEig/vPX5ayMfdPsnMx1noZnH2yLAA0zWHkc9038uqQS03Rl0XJ8fSgKdQ
 RUiZn6HUZR2LGyH/cnFOhvoCs6IfYUSAugtXN4397Zcz/oNFkgNe01xASgJXruYLPjr6
 /5TcuNWDrC4PmM9aAsmiY5t4KPSE1yYF4/9LS/0fcfTFNWNNqbzUy9uENxVk1LaR096H
 fnPqAO/xIUt2gWAWpq2xTL0h0cbSRPYlfY8IuQ6cDHLCWDpYeJVko0bzn1RRkxAdu/3C
 /wgQ==
X-Gm-Message-State: AOAM532E4CIzrpqoaVBLRCktm+kLVH9NaXmJpHsgbBtBaCKD3nXIsHUQ
 SGc5DdEhxHIp8T8I0MC+EdZ40UaUyyY=
X-Google-Smtp-Source: ABdhPJwH0iZTKw9fG2+cUPDpY57Idm42mlDvtfuf8h8PDwAM8DVQYcPprKjvL9vldd8NZkrr3HAUxQ==
X-Received: by 2002:a1c:b155:: with SMTP id a82mr521305wmf.46.1591210608543;
 Wed, 03 Jun 2020 11:56:48 -0700 (PDT)
Received: from krug (89-180-148-153.net.novis.pt. [89.180.148.153])
 by smtp.gmail.com with ESMTPSA id x8sm4606288wrs.43.2020.06.03.11.56.47
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 03 Jun 2020 11:56:47 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Wed, 03 Jun 2020 19:56:46 +0100
Message-ID: <87eeqwm101.fsf@HIDDEN>
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 (-)

Hello again gang,

As you might have seen in emacs-diffs, I have pushed a new
scratch/eldoc-async branch to the Savannah repo.  If you don't have this
repo setup you can find the commits here in the meantime:

   https://github.com/emacs-mirror/emacs/tree/scratch/eldoc-async

The code, which touches mostly lisp/emacs-lisp/eldoc.el contains the
logical continuation of the improvements I started building two weeks
ago.

When applied, these improvements result in a substantial reduction of
Eglot's documentation handling code.  Yes, Andrii, that means all our
hand-crafted, hard work of doc handling functions is soon gone,
including the awkward eglot-put-doc-in-help-buffer,
eglot-auto-display-help-buffer and the *eglot-help* buffer.

Feels sad but also good, because deleted code is good code.  And it's
not in vain because your feedback and testing was fundamental here.  And
the good news is that the logic problems about blinking and giving
priority to some docs is gone.

There are 6 commits in total, that build on top of each other.  In
reverse order

    10834f20ec * lisp/emacs-lisp/eldoc.el (Version): Bump to 1.1.0
    fe93e5b9d5 Make eldoc-print-current-symbol-info a command
    0612bb7ab5 Introduce eldoc-prefer-doc-buffer defcustom
    40d45067ba Overhaul and handle (most of) eldoc-echo-area-use-multiline-=
p in Eldoc itself
    600b9c0a71 New eldoc-documentation-eager value for eldoc-documentation-=
function
    cde8a6ab98 Better handle asynchronously produced eldoc docstrings

And the new version of Eglot that makes uses of this eldoc is here.

    https://github.com/joaotavora/eglot/tree/scratch/work-with-new-eldoc

It's important to note that Eldoc remains backward-compatible to all its
previous users.

In eldoc.el, things build on top of existing work, which includes the
reasonably new eldoc-documentation-functions (plural).  Earlier, I
thought of this variable somewhat useless, but it's really not.  In
fact, it's exactly what Eglot, SLY and other modes are after.  Even
emacs-lisp-mode itself could benefit as it's often the case that one
loses the documentation for a special variable just because one happen
to be inside a function call, or vice versa.
eldoc-documentation-functions allows us to split up these two competing
sources of documentation, so thank you Mark, or whomever had this great
idea.

An orthogonal question is how to display the documentation we gather
from multiple sources.  That is handled by eldoc-documentation-function
(singular), another variable I had underestimated.  In my changes, I
have added a third option to the two already existing ones.

  :type '(radio (function-item eldoc-documentation-default)
                (function-item eldoc-documentation-compose)
                (function-item eldoc-documentation-eager)
                (function :tag "Other function"))
  :version "28.1")

Eglot defaults to eldoc-documentation-eager, which simulates its
previous behavior.  I suggest you see the docstring for each.
Certainly we can have more strategies to combine documentation sources.

Another important development is that now that the display is
centralized, the formatiing can also be.  Thus a big part of
eldoc-echo-area-use-multiline-p can be easily honoured in eldoc.el
itself.

But the most complex changes pertain to async backends, such as Eglot's
and some (but not all) of SLY.  This is also covered.

On this point, it is also extremely super-important to note that even
though I have NOT used "futures" or "promises" in these patches, the
very same things can be achieved with them, give or take some code here
and there and some head-wrapping around different debugging techniques.
I have NOT focused on the particular async programming technique: I just
used the simplest and most commonly used in Emacs.

Finally, there is a bit of future-proof unused API.  Backends can call
the documentation-reporting callback with keyword arguments, such as
`:hint`.  But they're not really used yet for anything yet.  Some more
sophisticated text formatting in the *eldoc doc* buffer, including
renaming it like Eglot used to do to its *Eglot doc* buffer, is a
possibility.

Another possibility yet, also left unexplored, is for Flymake diagnostic
messages at point to be reported as independent documentation sources.
This is a frequent complain about Eglot.  But in fact I think it should
be Flymake-mode itself that adds some function to
eldoc-documentation-functions.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 03 Jun 2020 20:23:02 +0000
Resent-Message-ID: <handler.41531.B41531.15912157825223 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15912157825223
          (code B ref 41531); Wed, 03 Jun 2020 20:23:02 +0000
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 20:23:02 +0000
Received: from localhost ([127.0.0.1]:44618 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgZuf-0001M8-Ib
	for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 16:23:01 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:16376)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jgZue-0001Ld-0k
 for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 16:23:00 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3147681177;
 Wed,  3 Jun 2020 16:22:54 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6843E80382;
 Wed,  3 Jun 2020 16:22:52 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1591215772;
 bh=2gJBJbrIAWo+ivJ2BiNjOEZQ4L/1qsfrAyVGFfiXN04=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=nlqJiTc6AsrnPRn0RtGIpQ5jFcVyCydV4D/+sryaqw02mz2lxiqBVsiggPeE5HPtg
 7Xx3F70GWUr07rME03ljPZyLZwz6BNiV4349N2Fom+MCJdk5p3CaF5EyqYieklRF7R
 Bq7e1gIm/ZUcQpD5e3ccJ9tCjnK1I2bL+pAXM5SVTc+GtYyg9AnO4hohCwtz2Nzbiw
 3c4vm3PS475sT598hTJr/d4+/6jl8Imt8O2QxaevCbIgvIoP5GSU3X7opqkEW7fpGL
 iL2yT99F/Xrl5Guj+NINqf3Er05g+FW9GG6NHb1KuPm4rpe6W8CTVmvibYQcZ8f8oS
 Td9+onSVTCE0w==
Received: from alfajor (76-10-137-254.dsl.teksavvy.com [76.10.137.254])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ECFA71203B9;
 Wed,  3 Jun 2020 16:22:51 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
 <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
 <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN>
Date: Wed, 03 Jun 2020 16:22:44 -0400
In-Reply-To: <875zc8nhue.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 03
 Jun 2020 19:07:37 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.001 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

>>> +  "<WORLD CLASS DOCSTRING>"
> Ahem.
>>> +  "<WORLD CLASS DOCSTRING>"
> Ahem hem  :-)

Not sure what you mean ;-)

>>   "Special hook run to get the documentation string at point.
>> Each function is called with no argument and should return either nil
>> or an `eldoc-future` object that should have its `value` set as soon
>> as possible via `eldoc-future-set-value` (it can be set before
>> returning the future or at a later time).
>> This value should be a string, typically occupying only a single line.
> Sometimes clients want to return more than one value, i.e. set more than
> one value.

You mean a single call could return first a function signature and
a while later a docstring?  Or at the same time.
If at the same time, then it should return them combined into a single
value (concatenation of strings, list, you name it).

The infrastructure so far only accepts strings as far as I know, so
until that is changed the question seems moot.

> The callback strategy makes it easy because there are lambda lists of
> all shapes and sizes.

It's trivial to use a list to bring the number back down to 1, so it's
not much of a difference.

> How does the future approach handle this?
> Do clients return structured lists of things?

If we want to extend it that way, that would be the natural thing to do,
I guess.  Tho without knowing what the different elements represent
(i.e. some kind of semantic information about that list), I'm not sure
what the callback can do with it other than presume that all elements
are strings and concatenate them.

>> In case the function ends up finding no information it is allowed
>> not to `eldoc-future-set-value` at all."
> This is problematic.  In the eldoc-documentation-compose situation we
> need to wait for every backend to reply before composing.

We definitely don't want to wait: if a backend responds quickly we
should show that info immediately, and update the info if/when another
backend gives additional info.

OTOH indeed for the non-composing situation, we'd need to know that the
1st backend finished unsuccessfully before being able to use the
second backend.  So I guess you're right: we shouldn't allow backends to
drop requests :-(

>> each `eldoc-documentation-function` which chooses its own callback
>> rather than being chosen by their caller.
> For this to work, i.e. to be able to handle multiple responses, I think
> it has to be set by their caller, i.e. eldoc-print-current-symbol-info:
> that's the central "hub" that maintains information about how many
> backends have responded and how many haven't.

I don't think this structure can work well: the "hub" needs to work
differently for compose than for "return first".


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 03 Jun 2020 20:37:02 +0000
Resent-Message-ID: <handler.41531.B41531.15912166136540 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15912166136540
          (code B ref 41531); Wed, 03 Jun 2020 20:37:02 +0000
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 20:36:53 +0000
Received: from localhost ([127.0.0.1]:44639 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jga84-0001hQ-UD
	for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 16:36:53 -0400
Received: from mail-wr1-f43.google.com ([209.85.221.43]:36881)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jga83-0001hD-Pg
 for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 16:36:52 -0400
Received: by mail-wr1-f43.google.com with SMTP id x13so3787006wrv.4
 for <41531 <at> debbugs.gnu.org>; Wed, 03 Jun 2020 13:36:51 -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=Cun6DictJEL/DEQnc2DdbCyzpTJNS9NvC80Guol8Les=;
 b=E58/7DbhHTK7x/UEygVLR1DWg6fivcs8L7JKtE/J6T/hM/SHeRT4ukrudKJ1/2h6UN
 VzLd/QNe3XJ4xwTID0ReaQmat6+07LfP/aJZrKf1F+KYOfn/jCMQJxGv1M0GvEQhKTzM
 NWNV3+4rN+E8e87/EUlMgGPRfX2m9XkDU2WW7NrFyfecC/n9+wAU53tixzz7QExOMru4
 SyAjPnna/Ynut3tYMJCll+PtOGH8jkuIQi2ptDSTILvSgiDjiCJtoY5hjthfw4ow1dtO
 Su1zDzMK9Vfrjtul4xsTGUf6tic4so/NurunQCNDFVPxjLn9Kcb8Lspaa4qZR1uRnwIv
 zPag==
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=Cun6DictJEL/DEQnc2DdbCyzpTJNS9NvC80Guol8Les=;
 b=e8aXckmQDvqH2UxpNhbLs4WPOLt0s4z4FbVPKAk53d96HZBXJ/kq7p+9QSJnjMcCWQ
 Guavst05ZsFNbO1OvnMX3ATZTfbLVU8xI1KgmlvQuScZD7xlrb2NsFa6cBGiN4lP96Dn
 fsI3POqaRhj6cErSl/PJPuZAdhPxMkTL6PzPfoJ2LcvJX0BKQLuvz+aYO/b/YM68k85o
 fajeNGxez2W9wKql2vChVvtgQJGBG8mmUeQs/+qaPaYi4EDQG3Wgzz/QPWFk6U/z2NaA
 57QVpZ7IwNup9Ey26stciR6Md67qG4yxzIfwDnaw9ZXUp4CEBCKRdUlonGUk71JbooW8
 V9GQ==
X-Gm-Message-State: AOAM531hJVALglekSL/BbSlTKgIWcolppGCZOoSd+GyxycxYeMOmKCY8
 q9jfV15w3fu+LsemUW+IlWY=
X-Google-Smtp-Source: ABdhPJw6MBbZ8Y5tLuf0LZBoHmcSnRrDvug6+R4xPLKomJgBa1OSXy+jTZc0dCvh1BRkKkCTshWuAg==
X-Received: by 2002:adf:dc8e:: with SMTP id r14mr1013239wrj.333.1591216605574; 
 Wed, 03 Jun 2020 13:36:45 -0700 (PDT)
Received: from krug (89-180-148-153.net.novis.pt. [89.180.148.153])
 by smtp.gmail.com with ESMTPSA id 40sm5303387wrc.15.2020.06.03.13.36.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 03 Jun 2020 13:36:44 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
 <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
 <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN>
 <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN>
Date: Wed, 03 Jun 2020 21:36:42 +0100
In-Reply-To: <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Wed, 03 Jun 2020 16:22:44 -0400")
Message-ID: <877dwnnaxx.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 (-)

Stefan Monnier <monnier@HIDDEN> writes:

>>>> +  "<WORLD CLASS DOCSTRING>"
>> Ahem.
>>>> +  "<WORLD CLASS DOCSTRING>"
>> Ahem hem  :-)
>
> Not sure what you mean ;-)
>
>>>   "Special hook run to get the documentation string at point.
>>> Each function is called with no argument and should return either nil
>>> or an `eldoc-future` object that should have its `value` set as soon
>>> as possible via `eldoc-future-set-value` (it can be set before
>>> returning the future or at a later time).
>>> This value should be a string, typically occupying only a single line.
>> Sometimes clients want to return more than one value, i.e. set more than
>> one value.
>
> You mean a single call could return first a function signature and
> a while later a docstring?

No, that's not what I mean.  Those should be two different members of
eldoc-documentation-functions (plural).  I meant producing metadata
about the string just returned.  Much like string properties, I suppose,
but not specifically attached to regions of the string.

> The infrastructure so far only accepts strings as far as I know, so
> until that is changed the question seems moot.

Very soon that might change, but yes.

>> The callback strategy makes it easy because there are lambda lists of
>> all shapes and sizes.
> It's trivial to use a list to bring the number back down to 1, so it's
> not much of a difference.

Yes, I agree, but it's IMO easier to read (funcall cb :foo 42 :baz 23)
than (set-value fut (list :foo 42 :baz 23)).

>> How does the future approach handle this?
>> Do clients return structured lists of things?
>
> If we want to extend it that way, that would be the natural thing to do,
> I guess.  Tho without knowing what the different elements represent
> (i.e. some kind of semantic information about that list), I'm not sure
> what the callback can do with it other than presume that all elements
> are strings and concatenate them.

See my most recent patches, there are many ways to handle differently
formated and differently timed reports.

>>> In case the function ends up finding no information it is allowed
>>> not to `eldoc-future-set-value` at all."
>> This is problematic.  In the eldoc-documentation-compose situation we
>> need to wait for every backend to reply before composing.
>
> We definitely don't want to wait: if a backend responds quickly we
> should show that info immediately, and update the info if/when another
> backend gives additional info.

That depends.  Depends on the strategy.  I don't take
eldoc-documentation-compose to mean that, for example.  But we could
easily have eldoc-documentation-compose-wait and
eldoc-documentation-compose-eager.

> OTOH indeed for the non-composing situation, we'd need to know that the
> 1st backend finished unsuccessfully before being able to use the
> second backend.  So I guess you're right: we shouldn't allow backends to
> drop requests :-(

I also don't take eldoc-documentation-default to mean that.  I take it
to mean: focus on the first guy that promised he would produce
something.

But we could indeed have a "focus on the first guy that actually
produced something".

>>> each `eldoc-documentation-function` which chooses its own callback
>>> rather than being chosen by their caller.
>> For this to work, i.e. to be able to handle multiple responses, I think
>> it has to be set by their caller, i.e. eldoc-print-current-symbol-info:
>> that's the central "hub" that maintains information about how many
>> backends have responded and how many haven't.
>
> I don't think this structure can work well: the "hub" needs to work
> differently for compose than for "return first".

Yes, of course it works differently.  How "well" is another question,
whose details I don't fuilly understand.  In the last patches I showed
it works decently well, i.e. I don't see anything wrong with it.  I
implemented eldoc-documentation-default, eldoc-documentation-compose,
and something eldoc-documentation-eager which is like "default" but will
show the first one, and potentially replace with a slower, but more
important one.  These were all done "in the hub", without lots of code.
I'm fairly confident other strategies can be implemented "in the hub"
easily.

In fact, a much better name for eldoc-documentation-function (singular)
is eldoc-documentation-strategy, not least because it relieves us from
this silly singular/plural confusion.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 03 Jun 2020 21:23:01 +0000
Resent-Message-ID: <handler.41531.B41531.159121932710558 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159121932710558
          (code B ref 41531); Wed, 03 Jun 2020 21:23:01 +0000
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 21:22:07 +0000
Received: from localhost ([127.0.0.1]:44662 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgapr-0002kE-LA
	for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 17:22:07 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:19342)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jgapq-0002jk-1r
 for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 17:22:06 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 63A9F4413B7;
 Wed,  3 Jun 2020 17:22:00 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 95A024413B3;
 Wed,  3 Jun 2020 17:21:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1591219314;
 bh=TvARp4dfsdq7aherZgSKK3BVroL7isR+Gvy87oTB8qU=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=O8/7GKR3w72yAIkNWQfirMVD3BRY5Q1R6a003yTKMveQ2RFFBM7P86U0bx5mQy+7v
 DzynAnqkrYpCGB7SMuXwZDYTD4ZTDNkuq7DoO3Bh/c5ws/0AswuNriCrpWcDv+WxmC
 o57a/Af0bb61h3cplKlA6G7sGH7TDHg6fWCkUnpIxd0CTlQZ4b5UV4uuIUFriHrJna
 Yl7WlzIrH+NjfUU+Rce68ozl95hJkawBA/WA9nV6axMMkR3s0GLEpPordClO67Yv0L
 ceaJoCH8YDV/BgBeAn5YezLCZcjce4Ks0Me0clGtXKftWGLWkOy7/k16f3OuJub42l
 nMMTS5/3DNZxg==
Received: from alfajor (76-10-137-254.dsl.teksavvy.com [76.10.137.254])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EDE171206C3;
 Wed,  3 Jun 2020 17:21:53 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvmu5jyhm2.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
 <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
 <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN>
 <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN> <877dwnnaxx.fsf@HIDDEN>
Date: Wed, 03 Jun 2020 17:21:53 -0400
In-Reply-To: <877dwnnaxx.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 03
 Jun 2020 21:36:42 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.072 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

>> You mean a single call could return first a function signature and
>> a while later a docstring?
> No, that's not what I mean.  Those should be two different members of
> eldoc-documentation-functions (plural).

Great.

>>> The callback strategy makes it easy because there are lambda lists of
>>> all shapes and sizes.
>> It's trivial to use a list to bring the number back down to 1, so it's
>> not much of a difference.
> Yes, I agree, but it's IMO easier to read (funcall cb :foo 42 :baz 23)
> than (set-value fut (list :foo 42 :baz 23)).

I find the difference largely irrelevant.  Much more important is
what kinds of :foo and bar are allowed and what they do.

> In fact, a much better name for eldoc-documentation-function (singular)
> is eldoc-documentation-strategy, not least because it relieves us from
> this silly singular/plural confusion.

Sounds very good.  Changing its name will make it possible to fix the
current backward-incompatibility (which we'd fix by re-introducing a(n
obsolete) eldoc-documentation-function).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 03 Jun 2020 21:29:01 +0000
Resent-Message-ID: <handler.41531.B41531.159121971111100 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: Christopher Wellons <wellons@HIDDEN>, andreyk.mad@HIDDEN, 41531 <at> debbugs.gnu.org
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159121971111100
          (code B ref 41531); Wed, 03 Jun 2020 21:29:01 +0000
Received: (at 41531) by debbugs.gnu.org; 3 Jun 2020 21:28:31 +0000
Received: from localhost ([127.0.0.1]:44667 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgaw3-0002sy-BO
	for submit <at> debbugs.gnu.org; Wed, 03 Jun 2020 17:28:31 -0400
Received: from mail-wm1-f42.google.com ([209.85.128.42]:38154)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jgaw1-0002sl-RX
 for 41531 <at> debbugs.gnu.org; Wed, 03 Jun 2020 17:28:30 -0400
Received: by mail-wm1-f42.google.com with SMTP id f185so3573161wmf.3
 for <41531 <at> debbugs.gnu.org>; Wed, 03 Jun 2020 14:28:29 -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=Ip3L0ljstINhrnBI9r2Hf6N5g9/HQnfrIAic3dVZISQ=;
 b=ZZX1VvifS3QbPrYe8hScB4YUZbUA01eQIANh5nS8Knlr4RQi64Dr7Q6Tr689+dXu53
 E97+wFWdikI5xK7a4PDouDZ81P8okyKfmnuewds+WSBFnk5iaa5aGav7oJ72zA/JCilm
 jNRruWGE2eZUfYucOvL+vMHJM7oYQK2AmAHUMXPfBYhWgf7Gg7tX5PZF529kJv7F80P+
 mefmyQ+ETZipJMGmn9Gn7GJ3CmtGOwETpyzcU1bjXNp8MmpyFEMRE0zXsRHeRfDAswKA
 C/9bpMaYm9FfOo/aVdehjHGIJRiMg1IUPqyu8piyd8eyIW/HqyCb1O0IcUDZbB0UdA8w
 c8Bg==
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=Ip3L0ljstINhrnBI9r2Hf6N5g9/HQnfrIAic3dVZISQ=;
 b=GTeL5xdKqJl5BiM+tAX2YopSUGWpD2t4OwryvJ1O/hABOcWloWzh67qPt7gUt9Q5+L
 fuiR5eXqiZmq7B3zwVAM3a2LgGFfpajdtfkzSaAVVx6X5kz0uvlcNKI1wPJeZbAquEd/
 mLzpPeBg2wmpqXZKfZeUUIxukUh5sz4VZVPjwdlevJQkngBMkyav0AY0lUPcxI1RWNRu
 HwNy2SS+aiqWUt54r8ZY5KEj7NkcYdosRn+cFdX7klZSKFZBJpYb2Pv72hahBhCZvPSI
 e5l8zEUz2+aBVPjIQ3O65D+Sus1Eo1ooQs/ecv8ujzsJfxJQPpRlT8/CMAIg3zLiMxpQ
 Pbeg==
X-Gm-Message-State: AOAM530p9d4GhJtq+RegRJ3U+bD286aBTzW0bqZk3yg5rjJcJ9FZ21Q7
 W/u6zEgmCtUCcSxLIoApdIhAvXt5
X-Google-Smtp-Source: ABdhPJzB/XdBrL/bxXj8iLCr5obaEOr8xxBFhwCzvv5b8tIuh9yfuphFxC+LFMbNzg2DTrg1+TDBmA==
X-Received: by 2002:a1c:8048:: with SMTP id b69mr901662wmd.169.1591219703637; 
 Wed, 03 Jun 2020 14:28:23 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id l1sm6026133wrb.31.2020.06.03.14.28.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 03 Jun 2020 14:28:22 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
 <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
 <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <6d309720-ab64-0311-50b6-c50b7b7bfa15@HIDDEN>
Date: Thu, 4 Jun 2020 00:28:20 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <875zc8nhue.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.5 (/)
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: -0.5 (/)

On 03.06.2020 21:07, João Távora wrote:
> The equivalent in futures is just to say clients can set the value nil,
> or some other application-specific indication of "sorry, I failed".

They should call 'eldoc-future-set-error'.

One design point I'm not sure of, is whether the argument should be a 
string (coming from the error message), or a "proper" exception/error 
object, previous captured inside a condition-case.

We might make that choice just based on whether url-retrieve passes the 
same kind of data as, say, error-message-string expects. The same 
"proper" object, that is.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
Resent-From: Andrii Kolomoiets <andreyk.mad@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 04 Jun 2020 16:22:02 +0000
Resent-Message-ID: <handler.41531.B41531.15912876687173 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15912876687173
          (code B ref 41531); Thu, 04 Jun 2020 16:22:02 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jun 2020 16:21:08 +0000
Received: from localhost ([127.0.0.1]:47359 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgsc8-0001rd-2G
	for submit <at> debbugs.gnu.org; Thu, 04 Jun 2020 12:21:08 -0400
Received: from mail-lj1-f177.google.com ([209.85.208.177]:42733)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <andreyk.mad@HIDDEN>) id 1jgsc2-0001qm-Pm
 for 41531 <at> debbugs.gnu.org; Thu, 04 Jun 2020 12:21:06 -0400
Received: by mail-lj1-f177.google.com with SMTP id y11so6400611ljm.9
 for <41531 <at> debbugs.gnu.org>; Thu, 04 Jun 2020 09:21:02 -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=a5XQyh4Jm1hMe8Xdtol2G2P1KkSyxrWcA4gLfuCFPq8=;
 b=Ia3PjM584cX6Y9LmEwPkl8eNikkHZAZwe0n0A08l7eKIhOh/h38p4U1DNIx2xiQpMO
 yRWGsk7z77cO8GCIFU0OQVbbmS7A853+S/+Xuq36EDsKGLxjZFoUTTqqkfqvIXwSeZZ3
 /g9WKrBztDns6iuO1nzblLen2NFrQJ321O7UlO42njNworKBDGYpA570rAkzfTkX2x8w
 L0U3J96vuME2LiZJIxD4oEFYXRFZcYLU79VMu5/pMZ53UhJ5TaFHfZ3esj8ynp/aEwbj
 LCS+3g32UHKx4G8D9ZJT8+m6AVs6spHzKJlEqB1G/60ffKpq1dd+IYiXrYU28JuD94o7
 WBoQ==
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=a5XQyh4Jm1hMe8Xdtol2G2P1KkSyxrWcA4gLfuCFPq8=;
 b=aQ7UY/XshHKfxgsuDjQ9pihpbfq99n4vIUWGSfM/cYWOC5lWPfhxaeq680Csi6FPYn
 1mSBWtF67nGCEbVglb7UYkA0JOwu70Zzo1qZETaE+nfPLZl9Rx6UN5OOXumnw2meEeHm
 67WJJ/PZWt24e/kUNXonYNQ6xm341fdipod6m4ZSbMdRTLSCg1clNpJIITECHEIyrn7J
 ahoUlG7oiu4Lwt23gTr2PkRm3QK5Vsh8CGvG5l+ofUQv9/oe5FG/Jtlx3IM5aVa2Kv6V
 qKRjkBFnxPN7TfNk362aSwlqxE2skIGP1SzJEsBlgBosCzAzC3yRaGV72pp03h7UVg+g
 nlOg==
X-Gm-Message-State: AOAM530gTfTQ30Fvnwz3joSXLQKAeLIrBWbHtuCJJ0m7+hy2PMJAvWb/
 NwTomBsUq6+X6awU2JK24kOAU6gxnmQ=
X-Google-Smtp-Source: ABdhPJxC6b6OJoUT1f05daJkBbnO7i0bJB7LOYZQ/zrZlMbNBFiUGf5FwqU23peA3QAfR1GWBK16Jg==
X-Received: by 2002:a05:651c:93:: with SMTP id
 19mr2614955ljq.245.1591287655744; 
 Thu, 04 Jun 2020 09:20:55 -0700 (PDT)
Received: from muffinmac.local ([91.206.110.130])
 by smtp.gmail.com with ESMTPSA id f22sm13169ljn.28.2020.06.04.09.20.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 04 Jun 2020 09:20:54 -0700 (PDT)
From: Andrii Kolomoiets <andreyk.mad@HIDDEN>
References: <87eeqwm101.fsf@HIDDEN>
Date: Thu, 04 Jun 2020 19:20:53 +0300
In-Reply-To: <87eeqwm101.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 03 Jun 2020 19:56:46 +0100")
Message-ID: <m2pnae2462.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin)
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 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Hello again gang,

Hi Jo=C3=A3o,

> When applied, these improvements result in a substantial reduction of
> Eglot's documentation handling code.  Yes, Andrii, that means all our
> hand-crafted, hard work of doc handling functions is soon gone,
> including the awkward eglot-put-doc-in-help-buffer,
> eglot-auto-display-help-buffer and the *eglot-help* buffer.
>
> Feels sad but also good, because deleted code is good code.  And it's
> not in vain because your feedback and testing was fundamental here.  And
> the good news is that the logic problems about blinking and giving
> priority to some docs is gone.

I for one completely support moving documentation handling code to
eldoc.

I was planning to remove the eglot-put-doc-in-help-buffer variable in
the near future PR as well as the use of the eglot--message function for
the documentation display ;-)

However, after briefly using new Eldoc and Eglot I found some issues
that, I hope, we can fix:

1. Display only first line of the hover info.  Again :-)

2. The hover info is sometimes displayed right before the signature info
making the echo area to "blink".  I suppose this must be fixed on Eglot
side by not requesting both the hover and the signature infos at the
same time.

3. That IMO useless "...truncated, see *help* buffer" message is moved
to Eldoc.  Do we really need to show this message every time?  That one
last line can be used to show additional documentation.

Hadn't a chance to take a closer look at the code, so reporting those
issues is the most I can do for now.

Thanks!

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
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: Thu, 04 Jun 2020 18:23:01 +0000
Resent-Message-ID: <handler.41531.B41531.159129493027029 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrii Kolomoiets <andreyk.mad@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159129493027029
          (code B ref 41531); Thu, 04 Jun 2020 18:23:01 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jun 2020 18:22:10 +0000
Received: from localhost ([127.0.0.1]:47443 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jguVF-00071t-W1
	for submit <at> debbugs.gnu.org; Thu, 04 Jun 2020 14:22:10 -0400
Received: from mail-wr1-f44.google.com ([209.85.221.44]:35033)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jguVE-00071h-O6
 for 41531 <at> debbugs.gnu.org; Thu, 04 Jun 2020 14:22:09 -0400
Received: by mail-wr1-f44.google.com with SMTP id x14so7197526wrp.2
 for <41531 <at> debbugs.gnu.org>; Thu, 04 Jun 2020 11:22: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=KP+9kffa5YgPItx7lC94yw053wFlSHcqj3JEKcZBYWw=;
 b=eSZWQgpBL7X2EmP1SSF+mLrKxIl3Qp+CzenlnNUC4t5ZO580wB78mCSpQfrXvBxOEQ
 UF61Uh8gdw6Q3ISn3Weu0RDcQIepjusxbWRpvav4c+5fdhNzIYkIe3X/pw6p1QqjD7vB
 ThA+BaF8u7nJxfGEphPowhM3uhDBjh67v3HLpusRr00kXMz3T89IGf71TnHR6Q10ikdu
 nmrfTMgfbYAdQ+lyTILnqQlJx/7H34SHijp995H0KxLeK3hH72Yw0CM3qmh/9IUrMKrm
 JRYrBTxtecESzYEA1M2Bp+4WRtyeuwOp2KXS0J3vpibZ4yB6qvOqQ+V4FnUVUUAwb4NN
 EFzw==
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=KP+9kffa5YgPItx7lC94yw053wFlSHcqj3JEKcZBYWw=;
 b=rEJTnSiXTAfftrnXUujkvNLzEQrZAjyj4idTTDm/W9nwh7I402tFHb/gRnK2K7NOGj
 mquN8y7500shhG3bGufAm/svASo/hk3u6uVJZgaWlF9XyebmM2Ac6qHpr/Dc8yEev6Uy
 z+9dPhxJ45QoXBH1EbLhuDQcr6nVQysCMYRc4b8gz/w9iSV/1RPp2c4v0aY6BsoeekFy
 YcgGPkLYMTjdYeH4hmOx/Z1BYNrNaFIBedF5ptH0WEZDEx7nRDCsaP3hEydrnLJP/oCZ
 NjWjcnJJRJL3ioN7fIiLNvkg0km730OFXDdJqix3NSMIrnn/mAK+s3VDyvFFWAOz49WH
 gVUg==
X-Gm-Message-State: AOAM533v+Wh8Wh92aKGUL/gx5m51toRCtU4RqW1Wfp5zdVEVRZ7ULVVk
 LHGVIr9s631Wc1fogPvzhYc=
X-Google-Smtp-Source: ABdhPJwXQgyA4NikxiC1tUmqcJsxrB8KXliYCj+YW/0X7CnEt4GJFoxic43Y4hFfQNJguN1uxILNjg==
X-Received: by 2002:a5d:61d0:: with SMTP id q16mr5970488wrv.182.1591294922877; 
 Thu, 04 Jun 2020 11:22:02 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id q5sm9093843wrm.62.2020.06.04.11.22.01
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Thu, 04 Jun 2020 11:22:02 -0700 (PDT)
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <e2945b44-3a63-6d7e-4adb-1c1228ca488f@HIDDEN>
Date: Thu, 4 Jun 2020 21:22:00 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <m2pnae2462.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.5 (/)
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: -0.5 (/)

On 04.06.2020 19:20, Andrii Kolomoiets wrote:
> 3. That IMO useless "...truncated, see*help*  buffer" message is moved
> to Eldoc.  Do we really need to show this message every time?  That one
> last line can be used to show additional documentation.

The truncation can be indicated as ellipsis at the end of the (first) 
line. Maybe ellipsis in parentheses (...).

Whether to use multiple lines of not, seems like individual preference.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
Resent-From: Andrii Kolomoiets <andreyk.mad@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 04 Jun 2020 19:01:02 +0000
Resent-Message-ID: <handler.41531.B41531.159129721630584 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159129721630584
          (code B ref 41531); Thu, 04 Jun 2020 19:01:02 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jun 2020 19:00:16 +0000
Received: from localhost ([127.0.0.1]:47456 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jgv68-0007xD-HV
	for submit <at> debbugs.gnu.org; Thu, 04 Jun 2020 15:00:16 -0400
Received: from mail-lj1-f181.google.com ([209.85.208.181]:35320)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <andreyk.mad@HIDDEN>) id 1jgv66-0007x0-9C
 for 41531 <at> debbugs.gnu.org; Thu, 04 Jun 2020 15:00:14 -0400
Received: by mail-lj1-f181.google.com with SMTP id c11so8703036ljn.2
 for <41531 <at> debbugs.gnu.org>; Thu, 04 Jun 2020 12:00:14 -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;
 bh=nEAW7cNI0vce7xeF6xKwIpahbcZqX19u3MNRMWja/AE=;
 b=ahuyVn3T3Z7Ti0r0ramN3OsoWG0smAwaTVu4yJakGYG+By/+jAsJ/dHmAxCaANZEd/
 otSZ5P7AefPMlpqj1NarEAROJ18inqTN90xncB6L8r0reIedLI2Ux26FF5Vq3jrx85rj
 9Pi4+TgZFRrGwPquM9LLh3X7hjH/PabGmqIYcgUPdlK8OjSwW/0/FIGFpep1cZPERK5A
 /q6kSr6qJEzQYgCclAb1kXmrZ6q+rvKrN6yo2qt/Il9RKqvf1g0aK+Oiag1Fq9RmAyiU
 wE4O/9tbgs1d6++TetBmnFLhX2pSFeIu8HMBv7ZSUZvNmfyhM6SREv9HT+4iczu2foBC
 +npA==
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;
 bh=nEAW7cNI0vce7xeF6xKwIpahbcZqX19u3MNRMWja/AE=;
 b=g40H6QAmgCEJixMyvoHPPIl7wX8fOcPxnjVEi9DnpdZHMQIvEC8w0/T66XE3jA+tFg
 qiPcwqa4MIF6GWMIFnlNe3m3oNaZUIKo+55Y1+K8qYkMF8c+ltXB1QVlCixLKwP9tP7f
 PBU0OjHaB/VF/TDnFlRdjMYJqwL2ZFpUKCgiCmLFQNT89SP25yzYUydD/veJgvFb7POx
 YJ5OyRpybqJ4NeP4VbWNw2FOEFTbRzZV42+U+mgyRqshdwRlQ7Wft/bo/wlyFkN5wr8F
 mf1kpSNBdXsTlJUCJIsjtJnAP1GoT67pBzIFcjn+xI7R0gWmBnqvgKOD/RJoLdv88QsT
 gOCA==
X-Gm-Message-State: AOAM530qaFB1FbZ4iLgujZv1qi9mRdvr9+eyJRHczv+Ls7XBPrxd4xtb
 31GmACdfG/L+rYyBnczdXU8=
X-Google-Smtp-Source: ABdhPJyowZxPZCik7fn/9TU0mkAYTp150YVe2k2ezyhCcugt/+sKLL+wAvSCpujjDP3MySZ03E5QWQ==
X-Received: by 2002:a2e:9586:: with SMTP id w6mr2793711ljh.274.1591297208049; 
 Thu, 04 Jun 2020 12:00:08 -0700 (PDT)
Received: from muffinmac.local ([91.206.110.130])
 by smtp.gmail.com with ESMTPSA id 130sm106982lfl.37.2020.06.04.12.00.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 04 Jun 2020 12:00:07 -0700 (PDT)
From: Andrii Kolomoiets <andreyk.mad@HIDDEN>
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
 <e2945b44-3a63-6d7e-4adb-1c1228ca488f@HIDDEN>
Date: Thu, 04 Jun 2020 22:00:05 +0300
In-Reply-To: <e2945b44-3a63-6d7e-4adb-1c1228ca488f@HIDDEN> (Dmitry Gutov's
 message of "Thu, 4 Jun 2020 21:22:00 +0300")
Message-ID: <m2lfl21wsq.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin)
MIME-Version: 1.0
Content-Type: text/plain
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 04.06.2020 19:20, Andrii Kolomoiets wrote:
>> 3. That IMO useless "...truncated, see*help*  buffer" message is moved
>> to Eldoc.  Do we really need to show this message every time?  That one
>> last line can be used to show additional documentation.
>
> The truncation can be indicated as ellipsis at the end of the (first)
> line. Maybe ellipsis in parentheses (...).

Good idea.

> Whether to use multiple lines of not, seems like individual preference.

Absolutely.  That's why there are customizable variables so anyone can
tweak behavior to their likes.  Current version of Eglot pays attention
to the eldoc-echo-area-use-multiline-p variable and proposed one do
not.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
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: Fri, 05 Jun 2020 11:02:01 +0000
Resent-Message-ID: <handler.41531.B41531.159135487224456 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrii Kolomoiets <andreyk.mad@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, theothornhill@HIDDEN, mvoteiza@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, Fredrik Bergroth <fbergroth@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159135487224456
          (code B ref 41531); Fri, 05 Jun 2020 11:02:01 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 11:01:12 +0000
Received: from localhost ([127.0.0.1]:48380 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhA63-0006MO-VX
	for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 07:01:12 -0400
Received: from mail-wr1-f48.google.com ([209.85.221.48]:41912)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jhA5y-0006Lt-Kw
 for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 07:01:10 -0400
Received: by mail-wr1-f48.google.com with SMTP id j10so9286158wrw.8
 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 04:01:06 -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=y7nSKXsjG4BSOHM8rqvk+w+CFeR9SniJOhZn0MnTosI=;
 b=iCak68Ljf7d9T8hu4hBmCLL9+n76zFUxREb4qwQZ/eCBts9z97B8jcivlg9c6/XcqX
 oJzdsiLSiy7jidf2xwsd1EF44cXHiTH8/2bS528khqDPZxLNVrZ49QRZw8WoGRt+210z
 LmEAhmrZO0kgrRRXeb1Di7Bu03XGqR8AL1inlbQGx3CvWoONS3n/jkhwESUCxR9meyhH
 LEQiw75X7Pr2erQRcMQ/Qw1/ZOE4W8Om94xYfpk0vXxSEmEy9t8/3Tc5bPW+SxV66sdP
 g7wQocjsq62j378JWy45HSqe0JhDfU6+JKLCvoPrTPB2dw/VwJv+e9aRcis3higEUasF
 /9nA==
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=y7nSKXsjG4BSOHM8rqvk+w+CFeR9SniJOhZn0MnTosI=;
 b=HqOlSaOJk29/T2++Gs5jWSQsSYJ7aQpRXhdoGyMdc0QM1Iayt1ig1FtQdLhe54thIR
 j7L/0cha8eN+ImLqqoQV0Gc31r9pdfuvRZVruy2l7bCODMqdxpSthiW+HoqugT8vIQk5
 DJQO3XbEpKmSXa/SZYctMPgU0K1UMf/cUAxK6vGTDsVIt3XoKQHE9wX7KI8E+3RtHEVB
 FzNJN/0HiLvhNriwBlCUNNozac6kz68ne/0dcn0sbxwgrOhZE4hLhILIVW/dfVxBJGyq
 uIwz1gCW1BRx0vrnK2hxyhtCOgpgVDAB2MI0y1DjyUDT0efMQpQ6HIBUW84vmu/aa2mL
 qW+w==
X-Gm-Message-State: AOAM531EvtmU4AnzoYGXLSzllqNbsxI/IxiTTfAyQxPlAVWcJgP6UTsm
 pIXd/kUfK5PTTKEK71THR/8=
X-Google-Smtp-Source: ABdhPJzQaKCDxC9MMXDOK8GZeSoRSzZloH6XtDuRdAPwI/Vg2AYpipZwHWMG64Posqbw6GafXRzn7g==
X-Received: by 2002:adf:f58b:: with SMTP id f11mr9021417wro.155.1591354860719; 
 Fri, 05 Jun 2020 04:01:00 -0700 (PDT)
Received: from krug ([89.180.149.24])
 by smtp.gmail.com with ESMTPSA id 1sm10984852wmz.13.2020.06.05.04.00.58
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Jun 2020 04:00:59 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
Date: Fri, 05 Jun 2020 12:00:57 +0100
In-Reply-To: <m2pnae2462.fsf@HIDDEN> (Andrii Kolomoiets's message of "Thu, 
 04 Jun 2020 19:20:53 +0300")
Message-ID: <87img5lqty.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 (-)

[ Theodor and Fredrik, adding you since you were also interested in this
Eglot/Eldoc matter.  You can review the messages in the bug list if
you're interested:  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531]

Andrii Kolomoiets <andreyk.mad@HIDDEN> writes:

> I was planning to remove the eglot-put-doc-in-help-buffer variable in
> the near future PR as well as the use of the eglot--message function for
> the documentation display ;-)

I'm guess I'm happy to have shot these plans into the depths of the
ocean ;-)

> However, after briefly using new Eldoc and Eglot I found some issues
> that, I hope, we can fix:
>
> 1. Display only first line of the hover info.  Again :-)

You should be able to do this with either

   (setq eldoc-echo-area-use-multiline-p 1)

or

   (setq eldoc-echo-area-use-multiline-p nil)

Did you try this? If so, what exactly didn't work for you when you did?
I'm sorry if you've already given me this information in the multiple
PR's you opened about this, but let's have it again.

> 2. The hover info is sometimes displayed right before the signature info
> making the echo area to "blink".  I suppose this must be fixed on Eglot
> side by not requesting both the hover and the signature infos at the
> same time.

Not something to be fixed in Eglot, definitely, it's not its fault or
responsibility: it just reports whatever it has.  I've fixed this in
Eldoc, in the last commit.  It only affected the "eager" strategy (which
should really be called the "enthusiast" strategy).  I'll post a commit
soon using better names for strategies, I'm thinking:

eldoc-documentation-function  -> eldoc-strategy         (with obsolete alia=
s)
eldoc-documentation-functions -> eldoc-functions        (maybe)

eldoc-documentation-default  -> eldoc-patient
eldoc-documentation-compose  -> eldoc-compose-patiently
eldoc-documentation-eager    -> eldoc-enthusiast        (Eglot uses this)
  <doesn't exist yet>        -> eldoc-compose-eagerly   (Stefan mentioned t=
his)

> 3. That IMO useless "...truncated, see *help* buffer" message is moved
> to Eldoc.  Do we really need to show this message every time?

I see.  Maybe not _every time_ but at least _once_, I'd say.  Once per
Eldoc session (but what is an Eldoc session)?  Once per x truncated
messages?  Customization variable? (I hate those, but maybe).

Or maybe never show it?

> That one last line can be used to show additional documentation.
> Hadn't a chance to take a closer look at the code, so reporting those
> issues is the most I can do for now.

Yes, and that's fine for now, though a second pair of eyes in the code
is certainly appreciated too.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Fri, 05 Jun 2020 11:27:01 +0000
Resent-Message-ID: <handler.41531.B41531.159135640926897 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Christopher Wellons <wellons@HIDDEN>, 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159135640926897
          (code B ref 41531); Fri, 05 Jun 2020 11:27:01 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 11:26:49 +0000
Received: from localhost ([127.0.0.1]:48410 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhAUr-0006zl-BZ
	for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 07:26:49 -0400
Received: from mail-wm1-f48.google.com ([209.85.128.48]:37543)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jhAUq-0006zZ-77
 for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 07:26:48 -0400
Received: by mail-wm1-f48.google.com with SMTP id y20so1021393wmi.2
 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 04:26:48 -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=xxOYCOM/ZtKjqtBwBmFlfl3dHatjIzR/tty1FP0Lqns=;
 b=rFXJ6RcA5J5E2DDR0990Bxab2sYYxZa50ykwOdkXoBBP0fd1gEQCUp/3OcaQFyxdlt
 UZKBAlN6owK/360/fxwn3WW7hS+a3pdc9BWAfN6Z2+Vlg2crLLIzZo5uFNOP3MwIPNvf
 nEnXSAjBeitXkR6fuOwYjfYlcks1wkYCZQcUX46vqqqRSOfSYWziCj9q8hhDB5qL8y+x
 YpPuIDOOVwJ6CQ5JFogpzpAWBhJh+nTSD0ZuG3CU4pMUELC96Thp9EM+1yUgKsnNs3tA
 NeUEGuhY9o77apByP2P7WAWnS/NGCko1GZzbvIFGAPtkLSEG3zsex2cyHf2PFP/HwUJW
 9r+g==
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=xxOYCOM/ZtKjqtBwBmFlfl3dHatjIzR/tty1FP0Lqns=;
 b=HsX1b1y5/KVeYaxc90E6ddY8/aa4HjIv6mIu/xUn7fuuiVwmmJ0F6tbdWj/I30428c
 Qy5sxsBWFWIGbTJ0fwDKPnzA1xVqhAYhS/90fqdMC30vfm76EB6dL4DzBBSNRKxhsg0r
 umowwvl/pwYHZhT8hOc8ywb+9iDblJJ7dZ+LYzTywzP6Ov/Eo+/XVzi+5l1bGQcO3UbI
 IdlSyfQnBqWP/I6YbiqhziN4pQjTz3QHgEa7q0lYS/0lrafruZLk0QkNKig1JC83en3c
 mWjjjBORG0aVy4xnFGcZjvt/Wsk3u86hhn4Z6EYYMomQlSBx5QDvPafwZFUwD7rBnBd4
 KRFQ==
X-Gm-Message-State: AOAM531vF/rM7o6NV/U9V+cbVaSiveKgmFYj1OVE4ie3EfXBh3zIWHrA
 5JV1XLwcyIsjkYDl/qL/EfU=
X-Google-Smtp-Source: ABdhPJyniLwZjerjcKrfb4szY3j8bwRIg6L139GRXC9Lv962JLpFdIrSTAZcp7m6RkgUAr8V03txgw==
X-Received: by 2002:a1c:6244:: with SMTP id w65mr2249800wmb.82.1591356402127; 
 Fri, 05 Jun 2020 04:26:42 -0700 (PDT)
Received: from krug ([89.180.149.24])
 by smtp.gmail.com with ESMTPSA id r2sm12565802wrg.68.2020.06.05.04.26.38
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Jun 2020 04:26:39 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN> <87pnaqrae9.fsf@HIDDEN>
 <jwvo8qa4rxj.fsf-monnier+emacs@HIDDEN> <877dwyr7b9.fsf@HIDDEN>
 <jwv1rn64n38.fsf-monnier+emacs@HIDDEN> <871rn6r0pr.fsf@HIDDEN>
 <jwvsgfczxpm.fsf-monnier+emacs@HIDDEN> <875zc8nhue.fsf@HIDDEN>
 <jwvy2p3ykko.fsf-monnier+emacs@HIDDEN> <877dwnnaxx.fsf@HIDDEN>
 <jwvmu5jyhm2.fsf-monnier+emacs@HIDDEN>
Date: Fri, 05 Jun 2020 12:26:37 +0100
In-Reply-To: <jwvmu5jyhm2.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Wed, 03 Jun 2020 17:21:53 -0400")
Message-ID: <878sh1lpn6.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 (-)

Stefan Monnier <monnier@HIDDEN> writes:

>>> You mean a single call could return first a function signature and
>>> a while later a docstring?
>> No, that's not what I mean.  Those should be two different members of
>> eldoc-documentation-functions (plural).
> Great.

Indeed, I can see 3 eldoc sources for emacs-lisp mode, in this order:

- function signature
- docstring
- special variable value

If emacs-lisp-mode one uses the default display strategy
(eldoc-documentation-default or some rename of that) and sets
eldoc-echo-area-use-multiline-p to 1, it should be fully backward
compatible to the current behaviour.

Alternatively, we can have emacs-lisp-mode keep out of
eldoc-echo-area-use-multiline-p and use 4 sources:

- function signature
- one-line docstring
- special variable value
- remaining paragraphs of docstring

( At some point, if we compose all of these bits of information in the
volatile *eldoc* buffer, it will start looking a lot like *Help* for C-h
o, There's some integration work to do there, but I'd rather not open
that can of worms just now. )

>>>> The callback strategy makes it easy because there are lambda lists of
>>>> all shapes and sizes.
>>> It's trivial to use a list to bring the number back down to 1, so it's
>>> not much of a difference.
>> Yes, I agree, but it's IMO easier to read (funcall cb :foo 42 :baz 23)
>> than (set-value fut (list :foo 42 :baz 23)).
>
> I find the difference largely irrelevant.  Much more important is
> what kinds of :foo and bar are allowed and what they do.

I agree.  Content is more important than style.  Of course style
matters, too.  Occasionally, it matters overwhelmingly.  But not
here. I'd say.  The promises-vs-callbacks discussion is a matter of
style.

>> In fact, a much better name for eldoc-documentation-function (singular)
>> is eldoc-documentation-strategy, not least because it relieves us from
>> this silly singular/plural confusion.
>
> Sounds very good.  Changing its name will make it possible to fix the
> current backward-incompatibility (which we'd fix by re-introducing a(n
> obsolete) eldoc-documentation-function).

Yes, that's the plan.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
Resent-From: Theodor Thornhill <theothornhill@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 05 Jun 2020 18:18:01 +0000
Resent-Message-ID: <handler.41531.B41531.159138104025585 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN>
Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, Fredrik Bergroth <fbergroth@HIDDEN>, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Reply-To: Theodor Thornhill <theothornhill@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159138104025585
          (code B ref 41531); Fri, 05 Jun 2020 18:18:01 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 18:17:20 +0000
Received: from localhost ([127.0.0.1]:49899 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhGu7-0006du-GD
	for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 14:17:20 -0400
Received: from mail-40134.protonmail.ch ([185.70.40.134]:16436)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <theothornhill@HIDDEN>) id 1jhGUc-0003xO-1z
 for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 13:51:02 -0400
Date: Fri, 05 Jun 2020 17:50:38 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail;
 t=1591379451; bh=XKCZNxRwaLTFmCroMCzwpX5+zs0jeepoY5zA0OiEKwA=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=CMlqp/RC6WQ5AoOQzr6hUtqmqA3JHXBvpZJpVZMs8SU5tnP4pJ87u9e/Ic0UGpBL6
 kB56V9b7tMVGhq50k7iwPpqG8JIWADhVBiZbLVEynX3UbcmkVHCcktYV5t8ue5Y/Qj
 lHPR2VdYwn+kye/8UyMFiiYdRoNWe6GEQEqGUDcxx3LPfhXLdAZeF6Mg6SHsqqmXSh
 wfyOIVp2LIW6WOCFspcSOwFagFoL4Q/gCr2/mszj//PwChV9w0+FAEGwRFb/FPl9Bq
 RYxStUbsXwdqBUFisG8gKBywFq+fmsrmauOi9vPLy7Mf71htJBg5ZXTCk9X9XwSoSi
 ID5mRtMRDklSA==
From: Theodor Thornhill <theothornhill@HIDDEN>
Message-ID: <87img55rmm.fsf@HIDDEN>
In-Reply-To: <87img5lqty.fsf@HIDDEN>
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
 <87img5lqty.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED,
 DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no
 autolearn=disabled version=3.4.4
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch
X-Spam-Score: -0.7 (/)
X-Mailman-Approved-At: Fri, 05 Jun 2020 14:17:18 -0400
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.7 (-)

Hello!

Thanks for pinging me -

I tried it, and it looks pretty cool. However, I noticed a few bugs.

(When using both the new eldoc and eglot):

Bug 1:     =20
1. Open a file
2. Start eglot
3. Hover something with "C-h ."
4. Switch to the new window that popped up.
5. C-x k (kill buffer)
6. Repeat step 3.
7. "invalid buffer" and eldoc is dead.=20
8. Starting and stopping eldoc doesn't work  =20

This seems to happen since it uses the new buffer and updates it. When that=
 buffer is deleted, it gets confused.


Bug 2:
1. (setq eldoc-echo-area-use-multiline-p nil)
2. eglot spits the whole thing on one line. This looks a bit weird since it=
 uses both the signature and the documentation.

This may not be a bug, but right now IMO it looks a bit strange.

Bug 3:
1. "M-:"
2. Type "("
3. Minibuffer shows: eldoc-error: (wrong number of arguments (0 . 0) 1)

I think the first bug is the most problematic one though :)

However, I've started to take a liking to the no options set, with this ver=
sion. I think I like the "truncate, press M-x ..." message more than the pr=
evious one.

All the best,

Theodor

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> [ Theodor and Fredrik, adding you since you were also interested in this
> Eglot/Eldoc matter.  You can review the messages in the bug list if
> you're interested:  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531=
]
>
> Andrii Kolomoiets <andreyk.mad@HIDDEN> writes:
>
>> I was planning to remove the eglot-put-doc-in-help-buffer variable in
>> the near future PR as well as the use of the eglot--message function for
>> the documentation display ;-)
>
> I'm guess I'm happy to have shot these plans into the depths of the
> ocean ;-)
>
>> However, after briefly using new Eldoc and Eglot I found some issues
>> that, I hope, we can fix:
>>
>> 1. Display only first line of the hover info.  Again :-)
>
> You should be able to do this with either
>
>    (setq eldoc-echo-area-use-multiline-p 1)
>
> or
>
>    (setq eldoc-echo-area-use-multiline-p nil)
>
> Did you try this? If so, what exactly didn't work for you when you did?
> I'm sorry if you've already given me this information in the multiple
> PR's you opened about this, but let's have it again.
>
>> 2. The hover info is sometimes displayed right before the signature info
>> making the echo area to "blink".  I suppose this must be fixed on Eglot
>> side by not requesting both the hover and the signature infos at the
>> same time.
>
> Not something to be fixed in Eglot, definitely, it's not its fault or
> responsibility: it just reports whatever it has.  I've fixed this in
> Eldoc, in the last commit.  It only affected the "eager" strategy (which
> should really be called the "enthusiast" strategy).  I'll post a commit
> soon using better names for strategies, I'm thinking:
>
> eldoc-documentation-function  -> eldoc-strategy         (with obsolete al=
ias)
> eldoc-documentation-functions -> eldoc-functions        (maybe)
>
> eldoc-documentation-default  -> eldoc-patient
> eldoc-documentation-compose  -> eldoc-compose-patiently
> eldoc-documentation-eager    -> eldoc-enthusiast        (Eglot uses this)
>   <doesn't exist yet>        -> eldoc-compose-eagerly   (Stefan mentioned=
 this)
>
>> 3. That IMO useless "...truncated, see *help* buffer" message is moved
>> to Eldoc.  Do we really need to show this message every time?
>
> I see.  Maybe not _every time_ but at least _once_, I'd say.  Once per
> Eldoc session (but what is an Eldoc session)?  Once per x truncated
> messages?  Customization variable? (I hate those, but maybe).
>
> Or maybe never show it?
>
>> That one last line can be used to show additional documentation.
>> Hadn't a chance to take a closer look at the code, so reporting those
>> issues is the most I can do for now.
>
> Yes, and that's fine for now, though a second pair of eyes in the code
> is certainly appreciated too.
>
> Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
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: Fri, 05 Jun 2020 22:54:01 +0000
Resent-Message-ID: <handler.41531.B41531.15913976393389 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Andrii Kolomoiets <andreyk.mad@HIDDEN>
Cc: mvoteiza@HIDDEN, 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15913976393389
          (code B ref 41531); Fri, 05 Jun 2020 22:54:01 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 22:53:59 +0000
Received: from localhost ([127.0.0.1]:50165 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhLDr-0000sa-HY
	for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 18:53:59 -0400
Received: from mail-wm1-f43.google.com ([209.85.128.43]:50344)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jhLDq-0000sO-9Q
 for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 18:53:58 -0400
Received: by mail-wm1-f43.google.com with SMTP id v19so9767558wmj.0
 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 15:53:58 -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;
 bh=SY8VRQQOBIAfZcVWMXaMNk8SmCKdcyQIl850/POSJ0I=;
 b=h/DOmcByxY0Rq+tuMaq3tLudH6l4e65Ml1h+Xc//5H3ozou2coUTUYUFpgGrNk/gJz
 LFqQR/jx+iGP72hwauY1GRld4JmFR/rZNwHnn71w4/ja2mVMhe/75Sdvpk3HsB+0vsfE
 98vtM3DJuEQERLvM98/41jrIReOdqHKQcLUpV7JyEArJmGDfj+9gmftivnU6UgKGoa3w
 HTQy8agpZuJfrWkRMG/qASungC0Qr5/SmcEAvIUrFMiicJIRo3Zp8m/1nRqlLOyIiWJL
 3LCTszRW1dRqQQ8eH90AZH5Oal7BZAaezTxeBNcmxr7wUFyOMyaeeqX4JUYEETQ5JNk9
 tPIg==
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;
 bh=SY8VRQQOBIAfZcVWMXaMNk8SmCKdcyQIl850/POSJ0I=;
 b=IbKdVXxRP6++yLD9LOVT0ben8F25tO1XGHw60d9/yVeM8ru/bbrKxPRb9rJ3NMZcdI
 qSIGYwEsvGB8uzXRZlKNIbKzP6tik0tiQ2V/BelX4XNbOgQ/Ne1d+cGgnZk0Ul96aMdQ
 wLsg7PTq1CNIx4ug9W5Lob/hMbS8WpA+i2KKBe26NhAD71RWAsto0UL2zPcTuMuy/vzL
 KHOc/gtg6pUPnH9zaNrktQEbL5X+7ScQPL/5aMA4/qtK/pnISFI2qpVX0r9s2UcP20+F
 8uX/gqBLGC7cQUiZuOMaHJaN6xxx8Vu9wpRg8/6jP1flIU88Ar562MJSUaE7foaEBOY5
 evMg==
X-Gm-Message-State: AOAM5338WWg3PdXic6ZdVcIW6iV6vHKa/noS1OtsXy95nKWs+mHY2A2k
 vdZ0zMtoyLusabM3cB9R5pk=
X-Google-Smtp-Source: ABdhPJzjboyWNYrHT8WgXDCB+vtk3/GrTgB9bOC5KNk6CPO2bQ2VIDoQ7eQKvyxHWLvKhidKJhSUCQ==
X-Received: by 2002:a7b:c04f:: with SMTP id u15mr4769383wmc.98.1591397632221; 
 Fri, 05 Jun 2020 15:53:52 -0700 (PDT)
Received: from krug ([89.180.147.39])
 by smtp.gmail.com with ESMTPSA id y66sm13221532wmy.24.2020.06.05.15.53.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Jun 2020 15:53:51 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
 <e2945b44-3a63-6d7e-4adb-1c1228ca488f@HIDDEN>
 <m2lfl21wsq.fsf@HIDDEN>
Date: Fri, 05 Jun 2020 23:53:49 +0100
In-Reply-To: <m2lfl21wsq.fsf@HIDDEN> (Andrii Kolomoiets's message of "Thu, 
 04 Jun 2020 22:00:05 +0300")
Message-ID: <87k10ljf9e.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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 (-)

Andrii Kolomoiets <andreyk.mad@HIDDEN> writes:

> Dmitry Gutov <dgutov@HIDDEN> writes:
>> On 04.06.2020 19:20, Andrii Kolomoiets wrote:
>>> 3. That IMO useless "...truncated, see*help*  buffer" message is moved
>>> to Eldoc.  Do we really need to show this message every time?  That one
>>> last line can be used to show additional documentation.
>> The truncation can be indicated as ellipsis at the end of the (first)
>> line. Maybe ellipsis in parentheses (...).
>
> Good idea.

I think is is easily missed, and will not inform of the keybinding for
`eldoc-doc-buffer'.  But it's clearly better than nothing for the
strictly-one-line people.

>> Whether to use multiple lines of not, seems like individual preference.
>
> Absolutely.  That's why there are customizable variables so anyone can
> tweak behavior to their likes.  Current version of Eglot pays attention
> to the eldoc-echo-area-use-multiline-p variable and proposed one do
> not.

It does not because most of that variable (except for the very special
"truncate-sym-name-if-fit" value) is now handled in eldoc.el.  Modulo
bugs, of course, which I will endeavour to fix.  I also agree, of course
this is individual preference.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
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: Fri, 05 Jun 2020 23:27:02 +0000
Resent-Message-ID: <handler.41531.B41531.15913995686640 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Theodor Thornhill <theothornhill@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad@HIDDEN>, mvoteiza@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, Fredrik Bergroth <fbergroth@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15913995686640
          (code B ref 41531); Fri, 05 Jun 2020 23:27:02 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 23:26:08 +0000
Received: from localhost ([127.0.0.1]:50325 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhLix-0001j2-Sd
	for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 19:26:08 -0400
Received: from mail-wr1-f44.google.com ([209.85.221.44]:37144)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jhLiw-0001iX-6E
 for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 19:26:06 -0400
Received: by mail-wr1-f44.google.com with SMTP id x13so11301831wrv.4
 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 16:26:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:in-reply-to:references:user-agent:date
 :message-id:mime-version:content-transfer-encoding;
 bh=5RoegJxkV05gWENSCdtH9Jxl2IdE6g7mXtYCzoCFDMo=;
 b=pwfxlDYsQ1gWgx75N5UKKdZadJrTyvZbV9eB4moEJwYvz+GXcEvTKqWU1jsZVPEO9n
 hP5wCl+Xj/B29Uml0ChAZcMQoR7GZLfacvaXiDJT+GmxTeA5tWChkXYqyEjqu1xrjT7L
 K1MbbmO8PNnOp+c0/JozVkRJyQmkxAsAekz8Iqlo8glh7MBofIAeYQo0lV262uEsytRv
 PIQDKOgQkkRt+IysodY1Ie6+ZYYuftqLjpNeMpzvFOAGPB6X9MnNp8OgC9uTvoLv/0Aj
 ocISFNY9nifueb6AtmO8kagNNKD2jlMrBps8SqzTTt2Bp4dIDc+ZuyZF7Bn6q2INKtky
 469A==
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:in-reply-to:references
 :user-agent:date:message-id:mime-version:content-transfer-encoding;
 bh=5RoegJxkV05gWENSCdtH9Jxl2IdE6g7mXtYCzoCFDMo=;
 b=NZoNUBlI6w2ui9YUxKQJglZBgFZ68/5zeWrsHqBuCXBvjNQEyDSI83Ww/3PRKGipUY
 dGwXn/qQnOhJcD+fRgLQ/SO0QQDkx/E0VnPnoizyAD3tjINHnPg3wK9PKq22Yx7BVGWH
 pFnYIImJhkxv/6zvx/J9dZfMvnwmB2ho4MQUGORPGUKzPPieogLFWmkQF3F6lmtFAHva
 +ca+4XESPMxGrChXSEk9gMZsx7rnoiir2sGEnprxsq9wpzxKcEZ+3w0LzXPS3iDDyg5s
 8kr1MaQukQCZxeSLZZde9jlR97pRvfjmbu16WdlvEGP/69Vvwsiuv1KcISpJexGfjzmq
 3n4A==
X-Gm-Message-State: AOAM533r+EsifAvsds/FPUDRxSNgvdNzf3Rawd7P32hjcaV39SIJsc4d
 BSGUQjH+Ac2ciKF5L2cukw0=
X-Google-Smtp-Source: ABdhPJyQI/cv3M1TNXVQDZ1YKvxC/92c3atpzNylXIbz8f3nQt46pkxWC84fCek2+PANz8s4owGvYw==
X-Received: by 2002:adf:f44b:: with SMTP id f11mr11645465wrp.165.1591399560210; 
 Fri, 05 Jun 2020 16:26:00 -0700 (PDT)
Received: from krug (89-180-151-23.net.novis.pt. [89.180.151.23])
 by smtp.gmail.com with ESMTPSA id c65sm13442797wme.8.2020.06.05.16.25.41
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Jun 2020 16:25:59 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87img55rmm.fsf@HIDDEN> (Theodor Thornhill's message of
 "Fri, 05 Jun 2020 17:50:38 +0000")
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
 <87img5lqty.fsf@HIDDEN> <87img55rmm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Date: Sat, 06 Jun 2020 00:25:34 +0100
Message-ID: <877dwljdsh.fsf@HIDDEN>
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 (-)

Theodor Thornhill <theothornhill@HIDDEN> writes:

> Bug 1:=20=20=20=20=20=20
> 1. Open a file
> 2. Start eglot
> 3. Hover something with "C-h ."
> 4. Switch to the new window that popped up.
> 5. C-x k (kill buffer)
> 6. Repeat step 3.
> 7. "invalid buffer" and eldoc is dead.=20
> 8. Starting and stopping eldoc doesn't work=20=20=20
>
> This seems to happen since it uses the new buffer and updates it. When th=
at buffer is deleted, it gets confused.

Thanks.  This is easy to fix.  It's a buffer-live-p call somewhere.

> Bug 2:
> 1. (setq eldoc-echo-area-use-multiline-p nil)
> 2. eglot spits the whole thing on one line. This looks a bit weird since =
it uses both the signature and the documentation.
>
> This may not be a bug, but right now IMO it looks a bit strange.

It was intended.  But I agree it's not good.  I will change it: instead
of joining all lines, then trucating, I will just truncate the first
line if needed.

> Bug 3:
> 1. "M-:"
> 2. Type "("
> 3. Minibuffer shows: eldoc-error: (wrong number of arguments (0 . 0) 1)

I couldn't reproduce this one.

> I think the first bug is the most problematic one though :)
>
> However, I've started to take a liking to the no options set, with
> this version. I think I like the "truncate, press M-x ..." message
> more than the previous one.

Yes, and if `eldoc-doc-buffer` is bound to something shorter, then it
will be even simpler to read.  I will eventually recommend we rebind
`C-h .` (display-local-help) to it.  But in the meantime, I think I will
make Eglot bind it to that key, as an exception to Eglot's
no-keybindings policy.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
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: Fri, 05 Jun 2020 23:29:01 +0000
Resent-Message-ID: <handler.41531.B41531.15913996956852 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Theodor Thornhill <theothornhill@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Andrii Kolomoiets <andreyk.mad@HIDDEN>, mvoteiza@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, Fredrik Bergroth <fbergroth@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15913996956852
          (code B ref 41531); Fri, 05 Jun 2020 23:29:01 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jun 2020 23:28:15 +0000
Received: from localhost ([127.0.0.1]:50338 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhLl1-0001mS-5L
	for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 19:28:15 -0400
Received: from mail-wm1-f47.google.com ([209.85.128.47]:39382)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jhLkz-0001mF-LJ
 for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 19:28:13 -0400
Received: by mail-wm1-f47.google.com with SMTP id k26so10577955wmi.4
 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 16:28:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:in-reply-to:references:user-agent:date
 :message-id:mime-version:content-transfer-encoding;
 bh=5RoegJxkV05gWENSCdtH9Jxl2IdE6g7mXtYCzoCFDMo=;
 b=IQYazU0xKJNlbKSwX5diUO5+2yno17srluZzz045ssfKhXeDZERbIYQpVyi2lwDVlb
 WMujL67FgNQyA0go3iXpyzcNlvONZhLACjdxi6j6wWimLT/F2hE0puJvZRiibBGGOoMM
 lbvpbzuofI6CddK3ReuUE0koZKK5i6hTFeYiUR4Zu2B8t+WUON+ekW9Yo37PE2ZhLh6y
 dZW0fFS8Z39Bqb7KP2x2QfDj+EMBGkU3S1tJ3aeS0unbUrjYqT53MheDVheznoPT3SX2
 I2GYd1VhSoJ30OtJtU8S2n/TSUJ9GsamvQW2ZJmxgFWT2zzJs5WpMIIDRljRCnCb00sd
 RzGg==
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:in-reply-to:references
 :user-agent:date:message-id:mime-version:content-transfer-encoding;
 bh=5RoegJxkV05gWENSCdtH9Jxl2IdE6g7mXtYCzoCFDMo=;
 b=BF1iQA9hkzc0/V2uWqpC/nCEW2628rfxEXivJIRgbTIa2ji343QJjn7+vngo6ueY2k
 q1wxAZlx++n2w+Tir0267Ng7GGnz3Et1atkn/pEhOi6CMTKC6Sfi0nja40qWUclQdyYM
 fKNe9SmYGaErDb3Zq1kAQf8SuTpRJBXrR6pfx4FUbg2H7Ar/NCt3kEsOaF0HVwPvwo8U
 HNNWeSL6Wq3SuNJDwkQ8l46D8yd0zTLWQcILjbtu2JURoNbRFLjvxz95u3yi4Qa/jIKI
 ljA4dY+6z5H7sdVBxRifTaXAGRfgZAR0+vNgFFZ9/p7CQElppSRdSO61hUbVrTeUuxmL
 2EMQ==
X-Gm-Message-State: AOAM530iSMSkyCjRhQHybNdt7VLRM9cOBC2qZjK29t+y8pF9kCy631+U
 80dRIO145XWdTvUOYesqDhU=
X-Google-Smtp-Source: ABdhPJx7NXKRUVDOAJ3kIT+7LHVrTEJsaveZZwN39NmieTwDLAVc6nPqvRaVZ4CmKSP15kSoJ5bemg==
X-Received: by 2002:a1c:f401:: with SMTP id z1mr4696647wma.44.1591399687875;
 Fri, 05 Jun 2020 16:28:07 -0700 (PDT)
Received: from krug ([89.180.147.39])
 by smtp.gmail.com with ESMTPSA id a1sm12851031wmj.29.2020.06.05.16.28.06
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Fri, 05 Jun 2020 16:28:07 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <87img55rmm.fsf@HIDDEN> (Theodor Thornhill's message of
 "Fri, 05 Jun 2020 17:50:38 +0000")
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
 <87img5lqty.fsf@HIDDEN> <87img55rmm.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Date: Sat, 06 Jun 2020 00:28:05 +0100
Message-ID: <874krpjdoa.fsf@HIDDEN>
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 (-)

Theodor Thornhill <theothornhill@HIDDEN> writes:

> Bug 1:=20=20=20=20=20=20
> 1. Open a file
> 2. Start eglot
> 3. Hover something with "C-h ."
> 4. Switch to the new window that popped up.
> 5. C-x k (kill buffer)
> 6. Repeat step 3.
> 7. "invalid buffer" and eldoc is dead.=20
> 8. Starting and stopping eldoc doesn't work=20=20=20
>
> This seems to happen since it uses the new buffer and updates it. When th=
at buffer is deleted, it gets confused.

Thanks.  This is easy to fix.  It's a buffer-live-p call somewhere.

> Bug 2:
> 1. (setq eldoc-echo-area-use-multiline-p nil)
> 2. eglot spits the whole thing on one line. This looks a bit weird since =
it uses both the signature and the documentation.
>
> This may not be a bug, but right now IMO it looks a bit strange.

It was intended.  But I agree it's not good.  I will change it: instead
of joining all lines, then trucating, I will just truncate the first
line if needed.

> Bug 3:
> 1. "M-:"
> 2. Type "("
> 3. Minibuffer shows: eldoc-error: (wrong number of arguments (0 . 0) 1)

I couldn't reproduce this one.

> I think the first bug is the most problematic one though :)
>
> However, I've started to take a liking to the no options set, with
> this version. I think I like the "truncate, press M-x ..." message
> more than the previous one.

Yes, and if `eldoc-doc-buffer` is bound to something shorter, then it
will be even simpler to read.  I will eventually recommend we rebind
`C-h .` (display-local-help) to it.  But in the meantime, I think I will
make Eglot bind it to that key, as an exception to Eglot's
no-keybindings policy.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Sat, 06 Jun 2020 01:58:01 +0000
Resent-Message-ID: <handler.41531.B41531.159140866120298 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159140866120298
          (code B ref 41531); Sat, 06 Jun 2020 01:58:01 +0000
Received: (at 41531) by debbugs.gnu.org; 6 Jun 2020 01:57:41 +0000
Received: from localhost ([127.0.0.1]:50427 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jhO5c-0005HK-Vc
	for submit <at> debbugs.gnu.org; Fri, 05 Jun 2020 21:57:41 -0400
Received: from mail-wm1-f49.google.com ([209.85.128.49]:35010)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jhO5a-0005H6-6z
 for 41531 <at> debbugs.gnu.org; Fri, 05 Jun 2020 21:57:38 -0400
Received: by mail-wm1-f49.google.com with SMTP id q25so10794506wmj.0
 for <41531 <at> debbugs.gnu.org>; Fri, 05 Jun 2020 18:57:38 -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;
 bh=JGJgGG+LBCJdCbud5Cx4q8YSPWzILkaDeg+hAAZJMRE=;
 b=lcmSRfiMZjMr3vST+jWxriHxlUVQG2+gZCvGaPClRyQe+JnfqSPXZLz8eCIhnBIMGg
 CcXgr4XAP7f4zaooJKjLr2Rj/BFsTtzR271wC+2bNmBihDIvb45v4PBPfp/50U/b+L+r
 pu5Y0f/O7eiIf1k5TxLyJvpn/C0hi/TUnDhMS4apd+wMSZceyEaDRjMJKQnTjZA7BHpg
 S8Et7qJbsQDD7GMf8JXvanUH9pmCZcb+L01gUzBkqcoCEWd6I+2/CyzYYbhe0ZrAy+zc
 ZIjMlgUB4v5+jBCbbC+0gucoIHITwQvozKPu2S/MqsYgvYh0dpxbGqn58SsWQDPRYqDw
 oBiQ==
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;
 bh=JGJgGG+LBCJdCbud5Cx4q8YSPWzILkaDeg+hAAZJMRE=;
 b=miDVpQGaBhRN+iCtX4i3+WdxyMsZQLHwnx5Eil8mriXZx4WWT+pszdZbmm5jZmfwXJ
 +SbTVOCs54sccmjITeMNoA8E1R13Thy5hDKWrjsiaLWM7q06xXfSwgJ6qgY4FXI2h3Pk
 hpQnfCatm20/VWP63G5eckAofywhv3EboFatuNevOHcjOqfvuJ+cCZ1/KZjBDDxv9Hwj
 5C/6Pgl++id4RKiTc2BmbEBCAR+KB5HMKFvfaJ5TI/ir7c1OLT3xjcmtLZv/PP8kaHAn
 0H2eOsnUTM+wRjtGXzNUG0WPF0AbhUJmU/2qZNjEucp0rH9qM6sRQ8Wn0UjZmgGK1kVO
 kKOQ==
X-Gm-Message-State: AOAM533BoCq1CXqPUz6VjO0N+5VeYs08tRXjUGtQWegwXy/b8VuIaKKD
 rZA57UMpO98AukfrbB/65Uk=
X-Google-Smtp-Source: ABdhPJxqYUTqywXBM9fu26E3JPtCr7wTBylDzHSd8cwTVgFjDzHVaUPXbK7AQQ364CbG6X0ohAXKlA==
X-Received: by 2002:a1c:c2d6:: with SMTP id s205mr5606798wmf.140.1591408652319; 
 Fri, 05 Jun 2020 18:57:32 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id l18sm12646226wmj.22.2020.06.05.18.57.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Fri, 05 Jun 2020 18:57:30 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN>
 <4987863b-d390-5f87-eb1c-2cca4f4b7262@HIDDEN>
 <jwv367nqv52.fsf-monnier+emacs@HIDDEN> <87blmbrlda.fsf@HIDDEN>
 <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <63d261d3-62e5-8c60-f191-8734aa37752b@HIDDEN>
Date: Sat, 6 Jun 2020 04:57:29 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <jwvzh9u4uju.fsf-monnier+emacs@HIDDEN>
Content-Type: multipart/mixed; boundary="------------05307B20715A0076A57CEA31"
Content-Language: en-US
X-Spam-Score: 0.5 (/)
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: -0.5 (/)

This is a multi-part message in MIME format.
--------------05307B20715A0076A57CEA31
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi!

On 26.05.2020 17:53, Stefan Monnier wrote:
>> But really: now we have deadlock too?  I just want to solve this
>> problem: please let's commit something, and move on to the next bug.
> Can you use the sample `eldoc-future-*` code I sent earlier?

How about the attached file for a rough, but a largely feature complete 
first version of futures?

To remind from previous discussions, we wanted futures:

- To be cancelable, so that the issuer could abort their calculations, 
if they so desire.
- Force-able, meaning the consumer should be able to "realize" the 
future synchronously, with the future's creator being able to support 
their, most optimal, version of that logic. The default needs to be 
useful and reliable enough, though, that callers could use it in 99% of 
cases anyway.

The error callback probably wasn't mentioned, but it seems logical to 
have it anyway.

For the first two features, I also considered using cl-generic, but 
result might turn out to be clunkier, and we need overridability only 
for two of these functions. But suggestions welcome.

TBD:

- Probably rename to "promises" in the end.
- It would be nice to have a certain degree of compatibility with 
Christopher Wellons's emacs-aio, so that its promises could be accepted 
by code that expects "our" futures/promises. Not sure if we can do that 
without making the API more complex (aio-resolve's signature comes to 
mind), or if we adopt its approach, importing the package wholesale 
might make more sense.

--------------05307B20715A0076A57CEA31
Content-Type: text/x-emacs-lisp; charset=UTF-8;
 name="future.el"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="future.el"

;;; future.el --- Futures, a concurrency primitive   -*- lexical-binding: t; -*-

;; Copyright (C) 2020  Dmitry Gutov

;; Author: Dmitry Gutov <dgutov@HIDDEN>
;; Keywords: lisp

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <https://www.gnu.org/licenses/>.

;;; Commentary:

;;

;;; Code:

(require 'cl-lib)

(cl-defstruct (future
               (:conc-name future--)
               (:constructor future-make (&key force-fn
                                               cancel-fn)))
  "This structure represents a \"future\" value."
  value
  error
  (status 'pending)
  (force-fn #'future-force--apo)
  (cancel-fn #'ignore)
  callback
  errback)

(defun future-force (f)
  (funcall (future--force-fn f)))

(defun future-force--apo (f)
  (while (eq (future--status f) 'pending)
    (accept-process-output nil 0.05)))

(defun future-cancel (f)
  (when (eq (future--status f) 'pending)
    (setf (future--status f) 'canceled)
    (funcall (future--cancel-fn f))))

(defun future-set (f v)
  ;; FIXME: Probably shouldn't error on 'canceled'.
  (cl-assert (eq (future--status f) 'pending))
  (setf (future--value f) v
        (future--status f) 'success)
  (when (future--callback f)
    (funcall (future--callback f) v)))

(defun future-error (f e)
  ;; FIXME: Probably shouldn't error on 'canceled'.
  (cl-assert (eq (future--status f) 'pending))
  (setf (future--error f) e
        (future--status f) 'error)
  (when (future--errback f)
    (funcall (future--errback f) e)))

;; Or we can make these both lists of functions...
(defun future-set-callback (f c)
  (cl-assert (null (future--callback f)))
  (setf (future--callback f) c)
  (when (eq (future--status f) 'success)
    (funcall c (future--value f))))

;; ...and rename to -add-callback/-add-errback.
(defun future-set-errback (f c)
  (cl-assert (null (future--errback f)))
  (setf (future--errback f) c)
  (when (eq (future--status f) 'error)
    (funcall c (future--error f))))

(provide 'future)
;;; future.el ends here

--------------05307B20715A0076A57CEA31--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 28.0.50; proper Eldoc async support
Resent-From: Andrii Kolomoiets <andreyk.mad@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 11 Jun 2020 11:12:01 +0000
Resent-Message-ID: <handler.41531.B41531.159187390917919 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, theothornhill@HIDDEN, mvoteiza@HIDDEN, Stefan Monnier <monnier@HIDDEN>, Dmitry Gutov <dgutov@HIDDEN>, Fredrik Bergroth <fbergroth@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159187390917919
          (code B ref 41531); Thu, 11 Jun 2020 11:12:01 +0000
Received: (at 41531) by debbugs.gnu.org; 11 Jun 2020 11:11:49 +0000
Received: from localhost ([127.0.0.1]:36127 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jjL7d-0004ex-Je
	for submit <at> debbugs.gnu.org; Thu, 11 Jun 2020 07:11:49 -0400
Received: from mail-lj1-f193.google.com ([209.85.208.193]:37526)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <andreyk.mad@HIDDEN>) id 1jjL7b-0004ej-Ra
 for 41531 <at> debbugs.gnu.org; Thu, 11 Jun 2020 07:11:48 -0400
Received: by mail-lj1-f193.google.com with SMTP id e4so6433729ljn.4
 for <41531 <at> debbugs.gnu.org>; Thu, 11 Jun 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=sYeVq2pd5RoGtD/W8xpKWgT7IBEGsOZb6ldNsVlJjwc=;
 b=PLfIEIu+wt1cvMgwp6LEYaTnz3G9fNCFpyiaDtCGPw944w4RR+nm9tMVlob/3dsBa7
 e/Qa79TLDM753DxsXMTagcQ71Zi4HZGwg+T/eCfOhgrOYe/rcfzl7gxGKYiMQK2Bd4Lq
 /+TN5B+xS8Uy05brqbwOKn+RshSniDTW8ziZmau22kxGF6mRqRfrHBa6qQan4UgVY4P+
 KlumQUlDLj3rUDKVI7zk7WdlwIG3TmtTEwNtx0t6KAWbm1+4zyJHVtTxsA6LGwAINOq9
 v5nzL6ks+BXSxQWBaO50CKJLD1qCPDrrdexosz47FHFsOIe8wRaPWzxncazIORo5V0pU
 ZYDg==
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=sYeVq2pd5RoGtD/W8xpKWgT7IBEGsOZb6ldNsVlJjwc=;
 b=K8PwXrhQWQ1Bmxt0FWcfroZD6B0TDZGCohLJb+CC4HEDdYRO+UHGtKn5pX6kcf26dY
 4LMTbyBxizmKeJ6AOIeg9uaPy2OTe6mp6655Fv3dTbpXCaKblwA5MPmARKRNSgVgNGWe
 x0MUSrvm7JaQuGrmOmcmG5hBLbGNE9K8wH7C5aGr+V4lPRxIdAbqMCvlDUAPP+lz7wp5
 9JkbM9AJQhneVSbffYbYo9bF+9ik1cIA+e1ovRn1jYq4jbIkHuO2t+/SwSpsyA6wWkvP
 95TPRfvbEQIxfzUajsdblLri8EWAn7z7mcnQUDeIcs1JVaB7y6jC1FsOnpeHgIUqZyjo
 FiLg==
X-Gm-Message-State: AOAM532Mw4z6C1PAtS2cZ4PsVYCe42oSj3aIVgP2Ah+ev4cbhHvh6hov
 L1BwqB+AyeJ78bc8iXAQkgk=
X-Google-Smtp-Source: ABdhPJxxWns3JHqzJjxIfimu3i5ZH74F34gvc3/Ub3MH/Xf1mcQLgd12b6ZXgJPi6tOFbrfTOuIFNQ==
X-Received: by 2002:a2e:b5b9:: with SMTP id f25mr4281775ljn.50.1591873901681; 
 Thu, 11 Jun 2020 04:11:41 -0700 (PDT)
Received: from muffinmac.local ([91.206.110.148])
 by smtp.gmail.com with ESMTPSA id f74sm716399lfd.68.2020.06.11.04.11.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Thu, 11 Jun 2020 04:11:41 -0700 (PDT)
From: Andrii Kolomoiets <andreyk.mad@HIDDEN>
References: <87eeqwm101.fsf@HIDDEN> <m2pnae2462.fsf@HIDDEN>
 <87img5lqty.fsf@HIDDEN>
Date: Thu, 11 Jun 2020 14:11:39 +0300
In-Reply-To: <87img5lqty.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Fri, 05 Jun 2020 12:00:57 +0100")
Message-ID: <m2r1ul26xg.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (darwin)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 3.6 (+++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Sorry for the late reply. =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= writes: >> 1. Display
    only first line of the hover info. Again :-) > > You should be able to do
    this with either > > (setq eldoc-echo-area-use-multiline-p 1) > > or > >
   (setq eldoc-echo-area-use-multiline-p n [...] 
 
 Content analysis details:   (3.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [91.206.110.148 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (andreyk.mad[at]gmail.com)
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.208.193 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.208.193 listed in wl.mailspike.net]
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.6 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  Sorry for the late reply. =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= writes: >> 1. Display
    only first line of the hover info. Again :-) > > You should be able to do
    this with either > > (setq eldoc-echo-area-use-multiline-p 1) > > or > >
   (setq eldoc-echo-area-use-multiline-p n [...] 
 
 Content analysis details:   (2.6 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [91.206.110.148 listed in zen.spamhaus.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [209.85.208.193 listed in wl.mailspike.net]
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
                              no trust
                             [209.85.208.193 listed in list.dnswl.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (andreyk.mad[at]gmail.com)
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

Sorry for the late reply.

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

>> 1. Display only first line of the hover info.  Again :-)
>
> You should be able to do this with either
>
>    (setq eldoc-echo-area-use-multiline-p 1)
>
> or
>
>    (setq eldoc-echo-area-use-multiline-p nil)
>
> Did you try this? If so, what exactly didn't work for you when you
> did?

This way the signature info is truncated.  For the function with many
parameters the info of the last parameters is not visible.=20

>> 2. The hover info is sometimes displayed right before the signature info
>> making the echo area to "blink".  I suppose this must be fixed on Eglot
>> side by not requesting both the hover and the signature infos at the
>> same time.
>
> Not something to be fixed in Eglot, definitely, it's not its fault or
> responsibility: it just reports whatever it has.

According to specification, server may send `triggerCharacters` in the
`SignatureHelpOptions`: the characters that trigger signature help
automatically.  Maybe Eglot should not always request the signature
info.
Though I like the current implementation.

>> 3. That IMO useless "...truncated, see *help* buffer" message is moved
>> to Eldoc.  Do we really need to show this message every time?
>
> I see.  Maybe not _every time_ but at least _once_, I'd say.  Once per
> Eldoc session (but what is an Eldoc session)?  Once per x truncated
> messages?  Customization variable? (I hate those, but maybe).
>
> Or maybe never show it?

Yep. Just like no additional message like "Press C-h v for the full
documentation" is shown hovering the variable in the `emacs-lisp-mode`.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 30 Jun 2020 11:32:02 +0000
Resent-Message-ID: <handler.41531.B41531.159351668222730 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 41531 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159351668222730
          (code B ref 41531); Tue, 30 Jun 2020 11:32:02 +0000
Received: (at 41531) by debbugs.gnu.org; 30 Jun 2020 11:31:22 +0000
Received: from localhost ([127.0.0.1]:50342 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jqETy-0005uA-0G
	for submit <at> debbugs.gnu.org; Tue, 30 Jun 2020 07:31:22 -0400
Received: from mail-wm1-f67.google.com ([209.85.128.67]:37216)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jqETv-0005oF-Sf
 for 41531 <at> debbugs.gnu.org; Tue, 30 Jun 2020 07:31:21 -0400
Received: by mail-wm1-f67.google.com with SMTP id o2so19250802wmh.2
 for <41531 <at> debbugs.gnu.org>; Tue, 30 Jun 2020 04:31:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=from:to:cc:subject:in-reply-to:references:user-agent:date
 :message-id:mime-version:content-transfer-encoding;
 bh=LVuAsIci5xxFQPp0JLCOkrOuIMwzgb8Nsyc0ubuUT+k=;
 b=hk3GCQO5/2nLJ3JilndH7UkgrJjFKJ4c3OfrNcssSBv1BKwTx0NCzutMbR3kSnCOe0
 C3Wqg/lKsoA16JOt0R2JgcBq5sDTy0nVcPEiFw9vvEmmDsoBIG5kcw9V12KV07X7Xoas
 GmehTrl3KZaG2Wr8buzHTg4bHL8hYtquJBd2a57aeE1AL6dAqoYMYj68PeFwky3Yl37q
 uqSi0PjVQoB+0Q8uJP8fojzv/DjZWd7c3hH+BTRdvfE7fraSWyVy+OOyxqQZS8Xx6Lti
 tAyMHP3ixMbMQvlcwPdvYwv6vefdM/OxnXH0MbJ9dtC9gG496Q5bFgSGR03zt0y7Z2PJ
 nFkQ==
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:in-reply-to:references
 :user-agent:date:message-id:mime-version:content-transfer-encoding;
 bh=LVuAsIci5xxFQPp0JLCOkrOuIMwzgb8Nsyc0ubuUT+k=;
 b=GMEH+8V/IJ2nEmZ204xZ3SBWIoiOoB184xwxeoi7DZXHX/W1el7Kt1dvx0k6LZ1kk6
 pSnrS1a0qGYgxdr8ZEktRjt+SkWXKWjLu1bfbjlQ7Nu/N0YaVdPG+6hwZcls1hcjdyPS
 3E2lUXA/an7VCAkhhggCKs67Ef1rHVjHE9/FpEtxFnmLZucffUfJY4XrFA1Q8xmJBSmf
 B7gzxiCi+72fbsVtIYBZPEHFNq4pl7+Kq2bimZSanRTA0gUIiubSa+Is7kYTSwPJHzQl
 GLF5LCjiHo2PR5z0WkaKYMJqqfDILus9TGg3/Ssz36kHP51s0qG6pTHtRH0eMJ9Z/lQC
 FJ/g==
X-Gm-Message-State: AOAM531eWqaxR22WJWmTjvKkp/JoBd2Qi9rCCUK1kg8QM7uYh4TMmJX4
 yCGYzwBoZ2laQAZXJ4zctcM=
X-Google-Smtp-Source: ABdhPJwWdBhoy0gYLj6ujuzd2qc5rAXZT4ZNIQy3xQ+ZlWJVlLth1HQmQonS1Uf4M303FJSRHCF/JQ==
X-Received: by 2002:a1c:345:: with SMTP id 66mr6053391wmd.31.1593516673946;
 Tue, 30 Jun 2020 04:31:13 -0700 (PDT)
Received: from krug ([89.180.148.126])
 by smtp.gmail.com with ESMTPSA id g16sm3696913wrh.91.2020.06.30.04.31.12
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 30 Jun 2020 04:31:12 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
In-Reply-To: <875zckuet9.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Mon, 25 May 2020 18:04:02 +0100")
References: <875zckuet9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
Date: Tue, 30 Jun 2020 12:31:10 +0100
Message-ID: <87sgecssch.fsf@HIDDEN>
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 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> Hi Stefan, Dmitry, Andrii and maintainers,
>
> Moving the discussion that started in
> https://github.com/joaotavora/eglot/pull/459 to the bug tracker, and
> attaching the two patches that contain what I think is a decent
> short-term solution to the eldoc/async problems.

Hello again,

The work that started with this discussion is now mostly complete.  It
has been sitting in the scratch/eldoc-async branch of the Savannah repo
for a while, but I've been very busy and didn't have time to annouce it.

I've cleaned it up to to a four commit effort which.

    99fd115a8c Make more parts of Emacs use new Eldoc capabilities
    aaf5dfc71e * lisp/emacs-lisp/eldoc.el (Version): Bump to 1.1.0
    62dc1d4824 New M-x eldoc for on-demand and interactive documentation re=
quests
    6c54414d5f Better handle asynchronous Eldoc sources

I had good feedback on and off-list about it.  It works with a version
of Eglot in its scratch/work-with-new-eldoc branch.

There is of course a lot that can still be fixed or added, especially in
the domain of controlling the outlets for documentation (which now are
restricted to the echo area, and poorly formatted buffer).

Anyway I think my efforts are ready to push to master.  I'll do so soon
unless someone raises a serious problem about it.

Dmitry has expressed his intent to make the new eldoc.el work with a new
futures/promises library.  He prototyped one of those libraries.  I have
nothing against that in the future.  However,

1. I don't have the resources to make the eldoc.el prototype work with
   Dmitry's or other libraries;

2. We should revisit the purpose and the details of that and other
   libraries in a separate discussion.  For now it's high time we
   advance the Eldoc libray;.

Thanks,
Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 07:46:01 +0000
Resent-Message-ID: <handler.41531.B41531.15938487213312 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15938487213312
          (code B ref 41531); Sat, 04 Jul 2020 07:46:01 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 07:45:21 +0000
Received: from localhost ([127.0.0.1]:57988 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrcrR-0000rM-1M
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 03:45:21 -0400
Received: from eggs.gnu.org ([209.51.188.92]:60188)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1jrcrN-0000r6-Mb
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 03:45:19 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:59655)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1jrcrF-00009f-Nm; Sat, 04 Jul 2020 03:45:10 -0400
Received: from [176.228.60.248] (port=1618 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 1jrcrC-0002ah-OP; Sat, 04 Jul 2020 03:45:08 -0400
Date: Sat, 04 Jul 2020 10:45:07 +0300
Message-Id: <83k0zjvi4c.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87sgecssch.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Tue, 30 Jun 2020 12:31:10 +0100)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.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>
> Date: Tue, 30 Jun 2020 12:31:10 +0100
> Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN,
>  Dmitry Gutov <dgutov@HIDDEN>
> 
> The work that started with this discussion is now mostly complete.  It
> has been sitting in the scratch/eldoc-async branch of the Savannah repo
> for a while, but I've been very busy and didn't have time to annouce it.

Thanks.

> Anyway I think my efforts are ready to push to master.  I'll do so soon
> unless someone raises a serious problem about it.

Not a serious problem, but some comments:

> -(defun eldoc-message (&optional string)
> +(make-obsolete
> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0")

Isn't the version part of the obsolete message supposed to tell the
version of Emacs?

The change to the number of arguments of the functions in the
eldoc-documentation-functions hook is backward-incompatible, isn't it?
I see you've changed the relevant functions in our sources, but what
about 3rd-party packages?

Also, the doc string of this hook needs clarification regarding the
arguments: it first says that CALLBACK is the only mandatory argument
to the hook functions, but then, out of the blue, appear additional
arguments DOCSTRING and a list of key-value pairs.  Confusing.

The doc strings have some words in UK English spelling "(e.g.,
"honour"), please fix that.  Also, please make sure comments all start
with a capital letter, end with a period, and comprise full English
sentences.

The doc string of eldoc-documentation-compose doesn't say a word about
the function's argument.

In the doc string of eldoc-documentation-strategy, you use the phrase
"queries the special hook for all functions that produce doc strings"
to mean, AFAIU, that the specified functions in the hook-variable list
are called.  IMO, this wording could be confusing; suggest to use this
instead:

  `eldoc-documentation-compose': calls all the functions in the hook,
  and displays all of the resulting doc strings ...

This doc string doesn't explain the use of the timer, it explains the
reason for its existence.  It should also describe the use:

> +(defvar eldoc--enthusiasm-curbing-timer nil
> +  "Timer used by `eldoc-documentation-enthusiast' to avoid blinking.")

Last, but not least: the "async" part of the branch's name hints on
some advanced and extremely useful functionality that these changes
are supposed to allow, but I see no mention of that in NEWS and in the
manual bits.  What did I miss?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 09:22:01 +0000
Resent-Message-ID: <handler.41531.B41531.159385451912348 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159385451912348
          (code B ref 41531); Sat, 04 Jul 2020 09:22:01 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 09:21:59 +0000
Received: from localhost ([127.0.0.1]:58051 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jreMx-0003D4-BY
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:21:59 -0400
Received: from mail-io1-f50.google.com ([209.85.166.50]:38071)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jreMv-0003Cs-4w
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:21:57 -0400
Received: by mail-io1-f50.google.com with SMTP id f6so19041948ioj.5
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 02:21:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=B8tYZnjh4Ij0tuHzim3NUUigGwD8Yj54B/Cp6F7Zlfg=;
 b=GyFiVIULbm72Q1DjuI52B1FKT/hERS2h+AYg+2meFTX6g8MyfWgnuTURZyBzw9e1Tj
 fGFGUfdNsgUpeHX6awYZxRZBsWrZkBsKO1b5KmXVzC1W0Op9UcjottSSrctTP7kcVpIq
 6qLe1Bv1LkL0AJiaRMbugeNyQFseY6sME6rFGltWUu9py6Cly/oWHawvnV2hKYs85nP4
 6SItKrxlVAzYhm5pBsCSJc9itE82h6z//WzC3HkwXJ8vAdRYHZ8VmK1+Qf69kdFnzb8E
 w2BKVLjq2P06Hpz7DrZ+7mAnAzhrhShw+cwPA/Cz+34nR8BUKE+BEdsMw931QSfT9tGS
 EU/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=B8tYZnjh4Ij0tuHzim3NUUigGwD8Yj54B/Cp6F7Zlfg=;
 b=UwTuG8ht7DCel4QTp/vUOIqSOWCAy/2QtCCtTH1gNsmaf8sMmcEJrGG6VqpINj/0cK
 Yu0qobCKn2u16a27o2/DmLBWvO48exL6mK0En9VBPcuhDfHs6/pKs83ywlsR9Hto+UFB
 g4xtl4AWhJRwaS+q/ahljun4umzmgdU8+UlvNHkSrGewXT7SWrAmK6IGsEZkEsSX7ori
 ND4DIeWLcf9DGcOOQIg/7BnSfv3RwNCT1UKMB4tkCtGLJhGNJZ4EWywPMhVIGzlaMKIm
 JcHFj0CbzX4yBDnCj+DqmOwuB8miMyNJ+O59O25F1ah1K9HE529gmymLEOAkakMSRD4U
 PcwA==
X-Gm-Message-State: AOAM531pif/rBVFtZTC/AJZuF0l6xXMkFd3QMBe9YZ4cRwVkxtaHsGIc
 cWGQSQKZmraRHlbbIai+Ss7PZFvSR/99RV/+bMA=
X-Google-Smtp-Source: ABdhPJy1HD0q4aGulmElEXSnhPaFHvzBP5ErCHx9Rkj9zsdo48Gbtm1FHsgQq7NZsZ81K4sijURAhnFSIPIVi9snM7Y=
X-Received: by 2002:a02:9642:: with SMTP id c60mr42634940jai.71.1593854510393; 
 Sat, 04 Jul 2020 02:21:50 -0700 (PDT)
MIME-Version: 1.0
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN>
In-Reply-To: <83k0zjvi4c.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Sat, 4 Jul 2020 10:21:43 +0100
Message-ID: <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000ea6e9b05a99a2bab"
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: -1.0 (-)

--000000000000ea6e9b05a99a2bab
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback, Eli.

I'll get to each point later on. But I'm surprised the NEWS entry I had
written got lost. In the git rebasing, maybe.

Jo=C3=A3o

On Sat, Jul 4, 2020, 08:45 Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> > Date: Tue, 30 Jun 2020 12:31:10 +0100
> > Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN,
> >  Dmitry Gutov <dgutov@HIDDEN>
> >
> > The work that started with this discussion is now mostly complete.  It
> > has been sitting in the scratch/eldoc-async branch of the Savannah repo
> > for a while, but I've been very busy and didn't have time to annouce it=
.
>
> Thanks.
>
> > Anyway I think my efforts are ready to push to master.  I'll do so soon
> > unless someone raises a serious problem about it.
>
> Not a serious problem, but some comments:
>
> > -(defun eldoc-message (&optional string)
> > +(make-obsolete
> > + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0"=
)
>
> Isn't the version part of the obsolete message supposed to tell the
> version of Emacs?
>
> The change to the number of arguments of the functions in the
> eldoc-documentation-functions hook is backward-incompatible, isn't it?
> I see you've changed the relevant functions in our sources, but what
> about 3rd-party packages?
>
> Also, the doc string of this hook needs clarification regarding the
> arguments: it first says that CALLBACK is the only mandatory argument
> to the hook functions, but then, out of the blue, appear additional
> arguments DOCSTRING and a list of key-value pairs.  Confusing.
>
> The doc strings have some words in UK English spelling "(e.g.,
> "honour"), please fix that.  Also, please make sure comments all start
> with a capital letter, end with a period, and comprise full English
> sentences.
>
> The doc string of eldoc-documentation-compose doesn't say a word about
> the function's argument.
>
> In the doc string of eldoc-documentation-strategy, you use the phrase
> "queries the special hook for all functions that produce doc strings"
> to mean, AFAIU, that the specified functions in the hook-variable list
> are called.  IMO, this wording could be confusing; suggest to use this
> instead:
>
>   `eldoc-documentation-compose': calls all the functions in the hook,
>   and displays all of the resulting doc strings ...
>
> This doc string doesn't explain the use of the timer, it explains the
> reason for its existence.  It should also describe the use:
>
> > +(defvar eldoc--enthusiasm-curbing-timer nil
> > +  "Timer used by `eldoc-documentation-enthusiast' to avoid blinking.")
>
> Last, but not least: the "async" part of the branch's name hints on
> some advanced and extremely useful functionality that these changes
> are supposed to allow, but I see no mention of that in NEWS and in the
> manual bits.  What did I miss?
>

--000000000000ea6e9b05a99a2bab
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Thanks for the feedback, Eli.<div dir=3D"auto"><br></div>=
<div dir=3D"auto">I&#39;ll get to each point later on. But I&#39;m surprise=
d the NEWS entry I had written got lost. In the git rebasing, maybe.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Jo=C3=A3o</div></div><br><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Jul 4, =
2020, 08:45 Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN<=
/a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; From: Jo=C3=A3o=
 T=C3=A1vora &lt;<a href=3D"mailto:joaotavora@HIDDEN" target=3D"_blank" =
rel=3D"noreferrer">joaotavora@HIDDEN</a>&gt;<br>
&gt; Date: Tue, 30 Jun 2020 12:31:10 +0100<br>
&gt; Cc: Stefan Monnier &lt;<a href=3D"mailto:monnier@HIDDEN" tar=
get=3D"_blank" rel=3D"noreferrer">monnier@HIDDEN</a>&gt;, <a href=
=3D"mailto:andreyk.mad@HIDDEN" target=3D"_blank" rel=3D"noreferrer">andr=
eyk.mad@HIDDEN</a>,<br>
&gt;=C2=A0 Dmitry Gutov &lt;<a href=3D"mailto:dgutov@HIDDEN" target=3D"_=
blank" rel=3D"noreferrer">dgutov@HIDDEN</a>&gt;<br>
&gt; <br>
&gt; The work that started with this discussion is now mostly complete.=C2=
=A0 It<br>
&gt; has been sitting in the scratch/eldoc-async branch of the Savannah rep=
o<br>
&gt; for a while, but I&#39;ve been very busy and didn&#39;t have time to a=
nnouce it.<br>
<br>
Thanks.<br>
<br>
&gt; Anyway I think my efforts are ready to push to master.=C2=A0 I&#39;ll =
do so soon<br>
&gt; unless someone raises a serious problem about it.<br>
<br>
Not a serious problem, but some comments:<br>
<br>
&gt; -(defun eldoc-message (&amp;optional string)<br>
&gt; +(make-obsolete<br>
&gt; + &#39;eldoc-message &quot;use `eldoc-documentation-functions&#39; ins=
tead.&quot; &quot;1.1.0&quot;)<br>
<br>
Isn&#39;t the version part of the obsolete message supposed to tell the<br>
version of Emacs?<br>
<br>
The change to the number of arguments of the functions in the<br>
eldoc-documentation-functions hook is backward-incompatible, isn&#39;t it?<=
br>
I see you&#39;ve changed the relevant functions in our sources, but what<br=
>
about 3rd-party packages?<br>
<br>
Also, the doc string of this hook needs clarification regarding the<br>
arguments: it first says that CALLBACK is the only mandatory argument<br>
to the hook functions, but then, out of the blue, appear additional<br>
arguments DOCSTRING and a list of key-value pairs.=C2=A0 Confusing.<br>
<br>
The doc strings have some words in UK English spelling &quot;(e.g.,<br>
&quot;honour&quot;), please fix that.=C2=A0 Also, please make sure comments=
 all start<br>
with a capital letter, end with a period, and comprise full English<br>
sentences.<br>
<br>
The doc string of eldoc-documentation-compose doesn&#39;t say a word about<=
br>
the function&#39;s argument.<br>
<br>
In the doc string of eldoc-documentation-strategy, you use the phrase<br>
&quot;queries the special hook for all functions that produce doc strings&q=
uot;<br>
to mean, AFAIU, that the specified functions in the hook-variable list<br>
are called.=C2=A0 IMO, this wording could be confusing; suggest to use this=
<br>
instead:<br>
<br>
=C2=A0 `eldoc-documentation-compose&#39;: calls all the functions in the ho=
ok,<br>
=C2=A0 and displays all of the resulting doc strings ...<br>
<br>
This doc string doesn&#39;t explain the use of the timer, it explains the<b=
r>
reason for its existence.=C2=A0 It should also describe the use:<br>
<br>
&gt; +(defvar eldoc--enthusiasm-curbing-timer nil<br>
&gt; +=C2=A0 &quot;Timer used by `eldoc-documentation-enthusiast&#39; to av=
oid blinking.&quot;)<br>
<br>
Last, but not least: the &quot;async&quot; part of the branch&#39;s name hi=
nts on<br>
some advanced and extremely useful functionality that these changes<br>
are supposed to allow, but I see no mention of that in NEWS and in the<br>
manual bits.=C2=A0 What did I miss?<br>
</blockquote></div>

--000000000000ea6e9b05a99a2bab--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 09:32:01 +0000
Resent-Message-ID: <handler.41531.B41531.159385507413298 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159385507413298
          (code B ref 41531); Sat, 04 Jul 2020 09:32:01 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 09:31:14 +0000
Received: from localhost ([127.0.0.1]:58056 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jreVu-0003SQ-Fc
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:31:14 -0400
Received: from eggs.gnu.org ([209.51.188.92]:49474)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1jreVs-0003S6-6u
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:31:13 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60542)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1jreVk-0004xM-Hr; Sat, 04 Jul 2020 05:31:06 -0400
Received: from [176.228.60.248] (port=4704 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 1jreVj-0000in-17; Sat, 04 Jul 2020 05:31:03 -0400
Date: Sat, 04 Jul 2020 12:31:05 +0300
Message-Id: <83blkvvd7q.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN>
 (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sat, 4 Jul 2020 10:21:43
 +0100)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN>
 <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@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>
> Date: Sat, 4 Jul 2020 10:21:43 +0100
> Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, 
> 	dgutov@HIDDEN
> 
> I'm surprised the NEWS entry I had written got lost. In the git rebasing,
> maybe.

There is a NEWS entry in the branch, but it only says this:

  -*** 'eldoc-documentation-function' is now a user option.
  -Modes should use the new hook instead of this user option to register
  -their backends.
  +*** New user option 'eldoc-documentation-strategy'
  +The built-in choices available for this user option let users compose
  +the results of 'eldoc-documentation-functions' in various ways.  The
  +user option replaces 'eldoc-documentation-function', which is now
  +obsolete.

I don't see how by reading this anyone could understand that the
change allows significant new functionality.  maybe you wrote more
than that, and it did get lost somehow?

(FTR, I did "git diff ...origin/scratch/eldoc-async" to see the
changes on the branch.)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 09:39:01 +0000
Resent-Message-ID: <handler.41531.B41531.159385548413952 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159385548413952
          (code B ref 41531); Sat, 04 Jul 2020 09:39:01 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 09:38:04 +0000
Received: from localhost ([127.0.0.1]:58078 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrecW-0003cy-77
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:38:04 -0400
Received: from mail-il1-f172.google.com ([209.85.166.172]:45081)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jrecU-0003cV-Bp
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:38:03 -0400
Received: by mail-il1-f172.google.com with SMTP id o3so11697202ilo.12
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 02:38:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=eJCEPdd5HLzCOUFFbN8BZBu3wRwL6iq83UVPpcxXoPI=;
 b=POle9iPshb8GvArqtBGtS5Pbo9F+KAjHksOhL7ifIVinDaReCp5AysDNRdy+P+7rme
 qn657l4LEZ65TCnWkstJoz3tzb+uSJzStbZc0bHCYj1lrm9O2WgTh0nknLNuvuL7JQMc
 Fsh71BP/DyLViwZwcX97qzGcJbH9HQ6zz4mG2FSMUegBay+dERhBFjwFmaqnAcCh7eAN
 icbYobwOlzd8g1rKUwY8WPVT7LioIp9TTv59YOklmC3fYq1fj9XtShcBw603pEIiXBiX
 AS341lOhU1CxZMciVqUiqVEyEgBnlgVMF1aSSaOfOIO5M+LzBfjIe1WFUSkdQ6CINgKd
 3Egg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=eJCEPdd5HLzCOUFFbN8BZBu3wRwL6iq83UVPpcxXoPI=;
 b=DH32bkzA2PV/7eqPeV7ITrDpcC4HeQ8LTKd7zgE4sYu8wtqVGeRwtygycE5idiCCha
 Yo3ObdkcwZO6S4/jOELrVAluZv7FWl2p89U3909UBTxgePgtXmWl3JOaQ+lBo07LxErz
 mrFjmDxNWgSGGQSsvrAPTaKn+2Q6sThji1js9QQ51Cyfw6a6AsMZ33bQd3ee8r903dhV
 bDzIdXXYFrc8pyz9TjG+ejUU4vh38XJsmx+lUBo7d+g+TH9a381YsafLtCVN98EilMmF
 eSG9kAwiYsOdCbHmln97NNyHB/cSdLJcTjGci0+tFNz+JeWZdpfbniPIQxXvaa+53ufe
 d20Q==
X-Gm-Message-State: AOAM533zSrblYzZ6XDLhAQrZV2jQJI3CBaEHXNjsGmbVCsxEUFASfeHB
 dqElZNcPuyXO/UDSc0jpdkfR8Mr/VIXCnxlgcNDz7A==
X-Google-Smtp-Source: ABdhPJwocdD8D71Z+sn8l8uryYkDj9tq+SDvwoGSKPVttxwAwJFXQThpqQYkuFYywf+bpQay1vsxuBkFPolpJ+dKQZQ=
X-Received: by 2002:a05:6e02:1212:: with SMTP id
 a18mr19598863ilq.97.1593855476874; 
 Sat, 04 Jul 2020 02:37:56 -0700 (PDT)
MIME-Version: 1.0
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN>
 <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN>
 <83blkvvd7q.fsf@HIDDEN>
In-Reply-To: <83blkvvd7q.fsf@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Sat, 4 Jul 2020 10:37:50 +0100
Message-ID: <CALDnm52m5MZurAzGMVAjvgvjwU1iDw1_=-tvwW=5K7xHWu8iHw@HIDDEN>
Content-Type: multipart/alternative; boundary="00000000000085c58905a99a659c"
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: -1.0 (-)

--00000000000085c58905a99a659c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ah, ok I see what you mean.

I didn't feel it was necessary to enter into details since it is backwards
compatible. But I can add some things to mention that async is now
supported in a "first class" sense.

Jo=C3=A3o

On Sat, Jul 4, 2020, 10:31 Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN>
> > Date: Sat, 4 Jul 2020 10:21:43 +0100
> > Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>,
> andreyk.mad@HIDDEN,
> >       dgutov@HIDDEN
> >
> > I'm surprised the NEWS entry I had written got lost. In the git rebasin=
g,
> > maybe.
>
> There is a NEWS entry in the branch, but it only says this:
>
>   -*** 'eldoc-documentation-function' is now a user option.
>   -Modes should use the new hook instead of this user option to register
>   -their backends.
>   +*** New user option 'eldoc-documentation-strategy'
>   +The built-in choices available for this user option let users compose
>   +the results of 'eldoc-documentation-functions' in various ways.  The
>   +user option replaces 'eldoc-documentation-function', which is now
>   +obsolete.
>
> I don't see how by reading this anyone could understand that the
> change allows significant new functionality.  maybe you wrote more
> than that, and it did get lost somehow?
>
> (FTR, I did "git diff ...origin/scratch/eldoc-async" to see the
> changes on the branch.)
>

--00000000000085c58905a99a659c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Ah, ok I see what you mean.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">I didn&#39;t feel it was necessary to enter into=
 details since it is backwards compatible. But I can add some things to men=
tion that async is now supported in a &quot;first class&quot; sense.</div><=
div dir=3D"auto"><br></div><div dir=3D"auto">Jo=C3=A3o<br><br><div class=3D=
"gmail_quote" dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Ju=
l 4, 2020, 10:31 Eli Zaretskii &lt;<a href=3D"mailto:eliz@HIDDEN">eliz@gnu=
.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; From: Jo=
=C3=A3o T=C3=A1vora &lt;<a href=3D"mailto:joaotavora@HIDDEN" target=3D"_=
blank" rel=3D"noreferrer">joaotavora@HIDDEN</a>&gt;<br>
&gt; Date: Sat, 4 Jul 2020 10:21:43 +0100<br>
&gt; Cc: <a href=3D"mailto:41531 <at> debbugs.gnu.org" target=3D"_blank" rel=3D"=
noreferrer">41531 <at> debbugs.gnu.org</a>, Stefan Monnier &lt;<a href=3D"mailto=
:monnier@HIDDEN" target=3D"_blank" rel=3D"noreferrer">monnier@iro=
.umontreal.ca</a>&gt;, <a href=3D"mailto:andreyk.mad@HIDDEN" target=3D"_=
blank" rel=3D"noreferrer">andreyk.mad@HIDDEN</a>, <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"mailto:dgutov@HIDDEN" target=
=3D"_blank" rel=3D"noreferrer">dgutov@HIDDEN</a><br>
&gt; <br>
&gt; I&#39;m surprised the NEWS entry I had written got lost. In the git re=
basing,<br>
&gt; maybe.<br>
<br>
There is a NEWS entry in the branch, but it only says this:<br>
<br>
=C2=A0 -*** &#39;eldoc-documentation-function&#39; is now a user option.<br=
>
=C2=A0 -Modes should use the new hook instead of this user option to regist=
er<br>
=C2=A0 -their backends.<br>
=C2=A0 +*** New user option &#39;eldoc-documentation-strategy&#39;<br>
=C2=A0 +The built-in choices available for this user option let users compo=
se<br>
=C2=A0 +the results of &#39;eldoc-documentation-functions&#39; in various w=
ays.=C2=A0 The<br>
=C2=A0 +user option replaces &#39;eldoc-documentation-function&#39;, which =
is now<br>
=C2=A0 +obsolete.<br>
<br>
I don&#39;t see how by reading this anyone could understand that the<br>
change allows significant new functionality.=C2=A0 maybe you wrote more<br>
than that, and it did get lost somehow?<br>
<br>
(FTR, I did &quot;git diff ...origin/scratch/eldoc-async&quot; to see the<b=
r>
changes on the branch.)<br>
</blockquote></div></div></div>

--00000000000085c58905a99a659c--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 09:45:02 +0000
Resent-Message-ID: <handler.41531.B41531.159385588414571 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159385588414571
          (code B ref 41531); Sat, 04 Jul 2020 09:45:02 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 09:44:44 +0000
Received: from localhost ([127.0.0.1]:58083 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jreiy-0003mx-3C
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:44:44 -0400
Received: from eggs.gnu.org ([209.51.188.92]:51234)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1jreiw-0003mj-DW
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 05:44:42 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:60599)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1jreiq-0007py-JU; Sat, 04 Jul 2020 05:44:36 -0400
Received: from [176.228.60.248] (port=1648 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 1jreip-0005cj-Rd; Sat, 04 Jul 2020 05:44:36 -0400
Date: Sat, 04 Jul 2020 12:44:38 +0300
Message-Id: <83a70fvcl5.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <CALDnm52m5MZurAzGMVAjvgvjwU1iDw1_=-tvwW=5K7xHWu8iHw@HIDDEN>
 (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sat, 4 Jul 2020 10:37:50
 +0100)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN>
 <CALDnm50jTJtn7wH79ksDVkFJBv97OSCbF3g=eYKt2Ec4=BY-iw@HIDDEN>
 <83blkvvd7q.fsf@HIDDEN>
 <CALDnm52m5MZurAzGMVAjvgvjwU1iDw1_=-tvwW=5K7xHWu8iHw@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>
> Date: Sat, 4 Jul 2020 10:37:50 +0100
> Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN, 
> 	dgutov@HIDDEN
> 
> I can add some things to mention that async is now supported in a
> "first class" sense.

Please do, I think it's important.  You don't have to tell too many
details in NEWS about that, just mention it, and say that the details
are in the ELisp manual and the doc strings of this-and-that.

TIA

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Sat, 04 Jul 2020 10:05:02 +0000
Resent-Message-ID: <handler.41531.B41531.159385708916458 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, 41531 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159385708916458
          (code B ref 41531); Sat, 04 Jul 2020 10:05:02 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 10:04:49 +0000
Received: from localhost ([127.0.0.1]:58087 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrf2O-0004HO-PT
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 06:04:48 -0400
Received: from mail-wm1-f41.google.com ([209.85.128.41]:34171)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jrf2L-0004HA-Lk
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 06:04:46 -0400
Received: by mail-wm1-f41.google.com with SMTP id g10so12360449wmc.1
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 03:04: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=VwXM7qoUhqf+HEwuUmgUlTsVIN30W8k0bdpZKi4QzKs=;
 b=RtyCgyys45QhpoUJYZ7ddJqlVayFuLHTj5NxPJ4ikwBh3G+ghow+QTo9ixZb+rC1jU
 c1SwCnp7JA9rE/zCIqqhETN6gxbjhF/nQd1LNUafC0koQt/+Lc+pOHv0kYEHlpXZ8isH
 Q0F+VpcQZb3u1o93Dyd5kbrs9RjYUzTQtCXQr3qyNOyzYSTEgs/e2qBDowArZh0mXBYg
 XdTGdH+SItLyZApAGtmnkiFVayZxVpfO5H11CYT3lPT6+00862VmOateMPp+I50jpwcP
 erFWK7PqKMgGi0LJ89ZDa4/MY9KUfbBobu7hcuuuVIej/q/lpKw8xi26Su0mxAjVaIwA
 mYKA==
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=VwXM7qoUhqf+HEwuUmgUlTsVIN30W8k0bdpZKi4QzKs=;
 b=D9wD4G6D4UR/VkMgWtjcg32QOMA5ZormDqD7hZeU+w1vrv6Y8/WHCSFKHwbYvQqb7J
 1o2qsMW8LJJh5FB4pfTggngwvrzqc0fv/72TuFOgIIzX8fvtJjLobSW5/HYNYojB2CJs
 aa6XK3nYCSpT/8SFUjTncLMTX/pLAPN2ZK0A6kcqCeSF0OXcAaTjh/gcGeGwNKaNv+pK
 47sVSo6asTyqpV2W3zsDzU4j4dv11wk0fOgf+oQvdnQqgjoFNh42Qy5CNkQhQ9vv7CUC
 4cHqR+Dxc+P/xGUXqEZ3p2XB2WgDotpV9DXnkuj161xnAmYOeVeOULc8goZ/1TjkAG7L
 TCNA==
X-Gm-Message-State: AOAM5318L7HGyPkaEqKQMoXc6lgMui2MXpv2Vcx25uIqNzTNO6JITFTD
 ifh6mVy4rZU518nOT8UNpZM=
X-Google-Smtp-Source: ABdhPJy3E2m7Ex0GKsGxe1mqE8VfwX7XIsvZk927yjXGSeiwH9pS8gVezgvymFYU1D0xPdF+OXPsZw==
X-Received: by 2002:a05:600c:258:: with SMTP id
 24mr1430404wmj.126.1593857078777; 
 Sat, 04 Jul 2020 03:04:38 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id p4sm17554961wrx.63.2020.07.04.03.04.37
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 04 Jul 2020 03:04:37 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
Date: Sat, 4 Jul 2020 13:04:35 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87sgecssch.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 30.06.2020 14:31, João Távora wrote:
> Dmitry has expressed his intent to make the new eldoc.el work with a new
> futures/promises library.  He prototyped one of those libraries.  I have
> nothing against that in the future.  However,
> 
> 1. I don't have the resources to make the eldoc.el prototype work with
>     Dmitry's or other libraries;
> 
> 2. We should revisit the purpose and the details of that and other
>     libraries in a separate discussion.  For now it's high time we
>     advance the Eldoc libray;.

Unsurprisingly, I object to this approach. We should have better async 
support in multiple Emacs facilities, and that means standardizing on 
some particular async primitives and functions that can manipulate them. 
There is no need to release support for ad-hoc async values (you didn't 
like mine, so it's only fair play that I object to yours) when we can 
transition to full futures right away.

I'll get into a little more detail in the more full review, tonight or 
tomorrow, but for now my impression is that, in the absence of such 
standard library and async manipulation functions, you decided to 
implement them specially in Eldoc. Even though most of that logic should 
be extracted to general purpose code that manipulates async objects 
(futures/promises or the like). And I wonder how the desire not to have 
such logic in Eglot has influenced your total vision of the API.

Because with futures in standard library, it could look fairly 
different, and could need fewer changes compared to its current shape.

Regarding #1, it should be trivial to reimplement on top of futures. I 
could do this myself, as long as everybody is fine with the proposed 
shape of futures on standardize on.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 11:02:01 +0000
Resent-Message-ID: <handler.41531.B41531.159386047122247 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159386047122247
          (code B ref 41531); Sat, 04 Jul 2020 11:02:01 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 11:01:11 +0000
Received: from localhost ([127.0.0.1]:58145 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrfuw-0005mk-BC
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 07:01:11 -0400
Received: from mail-wm1-f51.google.com ([209.85.128.51]:52438)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jrfut-0005mL-8x
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 07:01:08 -0400
Received: by mail-wm1-f51.google.com with SMTP id q15so34296552wmj.2
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 04:01:07 -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=U3jKGvVmvC7vW5tZ6ATbgPWsl1l0Ym+M8Adx0n2gwtM=;
 b=a8w0HHzthl0KBxDztsqb26qWqRTw9LSympDtrr/UoAvyXgisqYUCrnrO1cV5x5+wUy
 z1Mk86nUPEQLhGM9ksLWvFPb6cTnxRTMPKtZSveNc30T+daWqxfrZ/58TeJHoIUZiKgX
 SynvRhUqRo7Qvy2FAW0ti/5sAJ6u5nbmsvoxSzPYgY1LJpAwWpWJcM6dF/FwlUT+5jtR
 Vl5vt7ro1x4Sa1ZORGympJs3e1hKyx3T1it6PKoopu+6DhI8uX4OfCGCzG38OJMcqdVG
 DzCStgS98ZEuw8KPXa3wSo9Y7d8E7xHS5ZxDEphFllyuuQSIB8PkYnI9eiaxbLi5TWi5
 LgcQ==
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=U3jKGvVmvC7vW5tZ6ATbgPWsl1l0Ym+M8Adx0n2gwtM=;
 b=fDaC39usPtCY05SRUbBbwYSBHXCWuPwKG3r2BpIZb7BCUr17DjCPkeRpaHMBZPkcaQ
 /MWZOUB5lADHR0lv/hyhNx5vP1vAQ6VJstipKXXBzrvH53XPw8apNlpWWYMqLf1ksq0u
 Qw2mv8IDinkRlw6PCWW9LnH5ZMN4lPnQeAXOGqu0vOn7Vje6c7EDndNHE9zHJonzxB51
 pbpAtWY64ug/h9pq9tjCwU06qetfocTSgi+qW2BaOF69lXBGdbVr9VQDSprUkU7ehyXK
 rqG2xwYpxXc5y3QQuDy6ZpKfjHZ+ayQJ5ERuwd/MltiN0DwOd350H7XSVX4IOah8oj/P
 MXoA==
X-Gm-Message-State: AOAM5318BVwtfhjc6EmTiwWaSS0jEZwA8EAmB8Khqiir9l1uPPic0lWM
 9FZ7IvuVEQXJbd5zJbdw+bk=
X-Google-Smtp-Source: ABdhPJxpwLDg2TPW7LnFRPoHM1Mf5aSUhP68r8FgO9YCZX5ecE9QDseclYgKJfwEJCI/RR6HbWAnJw==
X-Received: by 2002:a7b:c18f:: with SMTP id y15mr41408824wmi.85.1593860461240; 
 Sat, 04 Jul 2020 04:01:01 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id k185sm16389237wmk.47.2020.07.04.04.00.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 04 Jul 2020 04:01:00 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN>
Date: Sat, 04 Jul 2020 12:00:57 +0100
In-Reply-To: <83k0zjvi4c.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jul
 2020 10:45:07 +0300")
Message-ID: <87zh8fsfx2.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:

>> Anyway I think my efforts are ready to push to master.  I'll do so soon
>> unless someone raises a serious problem about it.
>
> Not a serious problem, but some comments:
>
>> -(defun eldoc-message (&optional string)
>> +(make-obsolete
>> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0")
>
> Isn't the version part of the obsolete message supposed to tell the
> version of Emacs?

Yes, but eldoc.el is its own versioned piece of software now, because it
is a GNU Elpa :core package.  So I opted to use that versioning instead.
Maybe I shouldn't have?  Don't know if there's prior art for this
situation, but I'm reasonably confident I personally have taken this
decision before.

> The change to the number of arguments of the functions in the
> eldoc-documentation-functions hook is backward-incompatible, isn't it?
> I see you've changed the relevant functions in our sources, but what
> about 3rd-party packages?

I've checked and there were none.  The eldoc-documentation-functions
variable came to be in Emacs master: it's not in Emacs 27.  I myself
"released" eldoc.el to GNU Elpa almost 2 months ago (see
9ebf51999ce58cccc2a228fd07a18c7b472dd3fd).  I had intended to streamline
that release together with these async-related developments, but reality
(and mostly Dmitry :-) intervened.

So indeed there is the danger that, in the intervening 2 months, some
3rd party package depending on GNU Elpa's Eldoc, started using the
argless eldoc-documentation-functions, and will be surprised by this
backwards-incompatible change.  However, I think the changes of that are
unlikely.  I searched Github and Google for such references and couldn't
find any.

So I think it's safe.  (But even if it weren't, I'd still argue for the
change + fallout ).

> Also, the doc string of this hook needs clarification regarding the
> arguments: it first says that CALLBACK is the only mandatory argument
> to the hook functions, but then, out of the blue, appear additional
> arguments DOCSTRING and a list of key-value pairs.  Confusing.

Understood.

> The doc strings have some words in UK English spelling "(e.g.,
> "honour"), please fix that.  Also, please make sure comments all start
> with a capital letter, end with a period, and comprise full English
> sentences.

OK.

> The doc string of eldoc-documentation-compose doesn't say a word about
> the function's argument.

That function isn't meant to be called by users, and the EAGERLYP is a
code-saving trick.  But of course I should document it.

> In the doc string of eldoc-documentation-strategy, you use the phrase
> "queries the special hook for all functions that produce doc strings"
> to mean, AFAIU, that the specified functions in the hook-variable list
> are called.  IMO, this wording could be confusing; suggest to use this
> instead:
>
>   `eldoc-documentation-compose': calls all the functions in the hook,
>   and displays all of the resulting doc strings ...

This of course, assumes that people know that "functions in the hook"
aren't like "functions in a list".  The symbol `t` may be in "in the
hook".

But it's better for practical purposed, I admit.  Because "result" is
often conflated with "return value", and that's only _one_ of the ways
the functions can produce doc strings, I'd modify that to:

   `eldoc-documentation-compose': calls all the functions in the hook,
   and displays the doc strings that they produce...
>
> This doc string doesn't explain the use of the timer, it explains the
> reason for its existence.  It should also describe the use:
>
>> +(defvar eldoc--enthusiasm-curbing-timer nil
>> +  "Timer used by `eldoc-documentation-enthusiast' to avoid
>blinking.")

OK.

> Last, but not least: the "async" part of the branch's name hints on
> some advanced and extremely useful functionality that these changes
> are supposed to allow, but I see no mention of that in NEWS and in the
> manual bits.  What did I miss?

Not much, we talked about this.  Will change NEWS according to what we
discussed.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 11:50:02 +0000
Resent-Message-ID: <handler.41531.B41531.15938633452476 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15938633452476
          (code B ref 41531); Sat, 04 Jul 2020 11:50:02 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 11:49:05 +0000
Received: from localhost ([127.0.0.1]:58160 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrgfJ-0000dr-A6
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 07:49:05 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:40190)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jrgfH-0000dM-AY
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 07:49:04 -0400
Received: by mail-wm1-f45.google.com with SMTP id f139so36675333wmf.5
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 04:49:03 -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=HY+Ka0K/9oo7jlQ0lX0xDowSmPxgNq9vAHBAOUDhzas=;
 b=fYdty+nmE1OSSjAsxDwpIpGDAoDnTLzmB4uUTaM3c4D1WLWSonqKFUt55Nl5q7/EpE
 G7dfkw/In4dONm5DQsaLnh/0iBJMIiKat9574EBm6JvMdGFo5MC3ZGN0bYekLKVeHy1G
 cbBtUIWHI5gbsrLK4dOTpaUCxjEZNlG0QhqQiGK661Qvmf9SrsdoGV6RuxlqLFmM87No
 T4tw4RSsMBZ9+KATCdnKlWdoYqouflLMNUMCFn1ikv9Dq9oG50TyvEeqPqxhswnon1v3
 QeqIWEk5pbUgW+rb8K4PFAFyjAw+2grSqxHIglwVofOldb9djZ8AqaDPUQ1hdyLvPfpZ
 8xag==
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=HY+Ka0K/9oo7jlQ0lX0xDowSmPxgNq9vAHBAOUDhzas=;
 b=i7ngNDd23elQ8/qQEWNVisYYh4M1g8zgd7oWCSsn7DteoY++bD4bXfrFgH4x3F+cqz
 te8pqmInJzSd/0f7jCBLxcsW1sX8MgzR9QxkK/5NoNoU4a9/xXXKMe7WvcSYEsjN53wm
 fKScIRi/olVWK/l3kDmOmtW+x0dfTOo7qx2smhK/Y4c6vMqzIFjqis7vZojcDgHxoJps
 1kfzr9bG5xdo7SjqVWnHXWxbR8xHKv7vF4r5rb9Pkkv1aXn/SJV6tac/FXUvvUXxN44i
 Tf811XSjlqmdp/rxJEJHLBgqhFpqLZH+E04bfZiRAO4uqOZHZv3tbAEwDOiYmZpIe5pP
 5BjA==
X-Gm-Message-State: AOAM533nVQghQrxirObRN8BuUXYqzrL9SA+Oa8YVQrQtcTojHlJMQwxd
 pQJ0Go+83Q7DNX16Y2qBIso=
X-Google-Smtp-Source: ABdhPJybLYR3yvLkV12Qg5Va0/ph15fdfmOmfxTd1eJKHjSJLj3r9AfshzOQ54e1Jjt9eOa0LxJgAA==
X-Received: by 2002:a1c:1fd1:: with SMTP id
 f200mr39651955wmf.162.1593863337254; 
 Sat, 04 Jul 2020 04:48:57 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id z16sm16709966wrr.35.2020.07.04.04.48.53
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 04 Jul 2020 04:48:54 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
Date: Sat, 04 Jul 2020 12:48:53 +0100
In-Reply-To: <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> (Dmitry Gutov's
 message of "Sat, 4 Jul 2020 13:04:35 +0300")
Message-ID: <87tuynsdp6.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.06.2020 14:31, Jo=C3=A3o T=C3=A1vora wrote:
>> Dmitry has expressed his intent to make the new eldoc.el work with a new
>> futures/promises library.  He prototyped one of those libraries.  I have
>> nothing against that in the future.  However,
>> 1. I don't have the resources to make the eldoc.el prototype work
>> with
>>     Dmitry's or other libraries;
>> 2. We should revisit the purpose and the details of that and other
>>     libraries in a separate discussion.  For now it's high time we
>>     advance the Eldoc libray;.
>
> Unsurprisingly, I object to this approach. We should have better async
> support in multiple Emacs facilities, and that means standardizing on=20
> some particular async primitives and functions that can manipulate
> them. There is no need to release support for ad-hoc async values (you
> didn't like mine, so it's only fair play that I object to yours) when
> we can transition to full futures right away.

I haven't seen a consistent plan "for transitioning to futures".  All
I've seen is (complicated, IMO) ideas on how to avoid the
callback-calling style by hiding the callback in an object.  I've seen
little argument or discussion of what futures are supposed to do or fix
or improve.  And I've seen no feedback from the author of what seems to
be the most promising futures library, aio.el which uses the
generator.el library, to provide, presumably, more elegant
"language-level" futures (i.e. futures that aren't only hiding the
callback in some other object).

Despite that, I've stated here repeatedly, tiringly: In principle, I
don't object to futures at all.  I just think it has to be a
thought-through change.  Propose your library to emacs-devel and let's
iterate it there.

> I'll get into a little more detail in the more full review, tonight or
> tomorrow, but for now my impression is that, in the absence of such=20
> standard library and async manipulation functions, you decided to
> implement them specially in Eldoc.

Of course, and that's what engineering is about.  For the most trivial
of changes X there is _always_ a refactoring R that will make
implementing X and a possible Y and Z much simpler, more elegant, more
"meta".  Knowing where to stop is what this game is about.  In this
case, there is only a vision what Y and Z might be, and a foggier vision
of how bad/good design decisions in R might affect them.

So I fixed the real, actual problem in Eldoc using the async paradigm
that is widely used in Emacs and most widely understood by programmers
of all (most?) trades: callbacks.

And, again, for the nth time, there is nothing in my code that prevents
your -- or someone else's -- "futures" library to be the nec plus ultra
of async in Emacs.  But, in the meantime, I won't let you make these
Eldoc changes hostage to your predilection for futures.  It's quite a
legitimate inclination, of course, it musn't be needlessly put it in the
way of other's work.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Sat, 04 Jul 2020 21:08:01 +0000
Resent-Message-ID: <handler.41531.B41531.159389682832705 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159389682832705
          (code B ref 41531); Sat, 04 Jul 2020 21:08:01 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 21:07:08 +0000
Received: from localhost ([127.0.0.1]:59754 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrpNM-0008VR-8Q
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:07:08 -0400
Received: from mail-wr1-f41.google.com ([209.85.221.41]:40575)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jrpNK-0008Uw-Jt
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:07:07 -0400
Received: by mail-wr1-f41.google.com with SMTP id f2so8486048wrp.7
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 14:07: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=rRsUflcTBcHQnpwwNiYHQ6phZcNGgoGpWp5L77Xlzw0=;
 b=Ke9kgBOfid8BiTlX9qFNYNjgAYFiP1b89LOtvlSbF0h7epkQSrAR/Sk3iU9kECZRpo
 PcaYGwZC02mZvzIZb2Tdyz9yQhNB91JFYQSBDM2ogyP9KtdhADOm3WLK3zF0HSZl7fdv
 bPrNCfDTtbl7pqHkOW3tmsWFOCUoKIDVdrYPNDjdSjzEnpGJ7ix/rHqHxSwXuFe6iDnS
 l28gJvZR9r6fJTW18mULlOyrXKBMInQqonmT9W3WwwfP9HT4rKLnr4JL0kr0eHSOgvdy
 SJB4DR5b7ANZ2HKgdHog4+UMWwkTqpmBMXWtxFz+L84wcLaAYF4Kmmep1NTnHmTUztMi
 0Frw==
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=rRsUflcTBcHQnpwwNiYHQ6phZcNGgoGpWp5L77Xlzw0=;
 b=Yfp7zpJKIFTjLFWH0GYEx84HTDKBQ2C8o+Yp0vvsY55wfZEplJQkZ/bMvgUUNsa+2c
 12A9jeAfENWyI8GcWdoxYswNsfMrO600EYsDbugeFlO6aTkl2qxvtseABLOV5UkfOrzf
 7wiIv12WEw1Qx6+TptSGS4Ogm+FZmMlXgVkZJ6uKB6pA48RO5uoWFG1D5m9v4J2CAL31
 5Lp71HGZTSNKnuo9a3RXtjsYL51SN0OufXnsitvALqemll8OcWPGMUV9t49HNDgYlhrI
 QuSZGGCqGEqkUc2rCmCVXWb9SBYPC4x3RRtQdUsVv4phPURxJYv/7ziFg3PTts3DnUBk
 r/cg==
X-Gm-Message-State: AOAM532nE8xGs2xPP36lbioXjhIhqQX0EsqtEBg2E35jKICCGO8T2XWk
 1B7E32YlbDfcD6Toh6ivLes=
X-Google-Smtp-Source: ABdhPJwJ9eRyc3MfJkRVNuYY/RqoR++ZeIp8eHMD1k3JWBU1wwMVHWdzG8BAM/lwzMTcHtJxEMgqhQ==
X-Received: by 2002:adf:b6a4:: with SMTP id j36mr42744125wre.260.1593896782578; 
 Sat, 04 Jul 2020 14:06:22 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id d10sm18330967wrx.66.2020.07.04.14.06.20
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 04 Jul 2020 14:06:21 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN>
Date: Sun, 5 Jul 2020 00:06:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87zh8fsfx2.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 04.07.2020 14:00, João Távora wrote:
> I had intended to streamline
> that release together with these async-related developments, but reality
> (and mostly Dmitry:-)  intervened.

To be fair to yours truly, though, AFAIK we are the only two people in 
this discussion who maintain third-party eldoc clients, or work on 
integrated development experience in general.

That's a pretty sad state of affairs, BTW.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Sat, 04 Jul 2020 21:28:02 +0000
Resent-Message-ID: <handler.41531.B41531.15938980502015 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15938980502015
          (code B ref 41531); Sat, 04 Jul 2020 21:28:02 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 21:27:30 +0000
Received: from localhost ([127.0.0.1]:59759 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrph4-0000WR-1y
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:27:30 -0400
Received: from mail-wr1-f46.google.com ([209.85.221.46]:46861)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jrph2-0000WF-SO
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:27:29 -0400
Received: by mail-wr1-f46.google.com with SMTP id r12so36457683wrj.13
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 14:27:28 -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=8fGAzBO7qxQEvrHhytcXR47y8aU1Fqh8ePC6ZJC+9+M=;
 b=QwF4K5QtcK6qgG+Vd6iFWtZyXas4uhDS10NQGPEPvl/TubbRNapWdyZygi/Hiikgxy
 gR2j6H/oeT+J9E6qDSZzONW8JOxd44IwkmRMMk/Wi5mc/HoXqT2RQdY1jAzCKKj7OcAF
 kaGcr4QDwnjTstpSTXwc8Jax6WNPrMG8saKU/5FCZDF2kgTdtY/ZY52J8uOfRnbUdumd
 I271rDSFBWGAedF5vWmmf+uYqKNRNL5WsxAQETg+NHoN5Jj4CSK9TmG9+n4YysMk3NKV
 GdiIcSYK+70yUmzsYvzmTQJ6qhwtqh6uJJIXLOdpgFczQE+9MWbUW6MxmTTGo+GoviGI
 uaXA==
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=8fGAzBO7qxQEvrHhytcXR47y8aU1Fqh8ePC6ZJC+9+M=;
 b=pMdWyp5NCUT82UXZ4WGmNKYOw1Oy5HSQeOL34XfHYg2ZKgLbgvu+7JgHyFBJwFU0bR
 3+Iiu0wSpOIiRGfU0WFIm9MIlBbm4vtwGEPVwQCJvGVXy8PW4CvGy6Zn1c9wskYYLj7x
 O07mL9JvW5OoQ6XUnBCyG35SPJ97UettZKo0tXtsA32DrTPsxPw+5J12DPaIx5uFGNVw
 sB7wF/jJOyE05QZeTXSZSlhfI60MtGhgT1eawGOENptks0+lbozGBU4rO0GYHD2AyF8g
 nCsdDSYJeX6cRZsfs4ZusftQAFdoXNE0zxqzsxzVNo5zCaEKKronTHUsQ/96Yk8acZ+r
 5M6g==
X-Gm-Message-State: AOAM5307XaAClbNK/C7JpD2lxQaXQyEInCMbfpPA/NlJE4N7uJFKkbrg
 /XLOzKtJe2bTmiljHIodKus=
X-Google-Smtp-Source: ABdhPJw7lssnIMg52lV03lLvFUJ+P4OLvrhjsJu9PqQthjlfEUlhR+QX0dHv2h5u38rfapE3lPMoeA==
X-Received: by 2002:adf:81c7:: with SMTP id 65mr40206857wra.47.1593898042900; 
 Sat, 04 Jul 2020 14:27:22 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id a15sm20882146wrh.54.2020.07.04.14.27.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 04 Jul 2020 14:27:22 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
Date: Sun, 5 Jul 2020 00:27:20 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87tuynsdp6.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 04.07.2020 14:48, João Távora wrote:

>> Unsurprisingly, I object to this approach. We should have better async
>> support in multiple Emacs facilities, and that means standardizing on
>> some particular async primitives and functions that can manipulate
>> them. There is no need to release support for ad-hoc async values (you
>> didn't like mine, so it's only fair play that I object to yours) when
>> we can transition to full futures right away.
> 
> I haven't seen a consistent plan "for transitioning to futures".

Do you want to see the patch based on your code? It's the only 
"transition" I meant here.

If you have other questions, please ask.

> All
> I've seen is (complicated, IMO) ideas on how to avoid the
> callback-calling style by hiding the callback in an object.

Hiding is absolutely not the point.

> I've seen
> little argument or discussion of what futures are supposed to do or fix
> or improve.

I think I have described at length the very simple idea of what it is 
supposed to improve: provide a standard primitive and a library of 
composition/manipulation functions that would make these operations 
simpler. Which can be used in Emacs core, and in clients of the various 
facilities and expose future-based interfaces.

> And I've seen no feedback from the author of what seems to
> be the most promising futures library, aio.el which uses the
> generator.el library, to provide, presumably, more elegant
> "language-level" futures (i.e. futures that aren't only hiding the
> callback in some other object).

I'm very curious to know Christopher's opinion myself. Based on my 
experience, this will result in a much longer, protracted discussion, if 
it will result in one at all.

You seem to be in a hurry to get this in for some reason, but I'm fine 
with waiting a little more, if we get a better result.

> Despite that, I've stated here repeatedly, tiringly: In principle, I
> don't object to futures at all.  I just think it has to be a
> thought-through change.  Propose your library to emacs-devel and let's
> iterate it there.

If you think emacs-devel will bring more feedback, no problem.

>> I'll get into a little more detail in the more full review, tonight or
>> tomorrow, but for now my impression is that, in the absence of such
>> standard library and async manipulation functions, you decided to
>> implement them specially in Eldoc.
> 
> Of course, and that's what engineering is about.  For the most trivial
> of changes X there is _always_ a refactoring R that will make
> implementing X and a possible Y and Z much simpler, more elegant, more
> "meta".  Knowing where to stop is what this game is about.  In this
> case, there is only a vision what Y and Z might be, and a foggier vision
> of how bad/good design decisions in R might affect them.

The thing about refactoring, is it doesn't change observable behavior. 
Refactoring would keep the stable interface (and e.g. reuse future-based 
utility functions under the covers).

Whereas the improvement I would like to see here, would change it. So 
it's not something that could be simply moved to backlog.

And as I intent to explain later, I believe you will need 
future-manipulating functions inside eldoc client code anyway, for best 
user experience. So we might as well bite the bullet and introduce 
futures at the API level.

> So I fixed the real, actual problem in Eldoc using the async paradigm
> that is widely used in Emacs and most widely understood by programmers
> of all (most?) trades: callbacks.

Please recall how you rejected my proposal along the same lines.

And it's fine. We can do better.

> And, again, for the nth time, there is nothing in my code that prevents
> your -- or someone else's -- "futures" library to be the nec plus ultra
> of async in Emacs.  But, in the meantime, I won't let you make these
> Eldoc changes hostage to your predilection for futures.

"won't let you" is not exactly how things work here. We usually try hard 
to reach a consensus.

In any case, I have considered this for some time, and my arguments for 
"let's work on this some more" won't be limited to futures-vs-callbacks.

> It's quite a
> legitimate inclination, of course, it musn't be needlessly put it in the
> way of other's work.

I agree that there are improvements to be made in documentation-related 
code (whether it's in Eldoc, or not), and I also think that you might 
not be going far enough in some respects.

But the problem you seem to be urgent to fix (having eldoc-message 
called from client code) is not so terrible that we can't wait until the 
future-related discussion at least has had a chance to happen.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Sat, 04 Jul 2020 21:31:02 +0000
Resent-Message-ID: <handler.41531.B41531.15938982332381 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15938982332381
          (code B ref 41531); Sat, 04 Jul 2020 21:31:02 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 21:30:33 +0000
Received: from localhost ([127.0.0.1]:59763 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrpk1-0000cL-Kb
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:30:33 -0400
Received: from mail-wm1-f54.google.com ([209.85.128.54]:35773)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jrpjz-0000c7-R7
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 17:30:32 -0400
Received: by mail-wm1-f54.google.com with SMTP id l2so36247669wmf.0
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 14:30:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:subject:from:to:cc:references:message-id:date:user-agent
 :mime-version:in-reply-to:content-language:content-transfer-encoding;
 bh=kTNAKs7qMsA+MHfa27Hog5lQtvA4JoCkaJGHkMl52Uc=;
 b=PI/ht1tqWt/vKCKdZiGd5LrQ1vWdmsQ3llnpHZy6tAkvyH0j7BzYnRo6iKePJwEBBx
 1KKVefAVhDuhtoLg9eBEyj/vP5DIQdg1AUBKkFf5djenXZg0aqX0nGPKoisgadHHQ4SH
 sEiqjeZbgEgeRWatCDbfLHk/3BaY8lac9spfYRjHig1SVah2QG/eK560lziJmpNHKcKo
 tq/5nN6029PC6Gp0PgJoxeXSbI3FQeeiVVgCOykUZJBw4aWrSb0YzIWPzxA/u0AODedF
 CyJ7DmyjsAkyBsj1Z2kBR73bp1jjfVJM1ni3eIk8SLnktFIei1nPV9S69JVBsf33oyZy
 SFMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:subject:from:to:cc:references:message-id
 :date:user-agent:mime-version:in-reply-to:content-language
 :content-transfer-encoding;
 bh=kTNAKs7qMsA+MHfa27Hog5lQtvA4JoCkaJGHkMl52Uc=;
 b=VgfYRDL2PEoEAUUVmxDdciq3BYJEONoQ8QoTldY4yNxluiw5VF4elWyOJiBl6KY4MP
 H+E2MQ1QjE3GE70O5Sw209UznveNJ8f5WzaruYx/mOv2gSzmlBDFw0VXN6DekBF67/vZ
 F2FLK/snSpsrvmedVBjIEdmpB764KTPkA0LgtoVq1+MP8z6G482/kTrdXNESuhfq5GEV
 /wCfruPVBY4TzfhjvD0FDmUg4Lh4E2mJDEothD6QSl74g7KUV8bKpfAHPEyJ/jVhdvjY
 UaCHzQR/eLO1tDYH5q69zZRsGR7o0yDCzwVc9Rhxjzf/bdNv47bUUCeatmCQtbDQ8Flh
 TvtQ==
X-Gm-Message-State: AOAM532F9hf3UJSccOySpnf6EiwRdCvXvHxBf2jZWvowg9rRYSmA3SmC
 +BKy1CAh1pFXO793hUfEJpY=
X-Google-Smtp-Source: ABdhPJy7gEGBpH/kVBB2mp9UKuxFqLGdxsqFHgGxT+0lhaLVbc21/Yfh6+PfXtIrAC6w+fLtuH4jMg==
X-Received: by 2002:a1c:acc3:: with SMTP id v186mr44580000wme.79.1593898226040; 
 Sat, 04 Jul 2020 14:30:26 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id y6sm18234015wmy.0.2020.07.04.14.30.24
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Sat, 04 Jul 2020 14:30:25 -0700 (PDT)
From: Dmitry Gutov <dgutov@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
Message-ID: <7c4cef6f-6aca-80ff-7633-728031442855@HIDDEN>
Date: Sun, 5 Jul 2020 00:30:22 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

Sorry,

On 05.07.2020 00:27, Dmitry Gutov wrote:
>> And I've seen no feedback from the author of what seems to
>> be the most promising futures library, aio.el which uses the
>> generator.el library, to provide, presumably, more elegant
>> "language-level" futures (i.e. futures that aren't only hiding the
>> callback in some other object).
> 
> I'm very curious to know Christopher's opinion myself. Based on my 
                                                          ^ But
> experience, this   will result in a much longer, protracted discussion, if 
                    ^ [moving it to emacs-devel]
> it will result in one at all.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 23:08:02 +0000
Resent-Message-ID: <handler.41531.B41531.159390403411723 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, eliz@HIDDEN, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159390403411723
          (code B ref 41531); Sat, 04 Jul 2020 23:08:02 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 23:07:14 +0000
Received: from localhost ([127.0.0.1]:59812 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrrFa-000331-6X
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 19:07:14 -0400
Received: from mail-wm1-f41.google.com ([209.85.128.41]:40673)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jrrFX-00032g-Hf
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 19:07:13 -0400
Received: by mail-wm1-f41.google.com with SMTP id f139so37881995wmf.5
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 16:07:11 -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=wzmstFM2nirKqdgvgjrpnmm3EO1tqEETCdLgHUEy4x8=;
 b=Qox142n01LfINeRjWVo0GLABwGmbYhz96or2L96VIH6LpfogXbkeJOZXsJ1N3BO95/
 FPhdCTy5BNG6MP5VsZeTaqUwPLp7Bo/OqOvLT9PqUkLb5KCzOfGB8+uObEJQutABKx20
 vLle+O5oIX0PxkWaBsEi1byTN3nxFJAMZ3+0TJWAcaRg9xSbSYQO+eiI6E1FSwRFsjIM
 qt45AO3jI7ZtDozczRKBGhGzJpOoqVC9sG4tEpe5VJHkFzYi3XSOgkG5iyg1y4lGYQaF
 v6hPXg80JYMRjv7ZD/BqQddKrQ3vkKE1/o0fwuzHXL5T+oZcaMjDjbyYjRTjC0dlEotH
 YAQw==
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=wzmstFM2nirKqdgvgjrpnmm3EO1tqEETCdLgHUEy4x8=;
 b=QLnhNOthldiHjfPuqe8GNg+p3JOCNjOZ/umPHc+PQTHtG2PeB7o7TlsrX8iq3ZWU+h
 Lum1BIfv0qxG5uyygsHcyf3HhpbHHhQnEslRkpvo9B7sXfH7NaaiV++vaKOiyyNTEK7O
 QDmUI2OLdg0B1AKdafj/UZAAG7E2hFo3ioMFaXRVviPPqE6ZqSmEFKfaEp7ga75/w+Nw
 qVtxbY0H+iENz+/H906GmZHVHkRwofvrO36hnuIOUlSVmyH1b6OfABaaJmTie01INDSu
 1oZ/nr81ghCfXUEgAhbqUICeM+k6xCEVcJ/832f5WG8HHWetkSQuCXc4Ez3GyCOlVfPq
 XXKg==
X-Gm-Message-State: AOAM530Spcr6+jG02Dru6Am4eV2MlE68enygtpe/mdtEI0obnmT8+oBY
 QLWvSWKpERYeqJJDGBwT9e4=
X-Google-Smtp-Source: ABdhPJzEHxOhLhZIYAVXwO8/3aUwvo/xGN9U5//B1RtjSTBUVAYxN1ysF/uLKEzuAgEJR0aYv9PsFw==
X-Received: by 2002:a1c:345:: with SMTP id 66mr26954065wmd.31.1593904025409;
 Sat, 04 Jul 2020 16:07:05 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id s8sm18157627wru.38.2020.07.04.16.07.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 04 Jul 2020 16:07:04 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
Date: Sun, 05 Jul 2020 00:07:01 +0100
In-Reply-To: <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> (Dmitry Gutov's
 message of "Sun, 5 Jul 2020 00:27:20 +0300")
Message-ID: <87h7umop62.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:

> [that is the] "transition" I meant here.
>
> If you have other questions, please ask.

If it wasn't clear, my suggestion is that you send your earlier
dimtry-futures.el (as I am temporarily dubbing it, for clarity) to
emacs-devel, along with a rationale for why it is needed and where it
can be useful, not only in eldoc.el but in other places in Emacs that
use callbacks like like url.el, flymake.el, jsonrpc.rl, timers,
completion, processes, etc.  You may want to include a short comparison
to Christopher Wellon's aio.el, if you have studied it.

> I think I have described at length the very simple idea of what it is
> supposed to improve: provide a standard primitive and a library of=20
> composition/manipulation functions that would make these operations
> simpler. Which can be used in Emacs core, and in clients of the
> various facilities and expose future-based interfaces.

Maybe I missed something, but I don't consider our discussion an
at-length discussion.  It might have been verbose, but it wasn't
in-depth at all.  And certainly it didn't involve anywhere enough people
for such an ambitious feature.  I have some comments to your last
proposed dmitry-futures.el, but this bug report is not the place to make
them.

>> And I've seen no feedback from the author of what seems to
>> be the most promising futures library, aio.el which uses the
>> generator.el library, to provide, presumably, more elegant
>> "language-level" futures (i.e. futures that aren't only hiding the
>> callback in some other object).
>
> I'm very curious to know Christopher's opinion myself. Based on my
> experience, this will result in a much longer, protracted discussion,
> if it will result in one at all.
>
> You seem to be in a hurry to get this in for some reason, but I'm fine
> with waiting a little more, if we get a better result.

I want to fix longstanding problems in Eglot.  I have limited resources,
mainly time.  It is you who seem intent on not letting this go in, as if
you won't be able to prove that "better result" after it does.  This is
absurd: if you do show it to be better, then we should migrate eldoc.el
etc to futures.  ...as I've said a trillion times already at this point.

> Please recall how you rejected my proposal along the same lines.

I don't remember your proposal fixing anything in eldoc.el, you merely
suggested I experimented with a technique.  Which I actually did, and I
didn't see any advantage in it.

> And it's fine. We can do better.

I'm sorry you don't like my work.  I had good feedback about it.  If
_you_ can do better, I'm not stopping you.

>> And, again, for the nth time, there is nothing in my code that prevents
>> your -- or someone else's -- "futures" library to be the nec plus ultra
>> of async in Emacs.  But, in the meantime, I won't let you make these
>> Eldoc changes hostage to your predilection for futures.
>
> "won't let you" is not exactly how things work here. We usually try
> hard to reach a consensus.

In my book, there's nothing legitimate in vetoing a bugfix because of
some yearning for some particular abstraction or programming paradigm.
That's as absurd as demanding Emacs be rewritten in my paradigm/language
of choice before anyone else commits anything.  Especially when, for the
quadrillionth time, there is nothing stopping you from making your case
for futures after the bug is fixed.

> In any case, I have considered this for some time, and my arguments
> for "let's work on this some more" won't be limited to
> futures-vs-callbacks.

In that case, if indeed they are not futures-vs-callbacks, are they
_serious_ objections?  Can they not be fixed afterwards?  I would have
expected some manifestation of them already, but you seem to waste all
your energy on your proclivity for futures.  But very well then, let's
have those non-futures objections in this bug report, the sooner the
better.

>> legitimate inclination, of course, it musn't be needlessly put it in the
>> way of other's work.
>
> I agree that there are improvements to be made in
> documentation-related code (whether it's in Eldoc, or not), and I also
> think that you might not be going far enough in some respects.
>
> But the problem you seem to be urgent to fix (having eldoc-message
> called from client code) is not so terrible that we can't wait until
> the future-related discussion at least has had a chance to happen.

I've explained repeatedly: this is holding up multiple things in Eglot.
I want Eglot to serve diagnostic messages, and various kinds of
automatically gathered information about the "things at point" all
through eldoc.el.  Then move on to better stuff, of which there is a lot
in LSP, as you well know.  Also, this fixes SLY and SLIME too, both
hacking their way through eldoc.el.  Possibly the same for CIDER and
other such extensions.  This also opens up eldoc.el in non-async
situations as well, such as elisp-mode.el.  Just read the patch.

Look, Dmitry, think clearly: I'm going to fix eldoc.el and you can have
your futures.el discussion when you want, a discussion where don't know
if I'll be able to participate, but that shouldn't prevent it from
happening.  After that discussion, whatever conclusion you, possibly me,
and other interested parties arrive at, as long as you/we keep Eglot and
SLY functional, or suggest improvements to them, I'll abide.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 04 Jul 2020 23:13:01 +0000
Resent-Message-ID: <handler.41531.B41531.159390437712218 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159390437712218
          (code B ref 41531); Sat, 04 Jul 2020 23:13:01 +0000
Received: (at 41531) by debbugs.gnu.org; 4 Jul 2020 23:12:57 +0000
Received: from localhost ([127.0.0.1]:59820 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jrrL7-0003B0-94
	for submit <at> debbugs.gnu.org; Sat, 04 Jul 2020 19:12:57 -0400
Received: from mail-wm1-f67.google.com ([209.85.128.67]:40214)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jrrL3-0003Al-UE
 for 41531 <at> debbugs.gnu.org; Sat, 04 Jul 2020 19:12:56 -0400
Received: by mail-wm1-f67.google.com with SMTP id f139so37887925wmf.5
 for <41531 <at> debbugs.gnu.org>; Sat, 04 Jul 2020 16:12:53 -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=nSERJ/0ipU+OAZKibo4XfuxaTijFZp30rP8PyOSouxw=;
 b=UdIwH1Bp2jmg4zcIO2/NZqWFWGVXXDXALIP2aMiNg6ICFV2BP2MGmQ4MfyyOuO9CqW
 BwH08Tc3t4v7CpfZEtWLTwlH5IkklrsHWXDyhh8F2GpnumGDv8ZG7/KL3sg/+6uHhZ9g
 XTjdFb5FZkiN0UswpPq1AbfYEWCOo7razd6xG1TQZtgbRtHToTiR1By05o9owHDBI+Z0
 IVTYQhWHJIz3H2lnkea7gvmS3s59rKMSBMafIa85Nyp8hMm/E9XBJgW+e91FLe6q0GZ4
 /LzUjaTV+7PSJR1sNgU4k7QpdOciuNtqsvU8NXX4kIu+HnNiVqKAZxzE4I6dx6r8gKAZ
 CBgA==
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=nSERJ/0ipU+OAZKibo4XfuxaTijFZp30rP8PyOSouxw=;
 b=WUvNd6t2Npf4oHpZAmamCOOxglwbsX0qgbLvg7lYx2N06Px3hI8h08K0/friskqTCn
 zYqBBWRE9ESgu0TH/Y6YGOT1dCyFQAI5s8FOetfdkPbOjp3zUUIeEXBv5yI85ER9LWGN
 QzZrhAVlWjQLx35xfxLAUMstJnnN5N0/3X/Xu9pzZZqLDx+H2+NoCHKQZkLI95OVZ8ZQ
 oqrwueSAcRSTMgQOJxU8jgrFjBRYdx5GjhNHEEd997m66sNdJhX68mxlLjExkRnq5gbC
 GPTpvsnxPT0g9AsPD3e8pY7yBrFvhmaE+4TXEEm2RyevPQRlL+uTZEP1cIWrk1HHKf+t
 J8Ug==
X-Gm-Message-State: AOAM530uxzibdlAUIkyDxkokKBi6oGdzS+DIhinEcAf/d0Ew9Y9jXjvY
 sCZazPU02UQpQyLbtTC/yPk=
X-Google-Smtp-Source: ABdhPJxjJGXzGEntnrnict1WeHLvPyFMPiUIowSPNa3LBuMjvrAUUEqSdGRGFjKYbqibn/kG3CA9OQ==
X-Received: by 2002:a1c:9c0c:: with SMTP id f12mr1085463wme.179.1593904368203; 
 Sat, 04 Jul 2020 16:12:48 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id e17sm17741691wrr.88.2020.07.04.16.12.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sat, 04 Jul 2020 16:12:47 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN>
 <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN>
Date: Sun, 05 Jul 2020 00:12:46 +0100
In-Reply-To: <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> (Dmitry Gutov's
 message of "Sun, 5 Jul 2020 00:06:18 +0300")
Message-ID: <87d05aoowh.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 04.07.2020 14:00, Jo=C3=A3o T=C3=A1vora wrote:
>> I had intended to streamline
>> that release together with these async-related developments, but reality
>> (and mostly Dmitry:-)  intervened.
>
> To be fair to yours truly, though, AFAIK we are the only two people in
> this discussion who maintain third-party eldoc clients, or work on=20
> integrated development experience in general.
>
> That's a pretty sad state of affairs, BTW.

I actually have multiple people working with me in Eglot, potentially
eager to see how things in Emacs core can be solved properly and
effectively, and being utterly disappointed by your opposition in this
eldoc.el case.  That's the sad state of affairs IMO.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 05 Jul 2020 12:04:02 +0000
Resent-Message-ID: <handler.41531.B41531.15939506413430 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15939506413430
          (code B ref 41531); Sun, 05 Jul 2020 12:04:02 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jul 2020 12:04:01 +0000
Received: from localhost ([127.0.0.1]:60167 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1js3NI-0000tE-QE
	for submit <at> debbugs.gnu.org; Sun, 05 Jul 2020 08:04:01 -0400
Received: from mail-wr1-f66.google.com ([209.85.221.66]:36801)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1js3NF-0000sy-S2
 for 41531 <at> debbugs.gnu.org; Sun, 05 Jul 2020 08:03:59 -0400
Received: by mail-wr1-f66.google.com with SMTP id k6so37783141wrn.3
 for <41531 <at> debbugs.gnu.org>; Sun, 05 Jul 2020 05:03:57 -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=N+iaL/HybVXXg6rGMlteyVqNVTIbraO6UWN+cjt00R4=;
 b=mNEEL5T2yv9VBbuIV//fLz3ykYkbF/SZGepqH8L2SxL0cGraf+EZGq2DcfD4vvVONZ
 CzOseNW8PMXBI30wJhcvYLpTPzNqdx0YILTEL+H94OKQ9lFTpMbEfa5R77Ga2VuSngrl
 2uYO3vdFr/F8l3uOve6j/DeRS4ynhpAZeNHH4YWs66oVVJZULm181wKFkAfNXOcuuSkK
 JzbvsSmkk1ZQ5vY5NXkRTsgiR4cWz+8utgqfRyoJWd68HRqVv5ymSvvGrorgk8K9MDL0
 M8ixiVIJSciWcpLAoqQWy/sAlTulOVnBaIs8A5eeNmTGLrutDWDxDDhJMDXpSbxWIGv7
 c6tA==
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=N+iaL/HybVXXg6rGMlteyVqNVTIbraO6UWN+cjt00R4=;
 b=Hw5qoxD3VuMTj23DMMK7MjT+ooUADej8pGG+SODS/ouPAyMOgHIfD915hPySlqdOv5
 xXXx/FpPLNU4/HTlgapPXlVl966oB9HkytwMLJYR7RaCK3jiJ8c1pxPtpYdoPSt69AC3
 U5/rKNDljBOnN+0lolPvGZ9+NNUXPuVuf5URz9vxoRfZH9iq8Oo/qUnex0V2tbWtuHww
 O5hN0ZCPk3Ka8uWqVYngIxFPVIRmqNMsRaqI7IZ0IsscCPhbJf2gEpd2x9FJ3ThjqVIO
 M/APb1u1Xgtoj7zGv7QIvylChSvRXyY8j3BXdzf4t2AvvVkbcRGjSOepPoV4NOuu/EQO
 Sucw==
X-Gm-Message-State: AOAM530biVllWCsDr7QCPSzBt1cfKXOs681Ror/Arjwj/XJpeAR8u/vt
 5vNFNn4xT3V6cL7i3NQyuyE=
X-Google-Smtp-Source: ABdhPJz5z18M734ZWllWD4h/l6CJ2IrD4RdfcHNTB7CN67yaFiG/zTkPXuWQ+eOGK/g9ynzqw8xGqg==
X-Received: by 2002:adf:e60a:: with SMTP id p10mr42289122wrm.181.1593950631904; 
 Sun, 05 Jul 2020 05:03:51 -0700 (PDT)
Received: from krug (89-180-156-25.net.novis.pt. [89.180.156.25])
 by smtp.gmail.com with ESMTPSA id z1sm20049371wru.30.2020.07.05.05.03.50
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Sun, 05 Jul 2020 05:03:50 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN>
Date: Sun, 05 Jul 2020 13:03:48 +0100
In-Reply-To: <83k0zjvi4c.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jul
 2020 10:45:07 +0300")
Message-ID: <87o8oui2xn.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:

>> -(defun eldoc-message (&optional string)
>> +(make-obsolete
>> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0")
>
> Isn't the version part of the obsolete message supposed to tell the
> version of Emacs?

Stuck with "1.1.0", because of the GNU ELPA criterion.  But maybe the
string could be "1.1.0-elpa" or something like that.

> The change to the number of arguments of the functions in the
> eldoc-documentation-functions hook is backward-incompatible, isn't it?
> I see you've changed the relevant functions in our sources, but what
> about 3rd-party packages?

Answered this already.

> Also, the doc string of this hook needs clarification regarding the
> arguments: it first says that CALLBACK is the only mandatory argument
> to the hook functions, but then, out of the blue, appear additional
> arguments DOCSTRING and a list of key-value pairs.  Confusing.

Changed that paragraph to

   To call the CALLBACK function, the hook function must pass it an
   obligatory argument DOCSTRING, a string containing the
   documentation, followed by an optional list of keyword-value
   pairs of the form (:KEY VALUE :KEY2 VALUE2...).  KEY can be:

The situation is very similar to Flymake's flymake-diagnostic-functions.
If you still find this docstring confusing, maybe I should copy that
docstring's structure.

> The doc strings have some words in UK English spelling "(e.g.,
> "honour"), please fix that.  Also, please make sure comments all start
> with a capital letter, end with a period, and comprise full English
> sentences.

I fixed all I could find, but is this a a hard rule?  I like to break it
once in a while:

    ;; We have to foo bar separately ...
    (foo bar)
    ;; ... because the bazness might be too quuxy.
    (if (quux) (foo baz))

I ended up not doing that this time, though.

> The doc string of eldoc-documentation-compose doesn't say a word about
> the function's argument.

I fixed that by creating a helper eldoc--documentation-compose-1 that
both eldoc-documentation-compose and eldoc-documentation-compose-eagerly
call.  I describe the arg in the helper.

> This doc string doesn't explain the use of the timer, it explains the
> reason for its existence.  It should also describe the use:

See the new version below.  I think it is sufficient.  Be aware this is
an internal variable, we don't even let the user customize the time (we
could though, but I think it's overcomplicating, for now).

    (defvar eldoc--enthusiasm-curbing-timer nil
      "Timer used by the `eldoc-documentation-enthusiast' strategy.
    When a doc string is encountered, it must endure a certain amount
    of time unchallenged until it is displayed to the user.  This
    prevents blinking if a lower priority docstring comes in shortly
    before a higher priority one.")

> Last, but not least: the "async" part of the branch's name hints on
> some advanced and extremely useful functionality that these changes
> are supposed to allow, but I see no mention of that in NEWS and in the
> manual bits.  What did I miss?

I reworded it, caught a bug, and mentioned
eldoc-echo-area-use-multiline-p.  Let me know it if you're missing
anything.

Jo=C3=A3o

PS: Actually a proper section for Eldoc in the Emacs manual is probably
missing, but I don't have time to work on it straight away.  Or at least
I think the fix should go in first.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 05 Jul 2020 15:10:02 +0000
Resent-Message-ID: <handler.41531.B41531.159396175520556 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159396175520556
          (code B ref 41531); Sun, 05 Jul 2020 15:10:02 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jul 2020 15:09:15 +0000
Received: from localhost ([127.0.0.1]:32882 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1js6GZ-0005LT-I1
	for submit <at> debbugs.gnu.org; Sun, 05 Jul 2020 11:09:15 -0400
Received: from eggs.gnu.org ([209.51.188.92]:52712)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1js6GV-0005LD-Qq
 for 41531 <at> debbugs.gnu.org; Sun, 05 Jul 2020 11:09:14 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e]:33768)
 by eggs.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <eliz@HIDDEN>)
 id 1js6GP-0005Q9-Lj; Sun, 05 Jul 2020 11:09:05 -0400
Received: from [176.228.60.248] (port=3862 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 1js6GP-0002DO-4t; Sun, 05 Jul 2020 11:09:05 -0400
Date: Sun, 05 Jul 2020 18:09:08 +0300
Message-Id: <837dvit2wb.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87o8oui2xn.fsf@HIDDEN> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sun, 05 Jul 2020 13:03:48 +0100)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN> <87o8oui2xn.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: 41531 <at> debbugs.gnu.org,  monnier@HIDDEN,
>   andreyk.mad@HIDDEN,  dgutov@HIDDEN
> Date: Sun, 05 Jul 2020 13:03:48 +0100
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> -(defun eldoc-message (&optional string)
> >> +(make-obsolete
> >> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0")
> >
> > Isn't the version part of the obsolete message supposed to tell the
> > version of Emacs?
> 
> Stuck with "1.1.0", because of the GNU ELPA criterion.  But maybe the
> string could be "1.1.0-elpa" or something like that.

AFAIK, the obsolescence message we display says "since N.M.X", and the
intent is always to an Emacs version, right?  How can the user
understand that in this case you are talking about the version of some
other package?

> > The doc strings have some words in UK English spelling "(e.g.,
> > "honour"), please fix that.  Also, please make sure comments all start
> > with a capital letter, end with a period, and comprise full English
> > sentences.
> 
> I fixed all I could find, but is this a a hard rule?  I like to break it
> once in a while:
> 
>     ;; We have to foo bar separately ...
>     (foo bar)
>     ;; ... because the bazness might be too quuxy.
>     (if (quux) (foo baz))

This is fine.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 05 Jul 2020 15:14:02 +0000
Resent-Message-ID: <handler.41531.B41531.159396199420945 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, andreyk.mad@HIDDEN, dgutov@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159396199420945
          (code B ref 41531); Sun, 05 Jul 2020 15:14:02 +0000
Received: (at 41531) by debbugs.gnu.org; 5 Jul 2020 15:13:14 +0000
Received: from localhost ([127.0.0.1]:32893 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1js6KQ-0005Rl-Cx
	for submit <at> debbugs.gnu.org; Sun, 05 Jul 2020 11:13:14 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:14424)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1js6KO-0005RW-JM
 for 41531 <at> debbugs.gnu.org; Sun, 05 Jul 2020 11:13:12 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3BC48806C9;
 Sun,  5 Jul 2020 11:13:07 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 939F980640;
 Sun,  5 Jul 2020 11:13:05 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1593961985;
 bh=d8p1k07pI8fOCj31ibI6Y5kNg/WEmPPWzrKt3LaSCq4=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=ibKriJv9pz841c8WFk/7qGyswvrXst+WSYzChURlsspRqO6TDOSn8qDnOtpgKMrj4
 /L/VRnY9X+vc3iFZpvv3sBa7IoheTkhxf9mRfrs1gGWmMmhhOMxhtmLhnqkRhFNDBi
 Cwi0KUQ+9JmGRIf0CxmQAToI59gSg5tQtnM06vRzPKNq0UBs0AEWWGJ1QVUZBYoIkH
 EIETambOGaSJRheMEfe9zhMXTb5bkPpdV2t1izXfW/R+sOjnysGZxiB0lM6GD18VJP
 2LGPc2yar8Qs2OeAHstRiHMzhSKWDUtnSWhIj6CIS9CVRRjouewum1Cx9U1rVdy7g3
 hdNJUqJdHbn/g==
Received: from alfajor (unknown [157.52.0.200])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 18933120264;
 Sun,  5 Jul 2020 11:13:05 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwv3666ov1m.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN> <87o8oui2xn.fsf@HIDDEN>
Date: Sun, 05 Jul 2020 11:13:04 -0400
In-Reply-To: <87o8oui2xn.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sun, 05
 Jul 2020 13:03:48 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.024 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

>>> -(defun eldoc-message (&optional string)
>>> +(make-obsolete
>>> + 'eldoc-message "use `eldoc-documentation-functions' instead." "1.1.0")
>>
>> Isn't the version part of the obsolete message supposed to tell the
>> version of Emacs?
>
> Stuck with "1.1.0", because of the GNU ELPA criterion.  But maybe the
> string could be "1.1.0-elpa" or something like that.

I recommend "eldoc-1.1.0" to clarify which version number we're talking about.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 00:44:01 +0000
Resent-Message-ID: <handler.41531.B41531.159408260926528 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159408260926528
          (code B ref 41531); Tue, 07 Jul 2020 00:44:01 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 00:43:29 +0000
Received: from localhost ([127.0.0.1]:35152 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsbho-0006to-NU
	for submit <at> debbugs.gnu.org; Mon, 06 Jul 2020 20:43:28 -0400
Received: from mail-wm1-f51.google.com ([209.85.128.51]:33664)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jsbhk-0006tY-Sj
 for 41531 <at> debbugs.gnu.org; Mon, 06 Jul 2020 20:43:27 -0400
Received: by mail-wm1-f51.google.com with SMTP id a6so648873wmm.0
 for <41531 <at> debbugs.gnu.org>; Mon, 06 Jul 2020 17:43:24 -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=QqVm2ydI+m9c3MzcchMxUR6Lqgs9G6TQPGnXe0eu0mQ=;
 b=XvYUlrVv7clNsq1wnZp8wxJbADjr9iQvxzUAAfEt7MVL/1LtmGM4NORONW7LC7gbH0
 nrIMCqqJ6gC+HrfR+P+aj/kWFgtoEK9mM62gWJiT7L7DVQe9jB6cqWYEKURrIF46KsTU
 aJk97XPQAziE7IgbZQ7tSK+VOfdrETcYSKuSE2bEItSzaY4oOmmY0wmsblVKRryUo8g8
 I7ItEHDPvC0Mxs6m9jJBHIqCaqdteTNIesLbm+1h8ozR03Y0qPrA99P04nRb/gIxFUGi
 jG1yFU1MmzXnilV7qDbDr5ASmyhbsyqZGJo2/cfmYLMxYR8y4YXEx1v0d9pmAerfZH9z
 jttQ==
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=QqVm2ydI+m9c3MzcchMxUR6Lqgs9G6TQPGnXe0eu0mQ=;
 b=YrRMKqKuq5MiSsOPvxzJAumeLhcPSwqwFpxcrFsQ2hXqFcZ8S56KM/shZEjxR/tYl8
 y77TWFGoFDjQJLYQHSt9qBi+ATr5Ea8782mF8n0Ur9SX5wgp+mrg3rsKtquN9EpK/UQm
 IQAunKd9gFj/ytTqkNwwZhB+I5bjnJxEFm0KBSFFH6RmzWkFbvXWsa5PA15fHQ0fZ3B2
 8O2F+BuCUkeLtqJsSq7DmNzL2bYCFBS9Um1TNFuBc82G3jzD9T/EsS8SHIVklAWw8pzP
 kQXivbbP/nI6y//CteYFvyKhvr2zSr1BcMK7pX8dCR21R0nE54fxzwoNEltjnJhSLVhk
 GKXQ==
X-Gm-Message-State: AOAM530jsnlv1v5e74pbHMDIVb9OkUSE2jYXOPaAFe8MtJxxG28ew2vt
 9SqAqzLxXJQfbdNLvLyIGpE=
X-Google-Smtp-Source: ABdhPJxI2rlWZrjCihmqISJIIbAvkk6s7Id2kl/F6jpv2xuztv0fFrshNY9YNkNOtkIHFS53/Y/ClA==
X-Received: by 2002:a7b:c7d2:: with SMTP id z18mr1571050wmk.149.1594082598894; 
 Mon, 06 Jul 2020 17:43:18 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id m16sm21998989wro.0.2020.07.06.17.43.17
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jul 2020 17:43:18 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN>
 <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> <87d05aoowh.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN>
Date: Tue, 7 Jul 2020 03:43:16 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87d05aoowh.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 05.07.2020 02:12, João Távora wrote:
> I actually have multiple people working with me in Eglot, potentially
> eager to see how things in Emacs core can be solved properly and
> effectively, and being utterly disappointed by your opposition in this
> eldoc.el case.  That's the sad state of affairs IMO.

A part of "solving things properly" is listening to feedback.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 03:02:01 +0000
Resent-Message-ID: <handler.41531.B41531.15940908927018 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15940908927018
          (code B ref 41531); Tue, 07 Jul 2020 03:02:01 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 03:01:32 +0000
Received: from localhost ([127.0.0.1]:35232 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsdrP-0001p7-Kn
	for submit <at> debbugs.gnu.org; Mon, 06 Jul 2020 23:01:32 -0400
Received: from mail-wr1-f52.google.com ([209.85.221.52]:46303)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jsdrM-0001ot-UD
 for 41531 <at> debbugs.gnu.org; Mon, 06 Jul 2020 23:01:30 -0400
Received: by mail-wr1-f52.google.com with SMTP id r12so43470406wrj.13
 for <41531 <at> debbugs.gnu.org>; Mon, 06 Jul 2020 20:01:28 -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=/4/eMZe+wU9ly30PODQJyvOmz89mN/3C5BM16El2qzY=;
 b=aW7I+d+obJvoQURp+OYT6eDOIl8nJnWIO7ph9apJQudj9kSqB67NfSgWP3RHZ8Sc9s
 XQQKVKE6jNS7k5RM/jSEr5qxC5Hb2l7ZzPqG/kIo0htITIOp01r68l3VF8E7rL+dnU8t
 PMwwQgFGyX67kG/TRBBmGt03UCoWXjz+Xl7dV4Jmzuq9Xev6PVESX+AZrr79eLRe+Z5c
 RQPUxX6YlDiBnRwzqWIOchwIU5nKOZx0S5zaIG9wec0h6qyEIv4UxxLrEIohimdxuBfV
 uXE0dp8juTe6Ej5o2ODHAlwzuWRsqOmzTRpyo7Y281kMBVcSJWeU4pcdHeQyGS58hHiE
 GwxA==
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=/4/eMZe+wU9ly30PODQJyvOmz89mN/3C5BM16El2qzY=;
 b=pHmCwnRIWykar5fSKs2DH6q57HXq57WmbMx4wBOi2J8BNBPJOkcWdB1xFR6v+ibu4F
 /DhZDuoJGcDk7LJFq4Csj47+4A/WGU3boN2RA2dbJ35zP/kpf9jznYDEUlg0qAlCD0n+
 5qxcbP3cJkmMUNNmLrWUViD3yVRq4mJB0gVFGLmc64DUHqjxWyLFno8aO5t7gTDfcmVz
 Xrxrj9G4mqrH1v68SQXy1ahYEEnAr6WVSdFTk1DF+Q+7vP1KACknN2Zc4fJHbeIMvP3I
 LBjci+WHtNRDP3Di2vnKBZ6FWpfkSHqs5KViueBA+7H9DYFWmEzOkeJzQ8iQ5MAb2DMw
 elgg==
X-Gm-Message-State: AOAM5309OD+0cllJ4lby/tCr94Dr7wHeN1lyjb6Vzt5Hxur2WHPvNnCj
 ow+z3Pm9ZadTU1RNnY+rj84=
X-Google-Smtp-Source: ABdhPJwDVflGGmUrSOE9SFV8BSWZiN0M6/Az5u6KdNF5YPkZlEEer8rXIPGN751wy3MvR4xlkjeEqg==
X-Received: by 2002:a5d:484b:: with SMTP id n11mr49491876wrs.320.1594090882869; 
 Mon, 06 Jul 2020 20:01:22 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id e17sm25716592wrr.88.2020.07.06.20.01.21
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 06 Jul 2020 20:01:21 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
Date: Tue, 7 Jul 2020 06:01:20 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87h7umop62.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 05.07.2020 02:07, João Távora wrote:
> Dmitry Gutov <dgutov@HIDDEN> writes:
> 
>> [that is the] "transition" I meant here.
>>
>> If you have other questions, please ask.

I meant questions about futures as pertaining to eldoc, of course. I 
have other uses in mind, but redoing existing features is a less urgent 
endeavor. E.g., Flymake is stable, and I don't have any particular bugs 
in mind that need solving. So I'd be fine with keeping it as is. Unless 
someone wanted to take advantage of extra features that futures provide.

> If it wasn't clear, my suggestion is that you send your earlier
> dimtry-futures.el (as I am temporarily dubbing it, for clarity) to
> emacs-devel, along with a rationale for why it is needed and where it
> can be useful, not only in eldoc.el but in other places in Emacs that
> use callbacks like like url.el, flymake.el, jsonrpc.rl, timers,
> completion, processes, etc.  You may want to include a short comparison
> to Christopher Wellon's aio.el, if you have studied it.

Yes, will do.

But note that when I argue for futures, it's for basically any 
implementation that has a container for such values, and a set of common 
functions for manipulating them. Christopher's version would serve that 
just fine (with copyright assignment signed). Which exact version to 
choose, however, can indeed be discussed separately.

>> I think I have described at length the very simple idea of what it is
>> supposed to improve: provide a standard primitive and a library of
>> composition/manipulation functions that would make these operations
>> simpler. Which can be used in Emacs core, and in clients of the
>> various facilities and expose future-based interfaces.
> 
> Maybe I missed something, but I don't consider our discussion an
> at-length discussion.

It also wasn't a discussion really. Too one-sided.

>> You seem to be in a hurry to get this in for some reason, but I'm fine
>> with waiting a little more, if we get a better result.
> 
> I want to fix longstanding problems in Eglot.  I have limited resources,
> mainly time.  It is you who seem intent on not letting this go in, as if
> you won't be able to prove that "better result" after it does.  This is
> absurd: if you do show it to be better, then we should migrate eldoc.el
> etc to futures.  ...as I've said a trillion times already at this point.

Please don't make it sound as if I'm the only one here having a strong 
opinion about proposed code. You disregarded the simple solution in 
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41531#8, and then went on 
with your own vision of of "simple" function based async, full on with 
extra features and additional incompatible API changes.

>> Please recall how you rejected my proposal along the same lines.
> 
> I don't remember your proposal fixing anything in eldoc.el, you merely
> suggested I experimented with a technique.  Which I actually did, and I
> didn't see any advantage in it.

It certainly did away with clients having to call eldoc-message. And if 
shorter code and better backward compatibility are not advantages, we 
might disagree hard on the meaning of the word.

>> But the problem you seem to be urgent to fix (having eldoc-message
>> called from client code) is not so terrible that we can't wait until
>> the future-related discussion at least has had a chance to happen.
> 
> I've explained repeatedly: this is holding up multiple things in Eglot.
> I want Eglot to serve diagnostic messages, and various kinds of
> automatically gathered information about the "things at point" all
> through eldoc.el.  Then move on to better stuff, of which there is a lot
> in LSP, as you well know.  Also, this fixes SLY and SLIME too, both
> hacking their way through eldoc.el.  Possibly the same for CIDER and
> other such extensions.  This also opens up eldoc.el in non-async
> situations as well, such as elisp-mode.el.  Just read the patch.

Aside: given that this discussion has user interface in mind, it needs 
more consideration of actual user experiences we'd want to allow. Ones 
not provided by eldoc itself as well. For instance, I think we sooner or 
later should have a callsig floating popup (in the vein of MS's editors) 
as an alternative to showing the signature in the echo area only.

 > But very well then, let's
 > have those non-futures objections in this bug report, the sooner the
 > better.

To be sure, they will also contain the "how we could do this better" 
kind of arguments.

Let's start with the basics:

The new API is incompatible with the previous one, it requires changing 
a lot of functions (though admittedly in a minor way). Which is easy to 
miss, as evidenced by describe-char-eldoc which still doesn't accept any 
arguments. Whereas we could limit ourselves to the change which would 
only make the clients use the different hook (or keep using the old one, 
for compatibility with older Flymake/Emacs versions).

The choice to require a return of a non-nil value if the callback is 
going to be used is also kinda odd (+1 control flow to test). What's the 
problem with using the callback synchronously if the doc is available 
right away?

The decision to double down on having different 
eldoc-documentation-strategy values seems odd to me in several respects.

First of all, if I understand the main motivation behind it, it's to 
delegate the implementation of asynchronous primitives to Eldoc. We 
don't want to bother with that in Eglot, etc. But you mentioned "a type 
of docstring" to be returned in the discussion (and the callbacks have 
the plist argument as a future proofing). If the type is a buffer, its 
contents might as well be created from several async calls, which would 
require the same async primitives (though rather in general purpose 
form) available on the client anyway. Though it doesn't seem to be 
necessary for LSP in common operations, it's unlikely to be the only 
such protocol we'd ever want to support.

The strategies themselves:

- eldoc-documentation-enthusiast: What's the difference compared to the 
'default' one? Sacrificing CPU load for lower latency? It's an odd 
choice to force the user to make. The only people who can make an ideal 
decision regarding this are probably the authors of 
eldoc-documentation-functions, but it wouldn't help if 
eldoc-documentation-functions has functions coming from different 
authors, facilities, etc.

- eldoc-documentation-compose: Okay, this is kinda interesting (though 
not essential), and the implementation is not working as well as I'd 
hoped it would. It makes the echo area blink up and down as I move the 
cursor around. There's no expected truncation of individual docstrings 
when they don't fit in the window's width. And I don't understand what 
you expect it to do if several docstrings are multiline, and as an 
aggregate they don't fit the target height. I think the only reasonably 
predictable behavior would be to truncate each of them to one line, always.

- eldoc-documentation-compose-eagerly: Ooh, now I think I see why 
documentation functions have to return these non-nil, non-string values. 
Is it that this particular strategy wouldn't have to wait too long for 
documentation functions that never intended to call back? Returning 
futures instead (when async is needed) would provide this kind of 
guarantee without the seeming duplication of signals.

On a related note, I believe some facilities might want to use only 
certain "kinds" of documentation functions (as indicated by the plist 
arguments). If the plist is only provided together with the response, 
there is no way to avoid unnecessary computations (e.g. making HTTP 
requests that return some other kinds of values). If the plist was 
returned together with a future value, however, it would be easy to do, 
as long as we document that the futures should start the computation 
until a callback is provided (if possible, at least).

And in a different high-level argument: you stated that you intend to 
have Eglot use a non-default value of eldoc-documentation-strategy. 
Which would basically have you use Eldoc as a library, controlling both 
the list of documentation functions and how they are composed.

Whereas having the eldoc-documentation-strategy defcustom at all makes 
it seem like the user's choice, and that all Eldoc clients must be able 
to perform well under any strategy chosen by the user. We might want to 
think twice before introducing such responsibility.

Next, eldoc-print-current-symbol-info is a mess, very hard to follow. I 
am frankly offended that you argued that both ad-hoc futures I showed, 
or any potential "proper" ones would make backtraces hard to read and 
debug, and then introduced this kind of control flow with callbacks 
calling dynamically generated callbacks, retrieved from a variable 
dynamically set in a caller function up the stack (to be clear: I think 
having eldoc--make-callback variable at all is a bad idea). This should 
very well be possible to untangle in the future, but I'd rather not have 
code like this in Emacs if we can help it.

Further, having all strategies basically delegate to hardcoded options 
inside eldoc-print-current-symbol-info seems to confirm that the set of 
available strategies is a closed one. Which is not what I would expect 
from a variable called eldoc-documentation-strategy.

These are my objections, for now. I'll have to study eldoc--handle-docs 
a bit later, but any problems it has are probably orthogonal to the rest 
of the list.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 10:57:02 +0000
Resent-Message-ID: <handler.41531.B41531.159411937629506 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159411937629506
          (code B ref 41531); Tue, 07 Jul 2020 10:57:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 10:56:16 +0000
Received: from localhost ([127.0.0.1]:35569 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jslGp-0007fp-SE
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 06:56:16 -0400
Received: from mail-wr1-f51.google.com ([209.85.221.51]:46304)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jslGl-0007fX-DW
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 06:56:15 -0400
Received: by mail-wr1-f51.google.com with SMTP id r12so44593432wrj.13
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 03:56:11 -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=wFo82F9BYxp9h6i7nk/imamXlrR7Jt6bw9l2u15Wbww=;
 b=sEkMZ2OLIP4WLZJ67mb2oFsazmXs04MkTxdUN+INt7E8+fzpVl6/xFRMqdRbjkfsTU
 kVYBQVoy0jduDUjqRwC4UNB9Zu1pJG7UFpoZIgXnJa0O1Fz6FWNnj5oGSY29FVhqXuY1
 F7QNjmCJcsWbbDg1YgCNd/5ehW8TQyY5xYg9FbZQhQgywj2Bk5u6kLfQr0eKPNAMeVeO
 n1H0LexF2B5udv70L8hHNmlBsO2OImfUW3ocavONhEAL9RBBifzXUaqXW7w2Bn9XTpHx
 6oSc/bc+zQO/iAIRlJ6lL4i6MjlKlv1uouzk91g3lgwcY4D36+FNGFzf52KcnvX1PcVZ
 gDpA==
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=wFo82F9BYxp9h6i7nk/imamXlrR7Jt6bw9l2u15Wbww=;
 b=se+hAYrn4+Waec6HUfgxqZ3czAtQOIXlEGM1axmGROtMgcxNw1m3C4rRpjmgnU9mr2
 FgJDn32Mr+1OhjwbWQf2k1ncgR4aGjC1KX3K5ShrY0ymC7eYLBzKUJaXRH5ouXK6rwEM
 Y7AGHunNjBYdje6jA6o3IqVq9ySEqyW5A8Lxg9VDE4fr6J06GYoAHKi5aatVqVN+2S4J
 lFDoxyFeP5i5YUS07pb+gt0a9z+SJQLeUqHHynKPJOo7SxZw0NTg5U/jJtSJOIUV6Flt
 SOHlL+jnY/mdsLcyqBVX3XLs+8Xn07XOAuBD0y7i4VuLxobKMZW87byUaMn7zbwqdrAq
 QVFw==
X-Gm-Message-State: AOAM533N9gyHBBETQfvDMvPIldlu2x+kJ6S1u2TnvCVaam+TbvtMplL5
 HcJqA9lewaK7z56k68axC6c=
X-Google-Smtp-Source: ABdhPJx8/O0plSKGWR3GUtLHztOZzY+VOjO4TzInD3vL5pIHjPaFi4Ad2mkMox86/V/YG6OvSLqg7w==
X-Received: by 2002:adf:f34c:: with SMTP id e12mr50934837wrp.46.1594119365300; 
 Tue, 07 Jul 2020 03:56:05 -0700 (PDT)
Received: from krug (6.213.115.89.rev.vodafone.pt. [89.115.213.6])
 by smtp.gmail.com with ESMTPSA id d18sm599393wrj.8.2020.07.07.03.56.03
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jul 2020 03:56:04 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
Date: Tue, 07 Jul 2020 11:56:01 +0100
In-Reply-To: <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> (Dmitry Gutov's
 message of "Tue, 7 Jul 2020 06:01:20 +0300")
Message-ID: <877dvfiofy.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:

> Please don't make it sound as if I'm the only one here having a strong
> opinion about proposed code. You disregarded the simple solution in=20
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531#8, and then went

Are you in any way trying to say that you presented a "simple solution"
that somehow magically solves the problems of Eldoc?  If you do, you're
living in conflict with reality.

There is the problem to be solved.  And then there are techniques for
solving the problem.  These are two entirely separate things.  To be
absolutely clear: you have not, ever, proposed an alternate solution to
the Eldoc async _problem_.

You talked and talked and presented your favourite async handling
techniques, like having functions return functions that return
functions.  You contented that I -- not you -- should work with it to
solve the problem.

Callbacks, futures, promises, ad-hoc or proper, are just techniques.  I
tried a couple techniques, including a basic futures-based one proposed
by Stefan.  I didn't find any as compelling as the simplest and most
widely used in Emacs: callbacks.

For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE: I
just don't use these Eldoc fixes to shoehorn something rushedly into
Emacs.  Make a new thread, or join the existing one:

    https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00935.html

Afterwards, propose a change to the technique, not only in Eldoc but
elsewhere, too.  This idea is so simple that it boggles the mind that
you don't grasp it.

> urgent endeavor. E.g., Flymake is stable, and I don't have any
> particular bugs in mind that need solving.

Great.  I'll just note here that it uses exactly the same technique I'm
proposing in Eldoc to communicate with multiple backends: it's curious
how that doesn't bother you.  I would reasonably expect "futures" or
something else its implementation much simpler too.

> Aside: given that this discussion has user interface in mind, it needs
> more consideration of actual user experiences we'd want to allow. Ones=20
> not provided by eldoc itself as well. For instance, I think we sooner
> or later should have a callsig floating popup (in the vein of MS's
> editors) as an alternative to showing the signature in the echo area
> only.

That is addressed in a comment in eldoc-docs

      ;; Finally, output to the echo area.  We handle the
      ;; `truncate-sym-name-if-fit' special case first, by selecting a
      ;; top-section of the `*eldoc' buffer.  I'm pretty sure nicer
      ;; strategies can be used here, probably by splitting this
      ;; function into some `eldoc-display-functions' special hook.

I agree there is ample space for improvement, including a=20
"floating popup" (which I wouldn't limit to callsigs though).  Make
another bug report to study this.

> The new API is incompatible with the previous one, it requires
> changing a lot of functions (though admittedly in a minor way).

This is demonstrably false. As I've explained to Eli there is no
incompatibility in practice.  0 (zero) third-party extensions make use
of the protocol being changed from Eldoc 1.0.0 to Eldoc 1.1.0, unless
you're stalling here to secretly work on one.

But if we really, really wanted to, it's easy to get rid of the
arguments, too, with a variation to the callback technique.  I just
don't think it's worth it: a technique is a technique.

> is easy to miss, as evidenced by describe-char-eldoc which still
> doesn't accept any arguments.

Oh, an actual useful comment! Easily solved, thanks.  And it was only
"missed" because it wasn't used anywhere.

> Whereas we could limit ourselves to the change which would only make
> the clients use the different hook (or keep using the old one, for
> compatibility with older Flymake/Emacs versions).

Compatibility to the old `eldoc-documentation-function' protocol is
fully guaranteed.

> The choice to require a return of a non-nil value if the callback is
> going to be used is also kinda odd (+1 control flow to test). What's
> the problem with using the callback synchronously if the doc is
> available right away?

Nothing, you can do it.  As long as you return non-nil, non-string.  But
if you are are going to synchronously call the callback on a string, you
might as well return that string, just seems simpler.

> The decision to double down on having different
> eldoc-documentation-strategy values seems odd to me in several
> respects.
>
> First of all, if I understand the main motivation behind it, it's to
> delegate the implementation of asynchronous primitives to Eldoc.

It's rather to make clients don't worry about the synchronization.  Not
specifically to make Eldoc worry about it.  As soon as you and others
come up with the uber-async library, I think Eldoc and Flymake and many
others will be very pleased to delegate work to it.

> We don't want to bother with that in Eglot, etc. But you mentioned "a
> type of docstring" to be returned in the discussion (and the callbacks
> have the plist argument as a future proofing). If the type is a
> buffer, its contents might as well be created from several async calls

If you want to support "buffers" as a "type of docstring", just do that:
make buffers a type of docstring.  The obvious way is to have multiple
sources produce multiple buffers.

Thing: why would you ever want to put buffer-joining complexity in the
client?  They're not in the business of doing async gymnastics, they're
in the business of serving things coming from servers as efficiently and
effectively as possible.

> , which would require the same async primitives (though rather in
> general purpose form) available on the client anyway. Though it
> doesn't seem to be necessary for LSP in common operations, it's
> unlikely to be the only such protocol we'd ever want to support.

I don't know about that, but if we did, the current mechanism work
nicely for the example you presented.

> The strategies themselves:
>
> - eldoc-documentation-enthusiast: What's the difference compared to
> the 'default' one? Sacrificing CPU load for lower latency? It's an odd
> choice to force the user to make. The only people who can make an
> ideal decision regarding this are probably the authors of
> eldoc-documentation-functions, but it wouldn't help if
> eldoc-documentation-functions has functions coming from different
> authors, facilities, etc.

Has nothing to do with CPU.  This is the way Eglot works now, or at
least tries to: there are two delayed doc-producing backends, and
neither is guaranteed to complete.  One has priority over the other (and
special hooks are a decent, standard Emacs way to manage priority)

Eglot shows the lower-priority one if it shows it can survive for more
than x seconds (currently x =3D 0.3, uncustomizable).  No more doc
blinking.

> - eldoc-documentation-compose: Okay, this is kinda interesting (though
>   not essential),

> I think the only reasonably predictable behavior would be to truncate
> each of them to one line, always.

That's a display problem, not a composition problem For now it works OK
for one liners and also multiple multi-liners.  Displaying doc is not
the main goal of these patches, there is certainly room for improvement,
as I said above.

> - eldoc-documentation-compose-eagerly: Ooh, now I think I see why
> Returning futures instead (when async is needed) would provide this
> kind of guarantee without the seeming duplication of signals.

Can't let go of that futures drum, can you?  It'd be a pleasure to see
you walk the walk.

> On a related note, I believe some facilities might want to use only
> certain "kinds" of documentation functions (as indicated by the plist=20
> arguments). If the plist is only provided together with the response,
> there is no way to avoid unnecessary computations (e.g. making HTTP=20
> requests that return some other kinds of values). If the plist was
> returned together with a future value, however, it would be easy to
> do, as long as we document that the futures should start the
> computation until a callback is provided (if possible, at least).

Save it for your future futures implementation.

> And in a different high-level argument: you stated that you intend to
> have Eglot use a non-default value of eldoc-documentation-strategy.=20

OK, but this has nothing to do with Eldoc, does it?  Make a bug report
for Eglot, I'll explain why it does this, and maybe I'll change it..

> Next, eldoc-print-current-symbol-info is a mess, very hard to
> follow. I am frankly offended that you argued that both ad-hoc futures

I meant no effense.

> idea). This should very well be possible to untangle in the future,
> but I'd rather not have code like this in Emacs if we can help it.

You're such an ace programmer that you code alternatives that are so
brief that they occupy no code at all!

> Further, having all strategies basically delegate to hardcoded options
> inside eldoc-print-current-symbol-info seems to confirm that the set
> of available strategies is a closed one. Which is not what I would
> expect from a variable called eldoc-documentation-strategy.

There are four strategies to choose from but you can make more.  What
did you have in mind?=20=20

> These are my objections, for now. I'll have to study
> eldoc--handle-docs a bit later, but any problems it has are probably
> orthogonal to the rest of the list.

Thanks.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 11:00:02 +0000
Resent-Message-ID: <handler.41531.B41531.159411954829768 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159411954829768
          (code B ref 41531); Tue, 07 Jul 2020 11:00:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 10:59:08 +0000
Received: from localhost ([127.0.0.1]:35573 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jslJc-0007k4-LP
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 06:59:08 -0400
Received: from mail-wr1-f49.google.com ([209.85.221.49]:45947)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jslJa-0007ja-VB
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 06:59:08 -0400
Received: by mail-wr1-f49.google.com with SMTP id s10so44624340wrw.12
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 03:59:06 -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=A9hUfR3hgsQN81wDuwZMJACUBAOm1S03sRPR4TXX1jc=;
 b=TaJ6nYdvu4ccTiVBkfHLH0RFQQpLLUh3CCvk54aIAZN8TYqQriEGPI1LAiOHZgJuNE
 pe14yRCiteAi+2e1ujNQDDw1CtlFil9eH7DcDYsfjcDb2n7y8GmpLiFf0V5mLUqA6Tu7
 3YPJCEI4XoEhPk8iXvEkjn8VlA2QXf/7Kmvaas+N/WxwrIf8ijwo0c7kvy6tdPgTC+XP
 a2zPM6H78yWoS1Eh7CjpvnlC2YPu+YrwUY0GFR8f/CsqKTNN4irxNjT5+i3qyQTEoHxc
 kQs5a3O0Dofl45k4Wu6huAc1epI4cGMpyVv5GEW6LNKnRm0msrN19mQUjEldH0H39nuQ
 mVMA==
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=A9hUfR3hgsQN81wDuwZMJACUBAOm1S03sRPR4TXX1jc=;
 b=QTLStpJLs3f9MP7XvnaCvzr8PgRiqXWxT4Hqu6zS3KRWmJxEX5hSTJ9nQiq7Lx7tfR
 xxFmk8iM4M372bdsICAkcMZMifPcLySoNWlsw8vSx+pi3DFfEQzxMEn6/e70dIkoN26S
 8AxX4NK56diD1qqU0Q+gO/knaEeIhnA1/bGxDxztvIw918qq3EymUwoVbURevO7AmZIB
 aAiFiv7iQV7oXR3YDEjzb0AM4mVHZFsGUcZpCIKfGT9sYEyJSzIL3bcEbv6vkZzNYkMK
 JE/eob66sswabfn9aszm8VXrxAWrUph/kFXAMxSa8wlrIRd/wOLxoPGy3smk3Uc8bj3U
 7Osw==
X-Gm-Message-State: AOAM533UKCO3vCLJzk5VbivPbjfBhbL+V2g0gttQKSHs0pmQUC1d18IU
 EV+f6hUE00Jr0H/l2auSRjw=
X-Google-Smtp-Source: ABdhPJyA9XZCRUawrvP21+eNegUECd86jBrpAU86ECmV9vd1+o5MjqV6l8LwMUAbyGmMaupqTqAtWQ==
X-Received: by 2002:adf:dcd0:: with SMTP id x16mr51251651wrm.387.1594119541307; 
 Tue, 07 Jul 2020 03:59:01 -0700 (PDT)
Received: from krug (6.213.115.89.rev.vodafone.pt. [89.115.213.6])
 by smtp.gmail.com with ESMTPSA id z25sm524217wmk.28.2020.07.07.03.58.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jul 2020 03:59:00 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN>
 <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN>
 <87d05aoowh.fsf@HIDDEN>
 <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN>
Date: Tue, 07 Jul 2020 11:58:59 +0100
In-Reply-To: <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN> (Dmitry Gutov's
 message of "Tue, 7 Jul 2020 03:43:16 +0300")
Message-ID: <873663iob0.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 05.07.2020 02:12, Jo=C3=A3o T=C3=A1vora wrote:
>> I actually have multiple people working with me in Eglot, potentially
>> eager to see how things in Emacs core can be solved properly and
>> effectively, and being utterly disappointed by your opposition in this
>> eldoc.el case.  That's the sad state of affairs IMO.
>
> A part of "solving things properly" is listening to feedback.

I've told you this before: you mistake attention for obedience.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 12:24:02 +0000
Resent-Message-ID: <handler.41531.B41531.159412459613757 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, eliz@HIDDEN, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159412459613757
          (code B ref 41531); Tue, 07 Jul 2020 12:24:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 12:23:16 +0000
Received: from localhost ([127.0.0.1]:35675 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsmd2-0003Zo-B6
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 08:23:16 -0400
Received: from mail-wr1-f53.google.com ([209.85.221.53]:40183)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jsmcx-0003ZY-G4
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 08:23:15 -0400
Received: by mail-wr1-f53.google.com with SMTP id f2so16934431wrp.7
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 05:23:11 -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=eRPkloRyzfybOoXLTomCGi/gUBsnCI1bWgmB/tn33S4=;
 b=osXGyX7pwDOHfVeDBeRgQelLdPROItTWGzDByDfVyFtDDQjbwDJ0AwIS0VxhOwKbO8
 Q0+jjNFHn4divnZZ3FGldROMjemigVGR2xQedcoGayZWZOXuThH4dNjACj8OCGCHrsO/
 jJ/nXCAXX02TBpWCLzVb1mW+mapVyl3QWnH+tyiYJWcdovNe7HHs1CDj48AxzxoK704+
 GBkdnRiSuLRysNtvXnAm4cUMcC94sTSRxrq7yf0zT021iTjCF8hInK84L/VEIEr74ByY
 DaU7vIy1a6yd+f24TFLbgEkM0em47teJWFU5zAXBnZcy4VidyP/42dXLVojO0REN4sUL
 JW4A==
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=eRPkloRyzfybOoXLTomCGi/gUBsnCI1bWgmB/tn33S4=;
 b=dyTDgpZcLXJBLH7Ifau2WoyXw1K6QnqnC8exXaytbSNQ4YiCfsIeD2LWyHyMMq1yIg
 d069RT4PUKLeEJeLIITyVxjBYnfvq05ytw9mAl6IgFCUloXfI15dvRDF++zdaQwjeoIE
 I9ADsNcc6puczxcWVtz68TRV4+4q0d78CXWdAlbVB2q3fqm+Nn0uFsikKFgW6US647KF
 sFtOHuO9QW+5+24ZgG4yD3Rbry/cohaz8A0lB1fUW02IED52VXYzNN5VURUcx3tCu0+4
 b+zIDMwIdGJ8h7CPeYdem1xFdOHrFuVyRS8vE6aofL+68Kjn+9qASpexgzKB27TadSnu
 oxFA==
X-Gm-Message-State: AOAM531LduAHc/aUb0IOeVj9O2MplYhfoBCTdyAiIDRzEq1W3hFHR8NQ
 4WvSb/IKzNEequhqBmjG46Q=
X-Google-Smtp-Source: ABdhPJzKrZBk14peza7FVkJXffLe1A2uKrJTIOEZiKXHTTKgoSgKi98a/QQMONMgnTQeGqfb/VvC3Q==
X-Received: by 2002:adf:fe85:: with SMTP id l5mr50848850wrr.333.1594124585649; 
 Tue, 07 Jul 2020 05:23:05 -0700 (PDT)
Received: from krug (6.213.115.89.rev.vodafone.pt. [89.115.213.6])
 by smtp.gmail.com with ESMTPSA id j16sm867122wrt.7.2020.07.07.05.23.04
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jul 2020 05:23:04 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN>
Date: Tue, 07 Jul 2020 13:23:03 +0100
In-Reply-To: <877dvfiofy.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 07 Jul 2020 11:56:01 +0100")
Message-ID: <87y2nvh5ug.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 (-)

Jo=C3=A3o T=C3=A1vora <joaotavora@HIDDEN> writes:

> For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE:
> just don't use these Eldoc fixes to shoehorn something rushedly into
> Emacs.

Just a further note: not only am I NOT "against" futures, I don't even
disagree with you that a good async library CAN improve Eldoc and other
async code.  The question is, like it always is: how much of an effect
and at what cost.

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 07 Jul 2020 13:40:02 +0000
Resent-Message-ID: <handler.41531.B41531.159412914221065 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159412914221065
          (code B ref 41531); Tue, 07 Jul 2020 13:40:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 13:39:02 +0000
Received: from localhost ([127.0.0.1]:35771 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsnoL-0005TQ-O1
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 09:39:02 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48936)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jsnoG-0005T9-4k
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 09:39:00 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3E4C1100E87;
 Tue,  7 Jul 2020 09:38:50 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 628BC1005A8;
 Tue,  7 Jul 2020 09:38:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1594129127;
 bh=KIevi42Yxm8vrvACP2tc7Ba9zbra3LiOkiKGtvpxqPI=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=hbA/pIZH1U2TfF8IsN8TNdYsAoSZC2jjzpD6QmgcTk1kupoXq7B6Oc4luBCkjTSgi
 By9PsBXRPTHMAz6xkbogYZXgjqAUhZ+VBOfblb+DNkIpNSeGpty0zaLR1zSH1ecQDW
 i0RO8/HCO7jB+j6Ck5px5pw1Z0F+4bpnQr9ESsPSMIonlAkAdoK6ijoirt/qY+1EbT
 KUmJ1DKDzZRKfDeZ6kBryImM4vGoYmjxA0oTtLxsE+zFIEo4N1mwJnBfKkWZ2p/CLT
 EX0X/CMWC6PrrSbeuKuKduRDW0MOXIZ8RXkCr69g04S5keNHtTNBYMU5x6oyru7ccv
 5sjk0jB0+Xqyw==
Received: from alfajor (unknown [157.52.0.200])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D29B1120329;
 Tue,  7 Jul 2020 09:38:46 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN>
Date: Tue, 07 Jul 2020 09:38:45 -0400
In-Reply-To: <877dvfiofy.fsf@HIDDEN> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Tue, 07
 Jul 2020 11:56:01 +0100")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.034 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

[ Sorry I can't really take part in the discussion, 'cause it's
  a rather busy time here.  ]

[ The discussion is becoming too tense for my taste.  Please take
  a break and think whether all this is important enough to warrant
  criticizing each other this way.  I think you're both great hackers
  whose opinion and expertise I value very much.  ]

I think getting async support for eldoc is more important than *how* we
get it.

I suggest we install the current eldoc-async code into `master` and in
parallel work quickly on a futures/promises/aio/... package for
`master`.

As long as it's done before we cut the `emacs-28` branch, I can't see
any reason why we couldn't change the new (and hence not yet released,
except for the GNU ELPA package) API in a backward-incompatible way
(just like the eldoc-async already does).


        Stefan


Jo=E3o T=E1vora [2020-07-07 11:56:01] wrote:

> Dmitry Gutov <dgutov@HIDDEN> writes:
>
>> Please don't make it sound as if I'm the only one here having a strong
>> opinion about proposed code. You disregarded the simple solution in=20
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D41531#8, and then went
>
> Are you in any way trying to say that you presented a "simple solution"
> that somehow magically solves the problems of Eldoc?  If you do, you're
> living in conflict with reality.
>
> There is the problem to be solved.  And then there are techniques for
> solving the problem.  These are two entirely separate things.  To be
> absolutely clear: you have not, ever, proposed an alternate solution to
> the Eldoc async _problem_.
>
> You talked and talked and presented your favourite async handling
> techniques, like having functions return functions that return
> functions.  You contented that I -- not you -- should work with it to
> solve the problem.
>
> Callbacks, futures, promises, ad-hoc or proper, are just techniques.  I
> tried a couple techniques, including a basic futures-based one proposed
> by Stefan.  I didn't find any as compelling as the simplest and most
> widely used in Emacs: callbacks.
>
> For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE: I
> just don't use these Eldoc fixes to shoehorn something rushedly into
> Emacs.  Make a new thread, or join the existing one:
>
>     https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00935.html
>
> Afterwards, propose a change to the technique, not only in Eldoc but
> elsewhere, too.  This idea is so simple that it boggles the mind that
> you don't grasp it.
>
>> urgent endeavor. E.g., Flymake is stable, and I don't have any
>> particular bugs in mind that need solving.
>
> Great.  I'll just note here that it uses exactly the same technique I'm
> proposing in Eldoc to communicate with multiple backends: it's curious
> how that doesn't bother you.  I would reasonably expect "futures" or
> something else its implementation much simpler too.
>
>> Aside: given that this discussion has user interface in mind, it needs
>> more consideration of actual user experiences we'd want to allow. Ones=20
>> not provided by eldoc itself as well. For instance, I think we sooner
>> or later should have a callsig floating popup (in the vein of MS's
>> editors) as an alternative to showing the signature in the echo area
>> only.
>
> That is addressed in a comment in eldoc-docs
>
>       ;; Finally, output to the echo area.  We handle the
>       ;; `truncate-sym-name-if-fit' special case first, by selecting a
>       ;; top-section of the `*eldoc' buffer.  I'm pretty sure nicer
>       ;; strategies can be used here, probably by splitting this
>       ;; function into some `eldoc-display-functions' special hook.
>
> I agree there is ample space for improvement, including a=20
> "floating popup" (which I wouldn't limit to callsigs though).  Make
> another bug report to study this.
>
>> The new API is incompatible with the previous one, it requires
>> changing a lot of functions (though admittedly in a minor way).
>
> This is demonstrably false. As I've explained to Eli there is no
> incompatibility in practice.  0 (zero) third-party extensions make use
> of the protocol being changed from Eldoc 1.0.0 to Eldoc 1.1.0, unless
> you're stalling here to secretly work on one.
>
> But if we really, really wanted to, it's easy to get rid of the
> arguments, too, with a variation to the callback technique.  I just
> don't think it's worth it: a technique is a technique.
>
>> is easy to miss, as evidenced by describe-char-eldoc which still
>> doesn't accept any arguments.
>
> Oh, an actual useful comment! Easily solved, thanks.  And it was only
> "missed" because it wasn't used anywhere.
>
>> Whereas we could limit ourselves to the change which would only make
>> the clients use the different hook (or keep using the old one, for
>> compatibility with older Flymake/Emacs versions).
>
> Compatibility to the old `eldoc-documentation-function' protocol is
> fully guaranteed.
>
>> The choice to require a return of a non-nil value if the callback is
>> going to be used is also kinda odd (+1 control flow to test). What's
>> the problem with using the callback synchronously if the doc is
>> available right away?
>
> Nothing, you can do it.  As long as you return non-nil, non-string.  But
> if you are are going to synchronously call the callback on a string, you
> might as well return that string, just seems simpler.
>
>> The decision to double down on having different
>> eldoc-documentation-strategy values seems odd to me in several
>> respects.
>>
>> First of all, if I understand the main motivation behind it, it's to
>> delegate the implementation of asynchronous primitives to Eldoc.
>
> It's rather to make clients don't worry about the synchronization.  Not
> specifically to make Eldoc worry about it.  As soon as you and others
> come up with the uber-async library, I think Eldoc and Flymake and many
> others will be very pleased to delegate work to it.
>
>> We don't want to bother with that in Eglot, etc. But you mentioned "a
>> type of docstring" to be returned in the discussion (and the callbacks
>> have the plist argument as a future proofing). If the type is a
>> buffer, its contents might as well be created from several async calls
>
> If you want to support "buffers" as a "type of docstring", just do that:
> make buffers a type of docstring.  The obvious way is to have multiple
> sources produce multiple buffers.
>
> Thing: why would you ever want to put buffer-joining complexity in the
> client?  They're not in the business of doing async gymnastics, they're
> in the business of serving things coming from servers as efficiently and
> effectively as possible.
>
>> , which would require the same async primitives (though rather in
>> general purpose form) available on the client anyway. Though it
>> doesn't seem to be necessary for LSP in common operations, it's
>> unlikely to be the only such protocol we'd ever want to support.
>
> I don't know about that, but if we did, the current mechanism work
> nicely for the example you presented.
>
>> The strategies themselves:
>>
>> - eldoc-documentation-enthusiast: What's the difference compared to
>> the 'default' one? Sacrificing CPU load for lower latency? It's an odd
>> choice to force the user to make. The only people who can make an
>> ideal decision regarding this are probably the authors of
>> eldoc-documentation-functions, but it wouldn't help if
>> eldoc-documentation-functions has functions coming from different
>> authors, facilities, etc.
>
> Has nothing to do with CPU.  This is the way Eglot works now, or at
> least tries to: there are two delayed doc-producing backends, and
> neither is guaranteed to complete.  One has priority over the other (and
> special hooks are a decent, standard Emacs way to manage priority)
>
> Eglot shows the lower-priority one if it shows it can survive for more
> than x seconds (currently x =3D 0.3, uncustomizable).  No more doc
> blinking.
>
>> - eldoc-documentation-compose: Okay, this is kinda interesting (though
>>   not essential),
>
>> I think the only reasonably predictable behavior would be to truncate
>> each of them to one line, always.
>
> That's a display problem, not a composition problem For now it works OK
> for one liners and also multiple multi-liners.  Displaying doc is not
> the main goal of these patches, there is certainly room for improvement,
> as I said above.
>
>> - eldoc-documentation-compose-eagerly: Ooh, now I think I see why
>> Returning futures instead (when async is needed) would provide this
>> kind of guarantee without the seeming duplication of signals.
>
> Can't let go of that futures drum, can you?  It'd be a pleasure to see
> you walk the walk.
>
>> On a related note, I believe some facilities might want to use only
>> certain "kinds" of documentation functions (as indicated by the plist=20
>> arguments). If the plist is only provided together with the response,
>> there is no way to avoid unnecessary computations (e.g. making HTTP=20
>> requests that return some other kinds of values). If the plist was
>> returned together with a future value, however, it would be easy to
>> do, as long as we document that the futures should start the
>> computation until a callback is provided (if possible, at least).
>
> Save it for your future futures implementation.
>
>> And in a different high-level argument: you stated that you intend to
>> have Eglot use a non-default value of eldoc-documentation-strategy.=20
>
> OK, but this has nothing to do with Eldoc, does it?  Make a bug report
> for Eglot, I'll explain why it does this, and maybe I'll change it..
>
>> Next, eldoc-print-current-symbol-info is a mess, very hard to
>> follow. I am frankly offended that you argued that both ad-hoc futures
>
> I meant no effense.
>
>> idea). This should very well be possible to untangle in the future,
>> but I'd rather not have code like this in Emacs if we can help it.
>
> You're such an ace programmer that you code alternatives that are so
> brief that they occupy no code at all!
>
>> Further, having all strategies basically delegate to hardcoded options
>> inside eldoc-print-current-symbol-info seems to confirm that the set
>> of available strategies is a closed one. Which is not what I would
>> expect from a variable called eldoc-documentation-strategy.
>
> There are four strategies to choose from but you can make more.  What
> did you have in mind?=20=20
>
>> These are my objections, for now. I'll have to study
>> eldoc--handle-docs a bit later, but any problems it has are probably
>> orthogonal to the rest of the list.
>
> Thanks.
>
> Jo=E3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 14:19:02 +0000
Resent-Message-ID: <handler.41531.B41531.159413150125451 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159413150125451
          (code B ref 41531); Tue, 07 Jul 2020 14:19:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:18:21 +0000
Received: from localhost ([127.0.0.1]:36397 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsoQP-0006cR-H3
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:18:21 -0400
Received: from mail-wr1-f54.google.com ([209.85.221.54]:36170)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jsoQL-0006cA-Hd
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:18:20 -0400
Received: by mail-wr1-f54.google.com with SMTP id k6so45344764wrn.3
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:18: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=5sJyn4G7owkFSRMDf77IxnlseK33nLbnh8K7xaok+8k=;
 b=GQGy0ZGOud8pRdAgqzqtJHmJdoF14io6MUKllYAE2E4kx1YfVh734iaR7V4dPVPXn7
 b8RAHToAzmSq+EtdG5pY1dT3QF1f/NHQ7SohiWqSPQf7/tMFfUjJnTQb6dLhWMx169dT
 zckQV2li8GpHjGyQEtV1OCdIl2cd69Ljtu+v6Ildj3iGFL8r3s6WCU7gK5iZe46urIoT
 kJ/zyi+GvavxOHQieOaCAZ189aIpt4O/VdICfxy/NnjuztKoEzipq4+3MTOF9zJ45xl4
 J/cO8uL35bDyD0zeZuzauwBtreGAyy+yje+/Y/TeieEBcg1f81zAzh3EFECVu5t7AWJS
 A0kg==
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=5sJyn4G7owkFSRMDf77IxnlseK33nLbnh8K7xaok+8k=;
 b=QkWH+B588YsYxELgg7Vyt4/ybrOBsJzDRggfz8SeBjeJAcbDy1s7FzPM6pHqbXiZsB
 iqz/sf9nbsAnvRjLQxmXLVMP3eSGFntqx//DB3PJyc/zxzBgcJfL9hkjG6asrik6jkS3
 Gi/dGJ7Ryhb/UyoCyoJbbafIKxezOMNX8x4/LdE3u8rccevKqsjBaxqClerJ5JCsa6XG
 oI2cw2VXDKTTDb+JcoCejxWEfD9F0n8CxTfnGaj85Lk7E7B9wYaZS0vZ5DE8BCoL7usw
 YvJW6nKqc2bWYJTU4cr2VppVriogfwSe9fgjKs3OZGRjj3L+5/mHHCsdEZJmFM8EnNiV
 kDGQ==
X-Gm-Message-State: AOAM530XAAFxFZyp6ffbvpVC8Zw+aJY/g1R6JrsPfjAwL+B6fQ1PHdxL
 n46qLzRtLFQ+7W5tu5M4zq4=
X-Google-Smtp-Source: ABdhPJzUwSW19vIWtylLJlMcEX6XNzU2dQZYm2vLQlNgBVrkGsWu/HxLwrXJLZHd08FoXjJyyc2Zig==
X-Received: by 2002:a5d:60c5:: with SMTP id x5mr19751827wrt.67.1594131491737; 
 Tue, 07 Jul 2020 07:18:11 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id m10sm1295652wru.4.2020.07.07.07.18.09
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jul 2020 07:18:10 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN>
 <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN> <87d05aoowh.fsf@HIDDEN>
 <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN> <873663iob0.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <a952c5d5-6569-b1b9-1981-618d9efd1bbb@HIDDEN>
Date: Tue, 7 Jul 2020 17:18:09 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <873663iob0.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 07.07.2020 13:58, João Távora wrote:
> I've told you this before: you mistake attention for obedience.

Most of the time I feel you're not even addressing my points.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 14:25:02 +0000
Resent-Message-ID: <handler.41531.B41531.159413186826074 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159413186826074
          (code B ref 41531); Tue, 07 Jul 2020 14:25:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:24:28 +0000
Received: from localhost ([127.0.0.1]:36405 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsoWK-0006mU-F4
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:24:28 -0400
Received: from mail-wm1-f46.google.com ([209.85.128.46]:33507)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jsoWI-0006mH-5V
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:24:26 -0400
Received: by mail-wm1-f46.google.com with SMTP id a6so1871744wmm.0
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:24:26 -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=W+F9C82WWkJmCj99W9SOwacXHCQJ1i1XU4B23/L9LqU=;
 b=mWAxLS8MdRrPShNxw47oE9rzSvOtr/Luz1GmTBfcifIBoIn5bP55Td6nnzeeg5wph3
 4nlOrUtBbuBUWTct3OW1yV04n45toHO55C5xslHpQX7bQ62jDTK/p2LTCm9gZ2BDEPTm
 fChdbmDkjzrjdRSvCzNoTzsRaMXa2pziMimlot8X87jjfKCzDdf8HVthIJWCQI5K6DH5
 s52WCybTYiWBQqyltt5VlSRBAYJX8+dSXOq9HpJ9bpoVwwNr051zNr0oGvz+tVshpbxc
 pMogJk7/5h61wCzcByIX+TQiGcE44FCHTsdKKzv2oC67jHOM5nPh+kzdwjFZF1GnGe3c
 XP8w==
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=W+F9C82WWkJmCj99W9SOwacXHCQJ1i1XU4B23/L9LqU=;
 b=sG53S0+iEyy6YUkTcb/jE3iJJnJ9NHxDkFIGPgm1IL3N0wBNWKCZMMLSGmEFxdWrqn
 r9FdjUxETYSvyjS1eM8hOvU2yqphkXK1rF4Jse5a6foSzwyEjoOwdeN+tpf3xc1hx14e
 S3E/wxCzXKfJvSxY4tbu3cfa3LrWlUfuC6L3Zp67bu1D/M/HdkR1s34DOy+KADLkOQ+c
 XDJ4mFOEJRDmMQUDbzPiwgQNii6ButhsAmaTnHotCy5wcVjkOmLGxavJJmDVAW+Ucuqd
 6tlYBBM5sPscMMutyqSlxoly+ceZmz3eLxq+sntXAorOhaVatqnEC0aWnIU8HXJsGLda
 Caog==
X-Gm-Message-State: AOAM532fjGsGLw5bKCTK5K6QQlKVAJWCoBgw382r+o1l2t3alKN5I4wS
 UPfhYEtBrZQhFTgJb3t/bdA=
X-Google-Smtp-Source: ABdhPJwrUd0+5TfHRmM6cHQShwWoGdg3Y2oU1yLosEmXMJTIOuEqW7HnPvXYrQ12fvUoWFoFxdYX8w==
X-Received: by 2002:a1c:de07:: with SMTP id v7mr4518106wmg.56.1594131860441;
 Tue, 07 Jul 2020 07:24:20 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id 2sm1162683wmo.44.2020.07.07.07.24.18
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jul 2020 07:24:19 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
Date: Tue, 7 Jul 2020 17:24:18 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 07.07.2020 16:38, Stefan Monnier wrote:
> As long as it's done before we cut the `emacs-28` branch, I can't see
> any reason why we couldn't change the new (and hence not yet released,
> except for the GNU ELPA package) API in a backward-incompatible way
> (just like the eldoc-async already does).

It's a good point, and if that was all that we'd need to agree on, I'd 
be fine to proceed.

But if we just wanted to get async into Eglot, that's what my simple 
patch did: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41531#8, 
proposed months ago. With minimal backward compatibility issues.

The current discussion, and the current eldoc-async branch adds some 
more design decisions, as well as breaking changes.

And those decisions seem to be informed and made necessary by the lack 
of standard functions for combining async computations that eldoc 
clients could use.

As soon as we get futures/promises/aio into the core, that will cease to 
be the case. But I fear we wouldn't be able to roll back the related 
decisions so easily, however.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 14:35:01 +0000
Resent-Message-ID: <handler.41531.B41531.159413249427207 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, monnier@HIDDEN, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159413249427207
          (code B ref 41531); Tue, 07 Jul 2020 14:35:01 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:34:54 +0000
Received: from localhost ([127.0.0.1]:36415 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsogQ-00074l-LP
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:34:54 -0400
Received: from mail-wr1-f51.google.com ([209.85.221.51]:38501)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jsogP-00074W-2T
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:34:54 -0400
Received: by mail-wr1-f51.google.com with SMTP id z13so45395944wrw.5
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:34:53 -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=WZsl3efc9qUf18ZTdQjylNux0op5veEUMsuIODH7bLg=;
 b=BV7NGpnjg/jFaVwhWpevIaPj9ZpoNLf1BXz18KcXe9+S9FZZKC+rDlHA970FvWMDW6
 FJ3dh9qi9tgyOb8+f2sop7B/rruWQJ5JQCZ2ht6odr2DRDLXwYe8492t3jczJkfZ+I0+
 X6Nte+O7ScEjsOm5oOn8sbGCFQWw2cMYFNk5+5rAGaelalvAouXcRnra4pwTJyqdjjBO
 JOIpNQarJHoNwhjpydAQ8v8GsGbPjfdRfW+rImJRRvZVQWNG+R9kAgML4HL63uL6nQoF
 Hk5jMYQcjuTB9X9eCgEcdKHrJ0s9jQ9zuhx2hk0IYiX35kpWa/z3LnAkA4Dplos49Y3/
 hsLw==
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=WZsl3efc9qUf18ZTdQjylNux0op5veEUMsuIODH7bLg=;
 b=ArT5VRpps9qYef/Fd608SmBtZ3u9lZkbWwZBIGizobA7YPbGa4wXEmOqJAXVLr4Cd8
 hAhV1TgOj7eyxbyYdnqyihBB4sTG2OxAPTd2fjlMqDfri8iJLHHUprXL5L9ubULmPu09
 7qMGAhtNOAHqa5qqocymOh1amvjhbBZjSmNmR3kAG17StAU8LHOkRzI7LOSylnjfHfsM
 FpgBC21YRskpn+I/PSNjxVwkCyxdsGQioZ/G/0WICqXQBJ01n+TcvCbFtS6fC3xY6Ksm
 mPhvwNkFYr3H8m7J6pRE+VlrSpgulFRBmw5LHJr0gtnBwmkJmKa7x55RKcaEPUgUZwNU
 ki0Q==
X-Gm-Message-State: AOAM533kiWpu5YjH/5XhkNuSRB1PRpjvMynDhAp1ws2/SpG72kHUKa30
 Qxp2ePKvGJXWuipKdQP1Mvg=
X-Google-Smtp-Source: ABdhPJzrk4tH3w8kdjSff9awiLE4nqxm8b59h9rTvUAK/RamI9zU2FJM1jfpJ0yCcx2rxCywqMedgA==
X-Received: by 2002:a05:6000:1182:: with SMTP id
 g2mr50646748wrx.44.1594132487250; 
 Tue, 07 Jul 2020 07:34:47 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id c206sm1381273wmf.36.2020.07.07.07.34.46
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jul 2020 07:34:46 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <83k0zjvi4c.fsf@HIDDEN> <87zh8fsfx2.fsf@HIDDEN>
 <6af94c86-596a-1539-3565-5aee9dfa6708@HIDDEN>
 <87d05aoowh.fsf@HIDDEN>
 <13b92d6a-6a11-ffd1-88f6-582f8ea89410@HIDDEN>
 <873663iob0.fsf@HIDDEN>
 <a952c5d5-6569-b1b9-1981-618d9efd1bbb@HIDDEN>
Date: Tue, 07 Jul 2020 15:34:44 +0100
In-Reply-To: <a952c5d5-6569-b1b9-1981-618d9efd1bbb@HIDDEN> (Dmitry Gutov's
 message of "Tue, 7 Jul 2020 17:18:09 +0300")
Message-ID: <87r1tngzqz.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 07.07.2020 13:58, Jo=C3=A3o T=C3=A1vora wrote:
>> I've told you this before: you mistake attention for obedience.
>
> Most of the time I feel you're not even addressing my points.

I try my best, but I don't have any control over your feelings :-)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 14:41:01 +0000
Resent-Message-ID: <handler.41531.B41531.159413281027766 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159413281027766
          (code B ref 41531); Tue, 07 Jul 2020 14:41:01 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:40:10 +0000
Received: from localhost ([127.0.0.1]:36435 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsolW-0007Dl-5l
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:40:10 -0400
Received: from mail-wr1-f43.google.com ([209.85.221.43]:42741)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jsolV-0007DU-3x
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:40:09 -0400
Received: by mail-wr1-f43.google.com with SMTP id o11so45449348wrv.9
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:40:09 -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=tmdLsAhQ1lGSzm8Y9I+NKexP/sI22/aW+rBNrrDBgAI=;
 b=IEDv1QHOrKvIxXwaugIs/YrmZeKFbI2rrFVkHWKJuHm7BRl1JYuWYKNlGrK0oVHBMa
 hHQD8m03Q7JUfDm9BToxYJH6YViTq0pUqbmlA4B8Mvqte6ArysxFSGxckaBfIopo54Hx
 qulL7uuED3ILaq0mG4ScYHk+3PqxETUV37P7CrPAibYxSYqLd/Igh5okuU1ZZUuIMckQ
 HnvXM7SHTtIwoOElvhcSdHYpXk/C3tbPJ03ldN1A1AM4cBqnEv0kNx25rxQowVlilUeb
 c40elBg2krhGALAu81jNB8Uk1h9YL+wA0arrTC0wrz7PHpIZt5Zv3pPA2CvhCqlrmk/B
 W0Ng==
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=tmdLsAhQ1lGSzm8Y9I+NKexP/sI22/aW+rBNrrDBgAI=;
 b=kYqdZjsnsiGfRGFaNCmJaFMVfdciUkjoUeP74iBi4583NiTCNLCWnZRLK96BxL8tFu
 UjThJVzgDIauTRYIq18LHzYBhg6EOvIqLv1dBQN7Lmrq09k+iDRpoZtcs0pf0mlnhO7C
 TlvoS5+p9//M1vL8e3sN0H95en/Hh2UFcpklZ/LIIxEdGB0Mrx5SDjLf4jAlT/t4ay0O
 fVRXdJgLldJ2I/chultBLfVIZHnmf1vq/8dpOd8Q5BGL6P0XRgUdnK7KrfgnCs0IV9oR
 nWeP+rN+v3xrKOnU106/6M96oBLjy/HK6xaCD8i/jFvaA+yXdA7Wd+ZVw1GxSO2asvYW
 ccOA==
X-Gm-Message-State: AOAM533FyapIO3tsj/VSMqJ/4x1FQIlCxcttiJFgsK20kHZB2BP+SHlc
 1TRq9UVzo7MqhQld/4TGNBA=
X-Google-Smtp-Source: ABdhPJwyUgnILBhalOJyE4hv7dKYcwRym7Ntabw+yD/Azl04QnYd4pUyADl1/NPJyUHoPMmXsPp7bQ==
X-Received: by 2002:adf:ed47:: with SMTP id u7mr58421602wro.201.1594132803193; 
 Tue, 07 Jul 2020 07:40:03 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id 63sm1320613wra.86.2020.07.07.07.40.02
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jul 2020 07:40:02 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <84a17480-cf10-8176-3080-61e5947ac6ed@HIDDEN>
Date: Tue, 7 Jul 2020 17:40:01 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <877dvfiofy.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 07.07.2020 13:56, João Távora wrote:
> Are you in any way trying to say that you presented a "simple solution"
> that somehow magically solves the problems of Eldoc?  If you do, you're
> living in conflict with reality.
> 
> There is the problem to be solved.  And then there are techniques for
> solving the problem.  These are two entirely separate things.  To be
> absolutely clear: you have not, ever, proposed an alternate solution to
> the Eldoc async_problem_.

Perhaps there is a misunderstanding here.

What would it take for you to say that "the problem" is indeed "solved" 
to a sufficient degree that your work on Eglot can continue?

If you could mention both the strictly minimum conditions, as well as 
the "bonus round", that would be great.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 14:46:02 +0000
Resent-Message-ID: <handler.41531.B41531.159413313028393 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159413313028393
          (code B ref 41531); Tue, 07 Jul 2020 14:46:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 14:45:30 +0000
Received: from localhost ([127.0.0.1]:36469 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsoqg-0007Nt-0J
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:45:30 -0400
Received: from mail-wm1-f67.google.com ([209.85.128.67]:35078)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jsoqe-0007Nh-Jm
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 10:45:29 -0400
Received: by mail-wm1-f67.google.com with SMTP id l2so45318019wmf.0
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 07:45: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=Qz4ueyref7OpFfZzbWzhcJeY4LYvkcSUdyVzNWRvLMY=;
 b=AXzALvK71pu/aq69sq+imK2FUo7bAeRX/GYihMmFBJH9X/RCEKrm+XucwqWa93GpLW
 XopfuOkMWWyhSdND+aEg+0bDogM6CS4yJ/NNaFm3nGmlV7yJg51iwwDw/nNgyy/pamc6
 NZ7gVL/vQgfEGDOncQ+SaLuNl7gUI7TpxXD4K/wuco+CKksuk7N7ixwAT4HKZlyyLsOx
 A7Bgc+IZcduNcmVdLSEIkUli/jf+3EaUjwORAKU58auTeX8+MZHz67+YJBO+5nrL5ABM
 xzypzvgNonvfqAM3EyqgBZuWrcWhta/q/fhbmN7VSfozk1wDEz2GQNEZB8EDr/WDpkrC
 pwRw==
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=Qz4ueyref7OpFfZzbWzhcJeY4LYvkcSUdyVzNWRvLMY=;
 b=LEO29FxYs1ZxjCtFp7arFa3wj6xv3E8z13YF6qx48kctDO7Kl8mHq78ybn700jyuhn
 Mjz9BdxwnTPxZJWJuR72lXNZUXwMAi0VYEcCxzIemXt13KbVewZXxg7cXt90idWTJPQK
 RK1wEC6NWaQ15zejOskNGLC57k0qOjtv0PwUcuBshJ1L5P1TuxPygIMEjt/MY7CQOQk5
 7Oa4Vdrv5F0lT5qFnG0iTgsaRo49OUcocv2IaRbS0iakIEVmffsJujUEbSC15T2N2R7v
 3BEJ9Tbyw8LG1jiNIZ/ns+UBTaaWMW0NTvaDyTxZrp5VcU5M1QsM/pWz1QKtwucUuEt/
 jUpg==
X-Gm-Message-State: AOAM532wv5Ctd7kKPCPobZl5WIAi3WRIZ3G9bguit3VB5BV/ndbTJK4r
 yshTPz1rbSqWCtD2YKREO8Y=
X-Google-Smtp-Source: ABdhPJzp3f9q7cNdtvgEkudMRhRSUYXFOGQmaQKtIMs/I0u0MdDEJRJtRtHDSOSXt4CLO95pQGpaSQ==
X-Received: by 2002:a1c:9e06:: with SMTP id h6mr4335114wme.45.1594133122758;
 Tue, 07 Jul 2020 07:45:22 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id 92sm1404294wrr.96.2020.07.07.07.45.21
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jul 2020 07:45:21 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
Date: Tue, 07 Jul 2020 15:45:20 +0100
In-Reply-To: <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Tue, 07 Jul 2020 09:38:45 -0400")
Message-ID: <87k0zfgz9b.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 (-)

Stefan Monnier <monnier@HIDDEN> writes:

> I suggest we install the current eldoc-async code into `master` and in
> parallel work quickly on a futures/promises/aio/... package for
> `master`.

That's the point I've been making all along, indeed! Finally progress!

Thanks,
Jo=C3=A3o

PS: I for one will try to invest some effort in some more
modular/powerful eldoc-display-functions... let's hope that's less
contentious.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 07 Jul 2020 16:09:02 +0000
Resent-Message-ID: <handler.41531.B41531.15941380834406 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15941380834406
          (code B ref 41531); Tue, 07 Jul 2020 16:09:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 16:08:03 +0000
Received: from localhost ([127.0.0.1]:36597 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsq8Z-000190-5B
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 12:08:03 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:44108)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jsq8X-00018F-5G
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 12:08:01 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9A81580A1F;
 Tue,  7 Jul 2020 12:07:55 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id B59B880B74;
 Tue,  7 Jul 2020 12:07:53 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1594138073;
 bh=G6Eo9Gg54jCUcvRFCG+PrRWzkdGztaR5cBdbfTB+5/o=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=imI3SPXmLv5XnVH6bxw5GMDBccfSm6Y3SVIl4z/hqiaS/83Gu1tlIcGEpcVjLhelI
 7PW6SFrI7ieIwFHnW+ciyqi53vqCOXerIUhS0WBz7kdUItfvqjToW1HBscgwi3aQrX
 RhMp82I090Xg+WUiYJqUkXfPVW5jCQZwYL7x8MoqDjWzn5kN3GkU7A/YMyqCsZLPop
 9Q8ydIxcwF4rURwhzwGkL2R9rPXh75hMsWxRyuY0/EB3pxRQWU5sZut783/7PECFpk
 LmkyD0zPlsTx4SCHQUtdfkt/DTU06+kp+76m9a1MmUEvjmvJiXWGrfJNiWTrWEBage
 7Pq56RRZaJp4A==
Received: from alfajor (unknown [157.52.0.200])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7C8CD12030B;
 Tue,  7 Jul 2020 12:07:53 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
Date: Tue, 07 Jul 2020 12:07:52 -0400
In-Reply-To: <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN> (Dmitry Gutov's
 message of "Tue, 7 Jul 2020 17:24:18 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.022 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

> The current discussion, and the current eldoc-async branch adds some more
> design decisions, as well as breaking changes.

I don't see any breaking changes (other than to things which haven't
yet been released IMO).

> As soon as we get futures/promises/aio into the core, that will cease to be
> the case.

Then let's get moving on that.  No need to wait.

> But I fear we wouldn't be able to roll back the related decisions
> so easily, however.

I don't see any reason to fear that.  The more time we spend discussing
what the ideal should look like, the less time we have to actually
get there.

The current eldoc-async branch doesn't get us further from the ideal,
I believe, unless `emacs-28` gets cut before we get our act together.

But if we don't get our act together before `emacs-28` then the
alternative is to have Emacs-28 without support for async eldoc, which
I think is even worse.

I recommend we try and be pragmatic.  Especially since it will make us
all happier (instead of arguing against each other, we get to work on
improving the code).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 22:26:02 +0000
Resent-Message-ID: <handler.41531.B41531.15941607098634 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15941607098634
          (code B ref 41531); Tue, 07 Jul 2020 22:26:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 22:25:09 +0000
Received: from localhost ([127.0.0.1]:36904 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsw1U-0002FB-Vh
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 18:25:09 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:34881)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jsw1T-0002Ea-58
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 18:25:08 -0400
Received: by mail-wm1-f45.google.com with SMTP id l2so908542wmf.0
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 15:25:07 -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=xvuyXoxcxuYAP+xmqs8M8iOHyb7g27NxZrpR1MIm6Fo=;
 b=oeT3OhCaaEgPBYt/KqpKLXKYjB6+0buHCHPxM53MRZUZ9CnBsGJKo2HR9PAQKg6n8P
 CyHDptVcHrwxVPtPkjf4Wj13Nu+8T8ilbuTwc2gvkr5BgtcrjoAuWmJuq1tw030DkUHZ
 2wOgRGlTSt/ckRWEmXzlwH5gvSHZdM/PO+tr6ZyW35TMa3pcTMn+bnc/un0FvW7ortOX
 H/pGsPHONjCOlfC7iGbjwHGuDqy2tt1Lm5vXCMFPqgm5mhKTUOGiUC1svCovLns6D++P
 wyKu2PtCU8mFeJZt2xD64aEfCkQSVotunbwjySsF/gU2A4uHBm/E5PV+Jrte9x+iOclq
 xDrg==
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=xvuyXoxcxuYAP+xmqs8M8iOHyb7g27NxZrpR1MIm6Fo=;
 b=ngvmu9OXSr352RPiUzCDg4lwxpfMmveCr4DwBE8dR/o7bMisscmbzTzzQyYt8j5OT1
 /AO9E5AiC2FFF5G5OALikyg2HhJTwY9syxiLIebz/qoSBuu3Rt+uzxGj6NRui6mtBfEA
 ocbX2M7kUmi6vkAx9ggy7pdXie4rD0VOFsR1Z3vox3esndZjxWCFObJ8/09h8TwaSmmC
 OwtqtZ7nyx9HcacK3c6MyyVPrd8PyB/jesbQ5ZyF0ZYycghH0L7kY1LUvUNn7a0JPVo1
 Qcg80yzi1uBmOMC2B92JS57apKl1wX3Q7X3BOIC28Wctx5R6fbs/romBuYKzc355NRGl
 vQUQ==
X-Gm-Message-State: AOAM530dB9n7Hv83orlrpQ9O7RGTHDRrtN430gBKwHS0OoCIbXEWA0ur
 oJe5OQGbtc56WAD7ucKuyZg=
X-Google-Smtp-Source: ABdhPJyHOiT5OZCxp0FjzLTdoAO7MpG77NY7KaN8zr7lzQskyRRRhqOhpJl/UWeKPHAOYuY0md/ueQ==
X-Received: by 2002:a7b:c4d6:: with SMTP id g22mr6478941wmk.170.1594160700808; 
 Tue, 07 Jul 2020 15:25:00 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id j24sm3015489wrd.43.2020.07.07.15.24.30
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jul 2020 15:24:40 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN>
Date: Wed, 8 Jul 2020 01:24:27 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <877dvfiofy.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 07.07.2020 13:56, João Távora wrote:

> You talked and talked and presented your favourite async handling
> techniques, like having functions return functions that return
> functions.  You contented that I -- not you -- should work with it to
> solve the problem.

I showed a solution to the part of the problem that we managed to define 
at that time. You added some more features now.

If you like, I can rewrite your branch in terms of that proposal. Or in 
terms of eldoc-future (as suggested by Stefan). Your pick.

(But we still need to discuss the extra changes in this branch).

> For the quintillionth time: I AM NOT AGAINST FUTURES IN PRINCIPLE: I
> just don't use these Eldoc fixes to shoehorn something rushedly into
> Emacs.  Make a new thread, or join the existing one:
> 
>      https://lists.gnu.org/archive/html/emacs-devel/2020-03/msg00935.html

Thanks for the link. I seem to have missed it. Not exactly the 
discussion to join, but the projects mentioned there could be helpful.

> Afterwards, propose a change to the technique, not only in Eldoc but
> elsewhere, too.  This idea is so simple that it boggles the mind that
> you don't grasp it.

Sure. As long as this discussion waits.

>> urgent endeavor. E.g., Flymake is stable, and I don't have any
>> particular bugs in mind that need solving.
> 
> Great.  I'll just note here that it uses exactly the same technique I'm
> proposing in Eldoc to communicate with multiple backends: it's curious
> how that doesn't bother you.  I would reasonably expect "futures" or
> something else its implementation much simpler too.

It doesn't have existing clients that return results synchronously. It 
almost always works with external processes. It doesn't care if a 
checker never calls back. It doesn't compose results from multiple 
checkers. Basically: it's simple, and whatever legacy it did have, you 
cordoned that behind flymake-proc (which everybody promptly migrated off).

And as you can note, the interface you proposed here is not exactly the 
same: due to some of the requirements above, it's slightly different. A 
flymake backend is considered running whenever it didn't signal an 
error. The convention you proposed here involves returning a non-string, 
non-nil value.

I imagine having different interfaces between facilities is better than 
having similar-by-subtly-different ones.

>> Aside: given that this discussion has user interface in mind, it needs
>> more consideration of actual user experiences we'd want to allow. Ones
>> not provided by eldoc itself as well. For instance, I think we sooner
>> or later should have a callsig floating popup (in the vein of MS's
>> editors) as an alternative to showing the signature in the echo area
>> only.
> 
> That is addressed in a comment in eldoc-docs
> 
>        ;; Finally, output to the echo area.  We handle the
>        ;; `truncate-sym-name-if-fit' special case first, by selecting a
>        ;; top-section of the `*eldoc' buffer.  I'm pretty sure nicer
>        ;; strategies can be used here, probably by splitting this
>        ;; function into some `eldoc-display-functions' special hook.

I think the first question to ask here, is whether the eldoc clients are 
not ultimately the best place to decide how the doc should be formatted 
and displayed.

So the alternative to your current proposal (with composing strategies) 
would be for us to provide a set of utility functions to clients: ones 
to manipulate async computations, ones to truncate the doc to desired 
dimensions, ones to combine several docs in one, etc, while honoring the 
value of eldoc-echo-area-use-multiline-p.

The advantage to that approach is that we don't limit the display to 
particular format (e.g. the truncate-sym-name-if-fit requires the symbol 
to be at the beginning of the line, and for it to be specified as the 
:thing property as well). The downside: mainly being unable to compose 
eldoc results from multiple clients. But I wonder how well we can manage 
to handle that anyway.

> I agree there is ample space for improvement, including a
> "floating popup" (which I wouldn't limit to callsigs though).  Make
> another bug report to study this.

Callsigs are a whole other matter, actually. The best experience seems 
impossible to implement through eldoc. The LSP protocol shows an example 
of a good data structure required for it (a list of overloads, the 
number of the current guessed one, and a documentation string for the 
function). Eldoc can be used in the absence of other options, but a 
different hook which requires richer values seems more appropriate.

>> The new API is incompatible with the previous one, it requires
>> changing a lot of functions (though admittedly in a minor way).
> 
> This is demonstrably false. As I've explained to Eli there is no
> incompatibility in practice.  0 (zero) third-party extensions make use
> of the protocol being changed from Eldoc 1.0.0 to Eldoc 1.1.0, unless
> you're stalling here to secretly work on one.

So what happens if we merge this to master now? Either you expect no 
clients, and there is no need to hurry, or we expect some new eldoc 
clients to use this interface. But then the same clients will experience 
breakage as soon as we switch over to "proper" futures.

> But if we really, really wanted to, it's easy to get rid of the
> arguments, too, with a variation to the callback technique.  I just
> don't think it's worth it: a technique is a technique.

The variation that I showed in my little patch a month ago?

>> is easy to miss, as evidenced by describe-char-eldoc which still
>> doesn't accept any arguments.
> 
> Oh, an actual useful comment! Easily solved, thanks.  And it was only
> "missed" because it wasn't used anywhere.

Well, you corrected its docstring in this branch.

>> The choice to require a return of a non-nil value if the callback is
>> going to be used is also kinda odd (+1 control flow to test). What's
>> the problem with using the callback synchronously if the doc is
>> available right away?
> 
> Nothing, you can do it.  As long as you return non-nil, non-string.  But
> if you are are going to synchronously call the callback on a string, you
> might as well return that string, just seems simpler.

Seems like a missed opportunity to simplify (or not).

>> First of all, if I understand the main motivation behind it, it's to
>> delegate the implementation of asynchronous primitives to Eldoc.
> 
> It's rather to make clients don't worry about the synchronization.

Because it's fairly difficult, right? Especially in the absence of 
helpful standard libraries.

>> We don't want to bother with that in Eglot, etc. But you mentioned "a
>> type of docstring" to be returned in the discussion (and the callbacks
>> have the plist argument as a future proofing). If the type is a
>> buffer, its contents might as well be created from several async calls
> 
> If you want to support "buffers" as a "type of docstring", just do that:
> make buffers a type of docstring.  The obvious way is to have multiple
> sources produce multiple buffers.

That doesn't really jive with what I imagined. If I want to produce a 
"pretty" buffer in a client, I will print to it. Possibly making several 
HTTP calls in the process, if that's not hard to do.

I would also probably prefer not to worry about some other eldoc client 
leaving its documentation function in the list before mine. Or having 
them later in the list, leaving some unrelated stuff in the resulting 
buffer. As a client, I would probably know which calls are made, which 
data is returned, and how I want it to be rendered.

> Thing: why would you ever want to put buffer-joining complexity in the
> client?

Because it knows in which order to put them? Or how to render the seams 
best? Or it could mix the HTTP responses in other ways than simply 
joining them with "\n\n". Having generic code do that seems limiting.

Having individual clients do that should encourage more attention to detail.

>> The strategies themselves:
>>
>> - eldoc-documentation-enthusiast: What's the difference compared to
>> the 'default' one? Sacrificing CPU load for lower latency? It's an odd
>> choice to force the user to make. The only people who can make an
>> ideal decision regarding this are probably the authors of
>> eldoc-documentation-functions, but it wouldn't help if
>> eldoc-documentation-functions has functions coming from different
>> authors, facilities, etc.
> 
> Has nothing to do with CPU.  This is the way Eglot works now, or at
> least tries to: there are two delayed doc-producing backends, and
> neither is guaranteed to complete.

Why not? HTTP responses normally arrive reliably.

> One has priority over the other (and
> special hooks are a decent, standard Emacs way to manage priority)
> 
> Eglot shows the lower-priority one if it shows it can survive for more
> than x seconds (currently x = 0.3, uncustomizable).  No more doc
> blinking.

Why not just wait for the first one, if its documentation function 
returned non-nil?

I considered commenting on the 0.3 magic number, but dropped it in the 
first review.

>> - eldoc-documentation-compose: Okay, this is kinda interesting (though
>>    not essential),
> 
>> I think the only reasonably predictable behavior would be to truncate
>> each of them to one line, always.
> 
> That's a display problem, not a composition problem For now it works OK
> for one liners and also multiple multi-liners.  Displaying doc is not
> the main goal of these patches, there is certainly room for improvement,
> as I said above.

Whether we can reliably display these docs in a "composed" way, from any 
sources, or not, should probably factor into the design. Because if not, 
do we really need different strategies?

>> - eldoc-documentation-compose-eagerly: Ooh, now I think I see why
>> Returning futures instead (when async is needed) would provide this
>> kind of guarantee without the seeming duplication of signals.
> 
> Can't let go of that futures drum, can you?  It'd be a pleasure to see
> you walk the walk.

There's not much inherent difficulty in extracting the future-merge code 
from here or elsewhere. The actual problems I mentioned in the email 
with the (tiny) future.el come from elsewhere (e.g. from requirements 
for using them for completion), but they need to be decided on, in order 
to minimize breakage later.

>> On a related note, I believe some facilities might want to use only
>> certain "kinds" of documentation functions (as indicated by the plist
>> arguments). If the plist is only provided together with the response,
>> there is no way to avoid unnecessary computations (e.g. making HTTP
>> requests that return some other kinds of values). If the plist was
>> returned together with a future value, however, it would be easy to
>> do, as long as we document that the futures should start the
>> computation until a callback is provided (if possible, at least).
> 
> Save it for your future futures implementation.

My point was, again, adopting futures here would create a structural 
change. A more incompatible one than if we adopted a more compatible 
API. Or straight away used eldoc-local futures.

>> And in a different high-level argument: you stated that you intend to
>> have Eglot use a non-default value of eldoc-documentation-strategy.
> 
> OK, but this has nothing to do with Eldoc, does it?  Make a bug report
> for Eglot, I'll explain why it does this, and maybe I'll change it..

It does, if the actual requirements here mean that Eglot could just as 
fine perform combining its documentation results itself, in its 
documentation function. Then Eldoc could eventually do away with the 
eldoc-documentation-function/strategy variable altogether.

And the current change to the API would be minimal.

>> idea). This should very well be possible to untangle in the future,
>> but I'd rather not have code like this in Emacs if we can help it.
> 
> You're such an ace programmer that you code alternatives that are so
> brief that they occupy no code at all!

Nice punch.

I hope you haven't missed the implication that it's _hard_ for me to 
make heads or tails of your code there. But I could take a shot.

>> Further, having all strategies basically delegate to hardcoded options
>> inside eldoc-print-current-symbol-info seems to confirm that the set
>> of available strategies is a closed one. Which is not what I would
>> expect from a variable called eldoc-documentation-strategy.
> 
> There are four strategies to choose from but you can make more.  What
> did you have in mind?

Well... if I were thinking further in the direction of strategies, 
perhaps some would first request/wait the documentation from sources 
that return buffers, and then if none of those return any, then query 
the rest of functions. Or order the sources based on their kind before 
doing the calls, using user-supplied algo. Or perhaps skip buffers which 
are already displayed in some window.

My point here was, though, that a strategy sounds like something 
customizable and extensible. So their semantics, docstrings and 
implementations will need to be more accessible to an average Lisp 
developer.

>> These are my objections, for now. I'll have to study
>> eldoc--handle-docs a bit later, but any problems it has are probably
>> orthogonal to the rest of the list.
> 
> Thanks.

Having looked at it, the only problems there I can report on are 
practical, the same as I described when talking about 
eldoc-documentation-compose in the previous email: blinking after every 
user command, missing truncation when composing several docstrings, and 
undefined behavior with multiple multiline docstrings.

Is it at all possible to get rid of blinking? One-line eldoc doesn't blink.

Also, umm... it seems to truncate the contents of a long doc buffer to 
its bottom part. At least that's what I get when trying the related 
branch of Eglot.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 22:50:01 +0000
Resent-Message-ID: <handler.41531.B41531.159416217911054 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159416217911054
          (code B ref 41531); Tue, 07 Jul 2020 22:50:01 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 22:49:39 +0000
Received: from localhost ([127.0.0.1]:36953 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jswPC-0002sE-St
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 18:49:39 -0400
Received: from mail-wr1-f47.google.com ([209.85.221.47]:37236)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jswPB-0002s1-1m
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 18:49:37 -0400
Received: by mail-wr1-f47.google.com with SMTP id a6so46988540wrm.4
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 15:49:36 -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=MHGJG17utx7ENa/DrQszChvQOsKf0cvqnQcl8WxZYEo=;
 b=EVRMO2oqgQdpJXRM725KPOOlar5np01tzv5+2651ZcWaDO20UUX6w4XXWwBGCGvsUW
 8w7p5ExrNCfL0jKvRu8dDuNvrf8rKwSrjmt3cTCsdBrZDcU++IUxhXqb7CYJgNxHe00Y
 Tk/sZ7S2++8IMDYp3wF5rM2/GF9hxIVvT+7ApNReodgDFdY2PJ//5qJGmMggKUAurJWz
 +gyo6thoz/RHiR1Y1B9JwZtglpDChiSnvjFD76jzSKt0YbrrBwpzDWIBBmjTUPXOkJLE
 t7L55IM/hqBsVWb0qAo9KKUrbkq5QXd8Zn2xM84/oaFj0k3Ka3v0Z/Z3Pf37JP8fNvOx
 C5pg==
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=MHGJG17utx7ENa/DrQszChvQOsKf0cvqnQcl8WxZYEo=;
 b=ZbO/gCWb7FfLli5p0O/ehwnzuqhxKvD4xyFKY1jaQNXjDSJ6YsIj7SZ0u5BK0qIAPk
 H7jbzF12IyDemWDGAEQ7TuKnWe2E772J+qG+prrBWHIUbe+6JNechLZcntR9GRppNRfF
 V4YzCgMVzywliqdZ4iC2m+PZxo3WqwE0sPBkzC8KfOCH0ozYmfhQO8lcaCaOscjlhczn
 Dl4AbYcEvFI9TIvJsJ+uCjoTBKwqcuyz3yMi/dEPpiV9NDmgKtGo+PS5OoVo/ZpwHh88
 jZQrdbWr5Ba5RrqcJtMU/9scHQ+4hQbAayr0u3bkC68vNVVtsdlAsa78ykjRqGeNT8Wn
 HPEw==
X-Gm-Message-State: AOAM5324AUtOqJET1O/+BGaA0jnqodk1wDHDn8zRzce2JWCP1OUfYZ+z
 pHZVnYwty9zuJJON5fnffA0=
X-Google-Smtp-Source: ABdhPJw/jAUSTrdP2aizTbi+Qt2jWXi2TIqKb8MS9oItlq341tlD0K/GsGr26CFWuw+hsIMVaRaVFA==
X-Received: by 2002:adf:b198:: with SMTP id q24mr25442221wra.335.1594162171003; 
 Tue, 07 Jul 2020 15:49:31 -0700 (PDT)
Received: from krug ([89.180.149.197])
 by smtp.gmail.com with ESMTPSA id u186sm2937340wmu.10.2020.07.07.15.49.29
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jul 2020 15:49:29 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN>
 <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN>
Date: Tue, 07 Jul 2020 23:49:27 +0100
In-Reply-To: <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> (Dmitry Gutov's
 message of "Wed, 8 Jul 2020 01:24:27 +0300")
Message-ID: <875zazgcug.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:

>> But if we really, really wanted to, it's easy to get rid of the
>> arguments, too, with a variation to the callback technique.  I just
>> don't think it's worth it: a technique is a technique.
>
> The variation that I showed in my little patch a month ago?

No, to be clear that was not a variation to the callback technique.  One
way is simply to passing the callback as a special variable (and there
are more ways.)

The rest of your long email hints that you've misunderstood what this
change to Eldoc is accomplishing.  I'm afraid I've done all I can to
explain it, including docstrings, NEWS entries, commit messages and
going through your previous very long code review.  I understand you
expected a futures library would come with this change, but it does not,
not for now.  I've explained that is only a technique, but in this last
email you conflate every issue with it again.  My position is: if there
really is value in them, futures will soon be in Emacs.  Let's follow
Stefan advice, it's good advice.  I might even work a bit on futures
myself.

Best,
Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 23:01:01 +0000
Resent-Message-ID: <handler.41531.B41531.159416282012089 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159416282012089
          (code B ref 41531); Tue, 07 Jul 2020 23:01:01 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:00:20 +0000
Received: from localhost ([127.0.0.1]:36966 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jswZX-00038v-V0
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:00:20 -0400
Received: from mail-wm1-f54.google.com ([209.85.128.54]:35840)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jswZU-00038e-QC
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:00:19 -0400
Received: by mail-wm1-f54.google.com with SMTP id 17so994516wmo.1
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:00:16 -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=vuHTpTZv9hS0z3MygeBbh9a8L6dbkoGa1B6Q4z1u1Ps=;
 b=TnmXCi1IjT8e23d7O/q683AAahnwpfgOTn2ntlkHTEhsMK3uvCMcavtUT2uqamL7Bh
 3SsNRfBnQzTjti5ZBtBphxIaFEE/i5WCoDSbr/iDTqsI5/DBWQwCUTcBeIKqRuPwLvxd
 M2O5bG7wmGWlSUYOFUbK06qmdglUljqMGGkHCZlpXLngJ4y1J+AOQB8cW6Q6c3vp4evR
 c2VDeRZ9mmlDH+w2ydmcha6iD4sWEqhbDS9k0y4ulusEW4q8VfDDqI5v2YzvYaVcaXBU
 iB9HBOhf5+11Au4aY+zvdq2YQPPg2Co8vKOB+RhemHjOy8igPT1qg4KCCRA62owdEOYL
 suhQ==
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=vuHTpTZv9hS0z3MygeBbh9a8L6dbkoGa1B6Q4z1u1Ps=;
 b=Xiu+79LT9Fuly71CpWzHnLrY5V7ngAE/BvHPetvBld2iEOootDr4SeyBJL3mx8HW6Q
 ZRgPDPlkZ93N1gT99VFettcVPKbRp7RxZS5TAWHYODI2bzT+ZCjiEnKr9E7V6XFMkbqR
 gfB71FXahN9+/jhxZi3VadiaoRO/YatrbsoFkIbLAuKZzi9v3vv4THDZZdQaMcI9AZvZ
 XJJEhRNMGBBPJ1m+E6MY6nk2JPL7Knk8xlQWGtl4eXcFJtWDCd087qTChq6Bq5GNwk0i
 iQMYFAU9pH7rFbMiplSFgYUtPsJE90v6kTYnzb5ul1MeYCnt5D/O8Q/mer3f+v/G54m3
 Xe2g==
X-Gm-Message-State: AOAM531dIAkclArpIsIEx+TBDJM68Mr8P42LDQejySTKeCcvWU8RmL2D
 sQJBG2T1PpylKLgAWA9x46I=
X-Google-Smtp-Source: ABdhPJy8KUm6VBsS/vPaNpQPJIa55dvW2Yi2/VjgLL33Wij4gxLzNNmzhbroIgWfpEgHuJID6m78ZA==
X-Received: by 2002:a05:600c:410f:: with SMTP id
 j15mr6153275wmi.128.1594162810683; 
 Tue, 07 Jul 2020 16:00:10 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id v5sm2930639wmh.12.2020.07.07.16.00.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jul 2020 16:00:09 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN>
Date: Wed, 8 Jul 2020 02:00:08 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <875zazgcug.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 08.07.2020 01:49, João Távora wrote:
> The rest of your long email hints that you've misunderstood what this
> change to Eldoc is accomplishing.

So basically you even refuse to discuss the design choices in the 
branch, or the shortcomings of the implementation, its current bugs, etc?

And just merge the branch wholesale?

Thanks, Stefan!

 > I might even work a bit on futures myself.

Knock yourself out.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 23:12:02 +0000
Resent-Message-ID: <handler.41531.B41531.159416348013117 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159416348013117
          (code B ref 41531); Tue, 07 Jul 2020 23:12:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:11:20 +0000
Received: from localhost ([127.0.0.1]:36988 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jswkC-0003PV-Kb
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:11:20 -0400
Received: from mail-wm1-f52.google.com ([209.85.128.52]:53856)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jswkA-0003PG-VR
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:11:19 -0400
Received: by mail-wm1-f52.google.com with SMTP id j18so986923wmi.3
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:11:18 -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=nVZ2kI+DAIGADUfmh08z8jHQMsnedOR1vrSwW7Ki33E=;
 b=uObmKMh6d7oPC1xfFBLhT0ZR9Kvl62LwLEcFZWq0V9N9isJc85ZiGV5Ya0stQX6BX7
 51JUA/IWcGolmGAI8JCHjcgVHPc1r/snW7jQZjakS9Msb3CR1PhJmc7R53qLeyTLtvmA
 mm/lK1x1+ET/q5jpcB54C1QHYCIbAVabnUqARwi6xKzDmRM/jzvDbbQKk3E8oRzHeBU9
 lXLdtUc6IizJCf6UFD1NeC8OefTli7n4r9K8JFj1yP/EcQYY+oX17ZDLhkJSyEi0gTwx
 O5m8cWGg6qm8/G0Jp88BElitL33UcI30naw5BBvc71g7V/prIhrhA8P7wkVRrwSC/aEv
 1H2w==
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=nVZ2kI+DAIGADUfmh08z8jHQMsnedOR1vrSwW7Ki33E=;
 b=q/RCB7khME6muuB+qwKzTS5D1fKad2wh5phUpNAXYs5ZKpEuNHNZwHAhYmXlUDxiwy
 LgvgtJHS5josJZjWLv7g0XJTEw9etPervXMBm8T0ntWmHftymF/VpYIcTb2hRaYNK2Lg
 Khu+pcyj0ieXGbIf89P4ARocXrFI+4VmynqD5izfCOSmhqx28HD6mdwZk/XtqmkV5VDS
 ic73ju/gp56utHew3AbhtWFb8LYOMmSXDi2Hgqu8BRGSnrgGzHx1x9Rddl7kVpNu3/NY
 K8/4VSWmQFaJRHuBWixAt3dwb3O0+FFPWYa9tgCz/2Zh1oB+qlijDHx8FZonnVNDWoOE
 DpPg==
X-Gm-Message-State: AOAM533a4NGXKRj8SqwGhOTbyCoqZgxL+LxhwPCTW7TiuBVntt++o90M
 BM28rCWHSFBeIXhXJuQw9Fs=
X-Google-Smtp-Source: ABdhPJz5517bNzpPLWyMX86nNJT9ACUV+nXxlEAZXJN/zRGn+YKrYTjZdsOGjxqomYmu4ugUvxgAQw==
X-Received: by 2002:a7b:c013:: with SMTP id c19mr6223505wmb.158.1594163473089; 
 Tue, 07 Jul 2020 16:11:13 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id c136sm3185519wmd.10.2020.07.07.16.11.11
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jul 2020 16:11:12 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
 <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
Date: Wed, 8 Jul 2020 02:11:11 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 07.07.2020 19:07, Stefan Monnier wrote:

 >> But I fear we wouldn't be able to roll back the related decisions
 >> so easily, however.

> I don't see any reason to fear that.  The more time we spend discussing
> what the ideal should look like, the less time we have to actually
> get there.

Given we can't even agree on the acceptance criteria, how would the 
rollback process look? Another "let's get it merged, folks"?

With nobody particular in charge of Eldoc except maybe for Joao now? Who 
will of course be ecstatic to change the API to one he explicitly 
disliked in the beginning.

> The current eldoc-async branch doesn't get us further from the ideal,
> I believe, unless `emacs-28` gets cut before we get our act together.
> 
> But if we don't get our act together before `emacs-28` then the
> alternative is to have Emacs-28 without support for async eldoc, which
> I think is even worse.

Why you don't consider the alternative with less invasive changes, is 
beyond my understanding.

> I recommend we try and be pragmatic.  Especially since it will make us
> all happier (instead of arguing against each other, we get to work on
> improving the code).

I wouldn't call the definition of eldoc-print-current-symbol-info in 
this branch an improvement over anything.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 23:26:01 +0000
Resent-Message-ID: <handler.41531.B41531.159416431214539 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159416431214539
          (code B ref 41531); Tue, 07 Jul 2020 23:26:01 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:25:12 +0000
Received: from localhost ([127.0.0.1]:37000 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jswxc-0003mR-1L
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:25:12 -0400
Received: from mail-wm1-f43.google.com ([209.85.128.43]:38179)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jswxX-0003m0-71
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:25:11 -0400
Received: by mail-wm1-f43.google.com with SMTP id f18so1043062wml.3
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:25:07 -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=hHLxnx8nyngEprDMbgUhDpwfukaPRT64QSt2P1M2iK8=;
 b=ttKPcjfqbU2GIdSSTXMLN86UsT6o4yhynfYN4XgJNTlKCKKATPMmE/mxSnAjET1knR
 eXqHzGDYIRCbY9b/3b6D8c/unx99widyRjiTyOqGrk4lsw59T+2i27L9hax8Q+rmOzpQ
 tmMbSKb/LkVBH6Ne5QHo73QzVFIaBWGW5rs+AjvApTqMXcV17J+Qbtm47wd/zPtvqsE3
 FBdIT3H7b9jbcaYvMCSDgk8dCrF3+OoyXa68JGbXi9OU7Kd5WsqOxmqyNfB6ut+e17rs
 D3uUBMaFxqoP5ratg8SmJ6GRhJlCmXs4wPRZ4ROGbOR8Ko2UKSCyCTj2IvJ9BA7qAjmM
 +6PQ==
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=hHLxnx8nyngEprDMbgUhDpwfukaPRT64QSt2P1M2iK8=;
 b=I8wkVI+SlX+a66vnGKTlNhrCWb5amErhuolZR9Spnlb/t6GiAGuKGaTEOxU4ggDJ7V
 p/+iJnyuWvvxUYdT/BieDJdhVJYw4ywRorguqSBjFAN6L6DcOIUv73W7hxwlV7GYhxnd
 6azVP3AvOqIwYnuLjrY1NhslPZYAgKT1Wc5E1g+nnGFfY7DdHWPiZ33j5lekc74jXVO0
 EzpGt0Y6qBQ1y9EZoUZGhwfr7TKZZOAnzd84+oleRqci7W5RAw3d2tx9D99ugItw3Qir
 iTWR6KMHr7JSJLwbsfizNnrAAf8gxE1tlfbdc10bTFe9dw11eUAcMRjpksnNpg4ueveD
 L9Pg==
X-Gm-Message-State: AOAM531bOTUpDv5Iv+QnjrLPWePHUhxJSiyckGKP/SgvWc6mGq55VA3A
 8FVxRix6YhBpcb5vEH0FcJQ=
X-Google-Smtp-Source: ABdhPJw3hlG+0sGLSq0N8dNiLmartdme4M4xwSQo7zG9tbgZAV9f5jhKh/0qWBrDYyeeLYPpPYUNQQ==
X-Received: by 2002:a7b:cd09:: with SMTP id f9mr6674049wmj.160.1594164301309; 
 Tue, 07 Jul 2020 16:25:01 -0700 (PDT)
Received: from krug ([89.180.149.197])
 by smtp.gmail.com with ESMTPSA id z63sm3168830wmb.2.2020.07.07.16.24.59
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Tue, 07 Jul 2020 16:25:00 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN>
 <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN>
 <875zazgcug.fsf@HIDDEN>
 <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN>
Date: Wed, 08 Jul 2020 00:24:59 +0100
In-Reply-To: <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> (Dmitry Gutov's
 message of "Wed, 8 Jul 2020 02:00:08 +0300")
Message-ID: <87y2nugb78.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 08.07.2020 01:49, Jo=C3=A3o T=C3=A1vora wrote:
>> The rest of your long email hints that you've misunderstood what this
>> change to Eldoc is accomplishing.
>
> So basically you even refuse to discuss the design choices in the
> branch, or the shortcomings of the implementation, its current bugs,
> etc?

I read your email, but it's very hard to follow your verbal conjectures
that this here or that there will fail catastrophically.

I suggest you make a bug report for each bug, describe a recipe for
reproducing the bug.  Likewise, if there are shortcomings in the design,
state clearly what you wanted do, but can't.  I promise to attend to
them, time permitting.

It's important to disconnect these reports from your fondness for
futures, which is a technique for which we don't have a library or
consensus for.  That in particular makes your otherwise extremely
valuable feedback very hard to follow.  Let's take Stefan's advice on
the futures front, is my recommendation.

Also, I agree with Stefan that things have become tense and agressive,
and no good progress can be made in these conditions.

Best,
Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 23:43:02 +0000
Resent-Message-ID: <handler.41531.B41531.159416535516202 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159416535516202
          (code B ref 41531); Tue, 07 Jul 2020 23:43:02 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:42:35 +0000
Received: from localhost ([127.0.0.1]:37010 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsxEQ-0004DG-Rs
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:42:35 -0400
Received: from mail-wm1-f51.google.com ([209.85.128.51]:33173)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jsxEN-0004Cw-H8
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:42:33 -0400
Received: by mail-wm1-f51.google.com with SMTP id a6so2731517wmm.0
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:42:31 -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=4D+jEGzN95BDJjc2YjQZP9qQmzC/H2EE9zxgquyjqok=;
 b=T6MRB4nLIYFQyTJKmmF7/QwR/lWn1wykRi7T9rn/q7ZWSPbvikOxlZhrkpt4SEHmHz
 BJbKFCsX4XJ2EgBGg6A0arnuap4k7+J6+LBqff4WJ0gHwJphoKoWEMakF3cQpy7h8ukG
 jMFkG6N0HA/+v9nn59mtCf8zP/QQ3z/wW13y/zlWr+/cZJ7wfq9AyQ55+ACLIDuha9Wg
 faZuL0FwJJo8DoAuwWW/h6YszRJlxl4EmcT3wzZnNhU0WWG3kjIxAXzPUrASOVgpY0HR
 zlmo33mkvQ/zqZdpxhSmPbRzIfTulnoaiPDcYoQyj930Za7Lfuy2SIroX6cmpzn5eDsS
 E7nQ==
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=4D+jEGzN95BDJjc2YjQZP9qQmzC/H2EE9zxgquyjqok=;
 b=J5UE2zNgIv+cgIsGRHXOIf5FAgymrt0muijUl4LKQvE0s7I9/diUj6uEVbkkQVdfc+
 ecx7DfeS7DLsQvVXQ+zt/pDr3/zP7xJlbFeIiThs0q+To6Jn3cShdNR4CWNe3sXvzFRz
 39HbMIrNNT/QLRnfV6K1Qnns1fcrQMHDRxWNZheCsHl7Sc1of+r1J5ZMJ1t72u7cPm8T
 szjO4TvCdovyRTZh1kT/PjlG3MKTEd4Xp1FY7LN3oJdBWUOb4myADjRlJDy0up8ebn2P
 hxJH8SAHsy0/1gV1ZivLTCTjojf2neaHG0fmnFWIoQu+Z+8xmU1TcWO1bAu/l8gtl+jS
 oTFA==
X-Gm-Message-State: AOAM531UAtMsPoUQByHoi2xaJsLkFltw7ivQCpS6LDRN1VBmoPSxBUBA
 kqA+cNNsSopckqlR4JtFxFg=
X-Google-Smtp-Source: ABdhPJxUxl1E83CpAhQN90UE0g1tu4RT5EzT3IEGU4HEhcVcUCTcoPwNAXWt3YkGASooC3VXDkNxjA==
X-Received: by 2002:a1c:bc8a:: with SMTP id m132mr6139843wmf.1.1594165345348; 
 Tue, 07 Jul 2020 16:42:25 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id w14sm2951234wrt.55.2020.07.07.16.42.23
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jul 2020 16:42:24 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN>
 <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> <87y2nugb78.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <36b1bf81-18b6-d079-ced6-9fc1a43d25c3@HIDDEN>
Date: Wed, 8 Jul 2020 02:42:23 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87y2nugb78.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 08.07.2020 02:24, João Távora wrote:

> I read your email, but it's very hard to follow your verbal conjectures
> that this here or that there will fail catastrophically.

No such conjectures there.

> I suggest you make a bug report for each bug, describe a recipe for
> reproducing the bug.  Likewise, if there are shortcomings in the design,
> state clearly what you wanted do, but can't.  I promise to attend to
> them, time permitting.

How about you reply to the email I already wrote and ask questions where 
something is hard to understand?

> It's important to disconnect these reports from your fondness for
> futures, which is a technique for which we don't have a library or
> consensus for.

You're ducking away from your previous statements. One message, you 
accuse me of not implementing everything myself. In the next one, after 
I offer to do just that, you cut the discussion short and accuse me of 
fearmongering or something.

> Also, I agree with Stefan that things have become tense and agressive,
> and no good progress can be made in these conditions.

Let's tone it down, then.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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, 07 Jul 2020 23:48:01 +0000
Resent-Message-ID: <handler.41531.B41531.159416563316659 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159416563316659
          (code B ref 41531); Tue, 07 Jul 2020 23:48:01 +0000
Received: (at 41531) by debbugs.gnu.org; 7 Jul 2020 23:47:13 +0000
Received: from localhost ([127.0.0.1]:37014 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsxIv-0004Kd-Dh
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:47:13 -0400
Received: from mail-il1-f194.google.com ([209.85.166.194]:44667)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jsxIp-0004KK-Gm
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 19:47:12 -0400
Received: by mail-il1-f194.google.com with SMTP id h16so14224114ilj.11
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 16:47:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=OWttQUTY9e7uQ0Xwk4FaUmcwDGUdkSZZxM0rfr09uYA=;
 b=olaKvag9QZxp9mU4plC9pvUV2+Yya4E42KxdEUJal+X1PqZfDy6JN3n8ESyqMEoRXP
 VEPYh+IRsT6r51xr08TFtnECGjzxJTm6mXkaYSnpAM5zMtGIKqSM12SsCMEoFC5gN1TX
 G27KRVfzdg5lkVIjmT/iNzRMmvuY4n2wE9rKgib7sybzqsYPYuTndMCFTawnwc4Cs++p
 I3lSFwE2EJmxy3TKcidgizYkZ8fdTe20a46PXjeRKzOzrmb7ER+2LUbKvmsmeXFLqsEU
 I86yqEvshPFdOJki1FkwMIsTena5i30xoYYcntKp3vO5hqbK9RiuuK4JxFlAPVaTp6t2
 cLIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=OWttQUTY9e7uQ0Xwk4FaUmcwDGUdkSZZxM0rfr09uYA=;
 b=dpCdSIaB1k+NbQX+WVwxfqq4exrLX5oYJVJNGZ/pakuootLBWy5KmL1XAU82ONoOmH
 9S/uQQmpYSEg59r4g8TiPEAfq2B4RgmeD1bbPw9lOGPgeTDAyaqOWtLio/vLcdjSx5Hq
 MmjoA2qPznDGyWHztcOi3cM6wF+asjwzbu/6dtBNAoUnGycxk7FZpbr0dkuZei+p1doE
 1HVh6TnzgXj16/8VdNJkNHAEzqzOG0nFbkgY5BMDk1b3swTI9HUo1rQOQH7eGCguhUMG
 Mdj0GWLhJMj++zd0zBzjMXXMgxEBRKLPmEMkrMsOviZwwQ+GwOyU0L6MzYekX58JJILA
 x13A==
X-Gm-Message-State: AOAM53002jk1Io8TVoOJnTOJKF3y//p8vTAnKAoGPKRE9wK5SzYn2DMB
 7a0bat4EMbCjwv2o0ZtTKv5edWeC7yio4uNK6jc=
X-Google-Smtp-Source: ABdhPJzpnAEIH7mqvzmPMsNGl3/Mp6SGND8VQQFV1N8nAX744GcyTzk46qqUI/Gik+uh5rf8lRvN2sekPlcD2rcXQ6M=
X-Received: by 2002:a05:6e02:13e2:: with SMTP id
 w2mr39678235ilj.9.1594165621868; 
 Tue, 07 Jul 2020 16:47:01 -0700 (PDT)
MIME-Version: 1.0
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN>
 <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> <87y2nugb78.fsf@HIDDEN>
 <36b1bf81-18b6-d079-ced6-9fc1a43d25c3@HIDDEN>
In-Reply-To: <36b1bf81-18b6-d079-ced6-9fc1a43d25c3@HIDDEN>
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
Date: Wed, 8 Jul 2020 00:46:49 +0100
Message-ID: <CALDnm508OCN7S9iLaw9k-91gtsW9nN4yo+vJWYzEf4ACoAJSiQ@HIDDEN>
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 (-)

On Wed, Jul 8, 2020 at 12:42 AM Dmitry Gutov <dgutov@HIDDEN> wrote:
> One message, you
> accuse me of not implementing everything myself. In the next one, after
> I offer to do just that, you cut the discussion short

You're confused, but by all means code away, you don't need my
permission for that. Good luck!

Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 08 Jul 2020 00:11:01 +0000
Resent-Message-ID: <handler.41531.B41531.159416701718818 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, Andrii Kolomoiets <andreyk.mad@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159416701718818
          (code B ref 41531); Wed, 08 Jul 2020 00:11:01 +0000
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 00:10:17 +0000
Received: from localhost ([127.0.0.1]:37040 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jsxfF-0004tS-8j
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 20:10:17 -0400
Received: from mail-wm1-f45.google.com ([209.85.128.45]:56004)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jsxfD-0004tE-Qa
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 20:10:16 -0400
Received: by mail-wm1-f45.google.com with SMTP id g75so1101690wme.5
 for <41531 <at> debbugs.gnu.org>; Tue, 07 Jul 2020 17:10:15 -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=+pr4S5vrAizyiKvX9CMB1ttGnrOWeW6Fx4dEPqxTz98=;
 b=Pe2D01jkI7z52EzUV36zA2OmimUijzp+0xwSYSFBpwi+jHCXcB2A/7k+1ctOSdJ4ep
 jrgYTXvX+84GXAjSryRYG8Y4dIm1terqfyiOd4r6u4RlkrulTCWCItekw24i/luv2Htr
 snMVzYW1zETQnPKnPdD3dL9xfkDTyZfNx6v8f8ZazxwupDgLI9Q3FCo3daA7vGdWxQbz
 oh218LbuD7Vw7gPqK0wtwUcD5Y4oMD4pB+5rs56MJ7jPUj2pwxcHgqmx4kSA3+hWwqh5
 /bdI4952ZXMWj/rKAAPD62LJK88XnxL2o+JryTPC2p6l2Kv1KsSoygyai3Q0S5LiYG04
 4kvA==
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=+pr4S5vrAizyiKvX9CMB1ttGnrOWeW6Fx4dEPqxTz98=;
 b=X7OtByIKG8rN2K3Emtc6Amu1t/d4v+tz6TYs4RkjMYmk/Rh03Imq75LrIReqvK+1TX
 HZsT1eZfBey30II/i7Xdgq9EMNNZhKngt00n3nOG1qGU6cJ4xdc7WkC/grdbFQ4NBEnT
 T8WD6llSEkrQ2veW/6vlMEVYinpZq/b10AnftjR8LTfd0nAH3/Kfj9DNY+f+azEqGO58
 M3upSJ2n91xefqB2C/9vJFVtGfluGkvSpRWOCwrEX9GyuOv8GW48SnBqnsk+7KVV5nlZ
 shZk9B5wKXAwm11XMtzGb0JO8NcCwycMJ62sXbJ6TSPUV61sXGLDltW4x2LBk/5ZThCi
 FmPg==
X-Gm-Message-State: AOAM530+bRds1oQM3/FgLnLNKLrYXYXmNJ/U2sdTwQSIP4lAowszsl0x
 pwDu/X3zJU8BczC8AhxENNQ=
X-Google-Smtp-Source: ABdhPJxF1Vnvsacdvg1cdn4KPjCVUttYqr0fU+ZbWSuUthmc+p68yeqrr680kLlUkNdppXC5oPRPJQ==
X-Received: by 2002:a1c:bb43:: with SMTP id l64mr6716385wmf.151.1594167010054; 
 Tue, 07 Jul 2020 17:10:10 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id x7sm3035950wrr.72.2020.07.07.17.10.08
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Tue, 07 Jul 2020 17:10:09 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <064d8696-a62f-bae2-de26-9bea8c325cd0@HIDDEN> <875zazgcug.fsf@HIDDEN>
 <462a9e0b-0393-d4d3-0793-f43176519f9c@HIDDEN> <87y2nugb78.fsf@HIDDEN>
 <36b1bf81-18b6-d079-ced6-9fc1a43d25c3@HIDDEN>
 <CALDnm508OCN7S9iLaw9k-91gtsW9nN4yo+vJWYzEf4ACoAJSiQ@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <550c7a18-e60b-e490-f39d-97d5a2b386a6@HIDDEN>
Date: Wed, 8 Jul 2020 03:10:07 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <CALDnm508OCN7S9iLaw9k-91gtsW9nN4yo+vJWYzEf4ACoAJSiQ@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 08.07.2020 02:46, João Távora wrote:
> You're confused, but by all means code away, you don't need my
> permission for that. Good luck!

So I spend a few hours coding, and you wave the result away just as 
promptly as you did with the code review? Or with my previous patch?

I asked what you actually need here in terms of functionality to go on 
with your work on Eglot. No response came to that either.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 08 Jul 2020 03:59:02 +0000
Resent-Message-ID: <handler.41531.B41531.15941807027462 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15941807027462
          (code B ref 41531); Wed, 08 Jul 2020 03:59:02 +0000
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 03:58:22 +0000
Received: from localhost ([127.0.0.1]:37197 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jt1Dx-0001wI-MY
	for submit <at> debbugs.gnu.org; Tue, 07 Jul 2020 23:58:21 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58279)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jt1Dv-0001w2-66
 for 41531 <at> debbugs.gnu.org; Tue, 07 Jul 2020 23:58:20 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 88C4780A1F;
 Tue,  7 Jul 2020 23:58:13 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C25E780B63;
 Tue,  7 Jul 2020 23:58:11 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1594180691;
 bh=Yx48gz2JAMFILb/JwiWMSIz+X7NTx+l+AMGxsgJwwKA=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=RcE5xMAlQgribr9eP1vz4DrbIinCHci7f8zpZLngTsgnvISzvr50Lead/1f5lqHPK
 02d9pWic+LqJ/DnJ1bPQiEDeB17ctxFo7PLjqdpVX3sQZb5S4YvaWlpuUs5VS1fhzn
 GLELU0Np8euZTbL7QcFzFmWuCpDYVzAAceeyZnEsly+ZKxBS19te8DNmeqPHsgZjBb
 /u0WIH0E6kfZK+wxBmuZJyYdwxBrCxeMPEDkgz+di2tR3ASIDa1jrk1JjhNliez9yW
 o004KuwD3r7+M1EvpEH49ngieB92FldEegENcjH2kdOLUJjHw9bo7zvvjKO+BlTj+L
 AuURnFWsbALUQ==
Received: from ceviche (unknown [157.52.0.200])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7674C1207A5;
 Tue,  7 Jul 2020 23:58:11 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
 <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
 <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
Date: Tue, 07 Jul 2020 23:58:03 -0400
In-Reply-To: <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN> (Dmitry Gutov's
 message of "Wed, 8 Jul 2020 02:11:11 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.022 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

> Why you don't consider the alternative with less invasive changes, is beyond
> my understanding.

[ It's the same old maintainer's conundrum, trying to balance the need
  to stay in control of the code and make sure it's coherent etc.. while
  at the same time delegating and encouraging participation.  ]

To a large extent, I tend to give a lot of weight to existing code.

I don't have the time or energy to work on eldoc myself, and apparently
neither do you, so the one who writes the code gets to take most of
the decisions.

From what I remember the last time I looked at the branch, there were
things I didn't much like, but not more so than in the rest of Emacs ;-)

I can't ask everyone to code what I would write (and it's often for the
better since what I'd write would likely not work because I'm not aware
of the underlying difficulties that would make it fail).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 08 Jul 2020 11:21:01 +0000
Resent-Message-ID: <handler.41531.B41531.159420725818347 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159420725818347
          (code B ref 41531); Wed, 08 Jul 2020 11:21:01 +0000
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 11:20:58 +0000
Received: from localhost ([127.0.0.1]:37564 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jt88H-0004lq-ND
	for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 07:20:57 -0400
Received: from mail-wm1-f52.google.com ([209.85.128.52]:39366)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jt88F-0004lb-Qw
 for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 07:20:57 -0400
Received: by mail-wm1-f52.google.com with SMTP id w3so2544807wmi.4
 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 04:20:55 -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=MdiIqwiFU+5+Y+Gx5O1l9usofkeMTwuX2UfN0Ry8IYU=;
 b=kt8XnajXRWQVngeNwLHgo1bLsKRL+PHHEB0ESuKZsTSVaxp3QPvTGbGyqVF5y6FVVT
 7L3eTP2I5PSTYg3BrCvj4JUjYrWPF9z56DS9gaMe4wOHFP8EqcJiJPy7ODdVVs6AUmvP
 IrfLklodRPsvWIimmUj6mfwkeeu6MVEYbweDx73rKQ9u7rLUP0k2yGOcesdbH8o5cvSQ
 oSkrXUH2mqBD7gOWH+OM1Yn3vL0Vpwsm103QHSg38eoEwedSFFF7aDtbLfaE0di1t8C1
 tl1fWHdPTT0j8tiH7f31f4IRO+IL70Fy4tW4wxw9WHTzPexkwVsd3y7JTZm2sYZ3qlkb
 C4fg==
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=MdiIqwiFU+5+Y+Gx5O1l9usofkeMTwuX2UfN0Ry8IYU=;
 b=d5UCfQmbIZ75Z4eCuAH6m2jWy7XX2pdZvm7silB8CaiKjENZpEDICFeskPfcNAU6P2
 aR/BVyXDkOISH6XFuAgfVopkYd0gr4DnOZEQ2Ed7/NFu3c+TOyjoWgOXfDeAHDDyHJrA
 w/ozZ25t4KUHlm1Fk8UWzHBuuzrNkox26pqrsBVmu4nZdkTI2GjZOT532C2Kq6AXL7lx
 6KYr/R3+MUwyBofofe7VR1VJyUxem0SFYAaRUtPsLSDMaGKOWg1iQnERtlbO13GVgG0N
 2tGQ5G62iH52/lwEV1Ty+RSL1oHzMf0WOPxuS3jyUweABWYIltf0595ztY4kwfg6vPFS
 92Zg==
X-Gm-Message-State: AOAM5312qBivy7MTeotxef26GyoN9u+8mSD3QY+EbRdy3NnjmL01Va1y
 hP9AIMWUOyR48Ofa3tpNff0=
X-Google-Smtp-Source: ABdhPJydYu0RkB2KDPCuRvwBbhAzxZW5oo9E9ktrl91tXJ5zhLqrKqhTlFQZKEd6h0XC6/ZhoQcyRQ==
X-Received: by 2002:a1c:2402:: with SMTP id k2mr8838040wmk.138.1594207249859; 
 Wed, 08 Jul 2020 04:20:49 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id u2sm5246753wml.16.2020.07.08.04.20.48
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jul 2020 04:20:48 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
 <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
 <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
 <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN>
Date: Wed, 8 Jul 2020 14:20:47 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 08.07.2020 06:58, Stefan Monnier wrote:
> I don't have the time or energy to work on eldoc myself, and apparently
> neither do you, so the one who writes the code gets to take most of
> the decisions.

I have offered to do a rewrite multiple times now.

The only encouragement in that direction I have received was "can't stop 
you".

>  From what I remember the last time I looked at the branch, there were
> things I didn't much like, but not more so than in the rest of Emacs;-)

I thought we were more into detailed reviews and good code.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 08 Jul 2020 13:26:01 +0000
Resent-Message-ID: <handler.41531.B41531.15942147375425 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15942147375425
          (code B ref 41531); Wed, 08 Jul 2020 13:26:01 +0000
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 13:25:37 +0000
Received: from localhost ([127.0.0.1]:37664 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jtA4v-0001PR-41
	for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 09:25:37 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:58025)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1jtA4r-0001PC-NN
 for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 09:25:36 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0701D4410DF;
 Wed,  8 Jul 2020 09:25:28 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6F4784410D2;
 Wed,  8 Jul 2020 09:25:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1594214726;
 bh=e3p+BSWjcLbk2D1fwz9A3DnLAnl/r7G/oloClcHR5y8=;
 h=From:To:Cc:Subject:References:Date:In-Reply-To:From;
 b=BY+PzqtMbWdZLEznp08ImHgiBaqt0EcfPt7O1behb0HhYaT1tPA0UHbyHONOgpolt
 UkhR9KQFgbMB8AvMDq1iCyDRXovi59PfgPY1/5GqmMj4NGqzNaVhpl82cKdUuPbxb+
 hkq7l2CFlrQlnMZUsCqwchcGtKpE5E7//vwKeuIddI3LjmA6+JHwIETlX/UM4ZgiMo
 e44Zvc4fZpvpmZVSNkXlUch8RrtoDc59CQUUnGvt8gGLWsfydPfpVusXfyEX/5NX9T
 rqLeF06D5wzcWT6GYPZSXb/6ur3Z03Dx8TX1nEy68KCXeNxsxQbTu9NyPpbWdjW2F9
 G6kMVePEUAVJA==
Received: from alfajor (unknown [157.52.0.200])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D312F120820;
 Wed,  8 Jul 2020 09:25:25 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
 <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
 <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
 <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
 <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN>
Date: Wed, 08 Jul 2020 09:25:23 -0400
In-Reply-To: <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN> (Dmitry Gutov's
 message of "Wed, 8 Jul 2020 14:20:47 +0300")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.037 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
X-SPAM-LEVEL: 
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 (---)

>> I don't have the time or energy to work on eldoc myself, and apparently
>> neither do you, so the one who writes the code gets to take most of
>> the decisions.
> I have offered to do a rewrite multiple times now.

Feel free to do so.  But it does mean that one of you two will
be frustrated because your/his code won't be accepted.

Maybe a better option, then is to:

- do a quick version of the code for yourself.
- then compare that with Joao's version.
- then do a mix of:
  - argue to change or remove some parts of his code (those that would
    make it difficult for you to install your code on top of his)
  - keep the other changes to apply them after he installs his

WDYT?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 08 Jul 2020 13:42:01 +0000
Resent-Message-ID: <handler.41531.B41531.15942157167044 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, andreyk.mad@HIDDEN, Dmitry Gutov <dgutov@HIDDEN>
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.15942157167044
          (code B ref 41531); Wed, 08 Jul 2020 13:42:01 +0000
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 13:41:56 +0000
Received: from localhost ([127.0.0.1]:37685 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jtAKh-0001pY-Us
	for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 09:41:56 -0400
Received: from mail-wm1-f50.google.com ([209.85.128.50]:39211)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jtAKe-0001pJ-0u
 for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 09:41:54 -0400
Received: by mail-wm1-f50.google.com with SMTP id w3so3190389wmi.4
 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 06:41:51 -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;
 bh=fHg9khiPVJolhLfM//rUXhKCwZGk6zFXXQS7wg4UUMI=;
 b=rHY8MNPBHkj0/1kv5PISl/xFkexDhZ7kmMxzjYAQSsNh5qzg9nj8f7r6OIAR/iEZ+3
 0NfTnog9dKSDGnPs2EbobioQgaIg+JqmOAPvyN68rnUKDkbZHDiS9S3RJ7KNy+xWA+8g
 5cWljYh8xuKzWBRD26hpeZhXnbebQCiFOCeomsmt4zvkfUCgAEmHUk3/KVsOXKoyCsKh
 E1Rw9j71lsB8Qu/zYKD3MHpT0NEUibqUZX85DgCDoc6FZw978USAOFNA+kO80YLzFPej
 CfjwfbO7fO0gmKEMNEYuq+NxxNnGI5ZaFfv0SUaqWR8QIoEXaWEzwsOVqKDqC74vTEvm
 6hyA==
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;
 bh=fHg9khiPVJolhLfM//rUXhKCwZGk6zFXXQS7wg4UUMI=;
 b=I6vsSARqK+fpYfEKB8KJn7ZGg4O/Kd4TrSsyYe/kFqg+l2wEXZUa1uwDxcmAH+ZltS
 d+cb6eWCPF/S5i/p/+F/8C7cTUbdHuUJRpQrSS90DccglKvULy2P71Dt0kYd/MQYeFVz
 MZ2mqRSKkYIchA3FL3rpPE07cFoQM2WBjbkj6kUnO0gYaf7r5CcKTf1ToM1jkL3ZpeC/
 hRfVwTW4PMps/aEHzL2uQQmjQ7ITlpOu/mKRb5LWJP2sqh7Is6OLHT4q6iSnxvtqPfmQ
 YuVd5gZKSkgVYdB5q0h0Lo6jXDe2CCnkNomDWKboR+grEUv+1CmrflbKZlwdLnUusGvj
 svTQ==
X-Gm-Message-State: AOAM532mK7KXqMtcrKrLinfR4f71GFgJwo04OW6KN01V0SezR+UtyFQp
 tAH4qan4Ob32+MmZvuytfwQ=
X-Google-Smtp-Source: ABdhPJzYtJ9IQK/7PaAMoOG2nnXSY3mAaAgVVgyji0pX1DXZuOA5ryIwisqF7AeqeOPC7AIKeW4ieg==
X-Received: by 2002:a7b:c0c9:: with SMTP id s9mr8888933wmh.166.1594215706071; 
 Wed, 08 Jul 2020 06:41:46 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id g3sm7090075wrb.59.2020.07.08.06.41.44
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jul 2020 06:41:44 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
 <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
 <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
 <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
 <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN>
 <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN>
Date: Wed, 08 Jul 2020 14:41:43 +0100
In-Reply-To: <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN> (Stefan Monnier's message
 of "Wed, 08 Jul 2020 09:25:23 -0400")
Message-ID: <87tuyif7jc.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
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 (-)

Stefan Monnier <monnier@HIDDEN> writes:

>>> I don't have the time or energy to work on eldoc myself, and apparently
>>> neither do you, so the one who writes the code gets to take most of
>>> the decisions.
>> I have offered to do a rewrite multiple times now.
>
> Feel free to do so.  But it does mean that one of you two will
> be frustrated because your/his code won't be accepted.
>
> Maybe a better option, then is to:
>
> - do a quick version of the code for yourself.
> - then compare that with Joao's version.
> - then do a mix of:
>   - argue to change or remove some parts of his code (those that would
>     make it difficult for you to install your code on top of his)
>   - keep the other changes to apply them after he installs his
>
> WDYT?

Fine with this plan.  Would even dare to call it "development" ;-)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 08 Jul 2020 14:23:02 +0000
Resent-Message-ID: <handler.41531.B41531.159421813020149 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159421813020149
          (code B ref 41531); Wed, 08 Jul 2020 14:23:02 +0000
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 14:22:10 +0000
Received: from localhost ([127.0.0.1]:38835 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jtAxe-0005Ev-3O
	for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 10:22:10 -0400
Received: from mail-wr1-f50.google.com ([209.85.221.50]:36848)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jtAxb-0005EW-He
 for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 10:22:08 -0400
Received: by mail-wr1-f50.google.com with SMTP id k6so49231299wrn.3
 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 07:22:07 -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=Bp7JpwMNs5wuTE+MJSxTx6brSAGYlwp91Ryf2N+wyqY=;
 b=dHlVtWAYyZsAqB1BdMgIYtvD4fJTK4LJuMCFgXUpD2xyRphnmY3FrKc/UaSBOxoYYs
 bQkrQYVpdmsZl0KYyrpafLdDzHbSBz+UdJKAq3nDwy9ttMl4U17XRws1tbZIxzw3w/zO
 zAhdMF+qkvkBD5OfRuhWZx0/H5c7NSOTDwZ2wRXosn1P6utbbff7H5549SP68xd2zH9c
 SAK9PLVG6sGBeJqWb7pEbPOUK0m2rBRHOUttWzgs8fFv23q1J54hSpVewgt5hmCthU+y
 fEBUi084eShSgRqaGP4ZTicJ8SvVqOaSudGevTllnfTTvrQ9gX73MSerq8+DXmpgbo4m
 P3+w==
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=Bp7JpwMNs5wuTE+MJSxTx6brSAGYlwp91Ryf2N+wyqY=;
 b=H7fUhup8AOmEM00KdM7Y4xJiNoaEk5dxwc7fF0nfYcOR2JxIhpHk7+qfvqUjoAAsUK
 GCvtxYC055LxHskF71uvde/NGdZClupGmhEI/UZ3cwbefTt9QnIttyUZjVGCQHAtIiyp
 UKekFCWrFeYldDC3dNWUBW/6dE8xSO9mV2pLY1mxqAJ02K9/5MIEna6nixsw+gI9ja9W
 6CzKp7wRFSNBMBspVLEdU50sX8fEV+cM7/Wx8KNCjfDpCqxm+HDKNKP0FnWj8NGi5f1L
 Xxn2rg432VrEoRH2a60eDvxGmX9skAsllHnoYqo6j+1RSVBFJ26xBnD9baxsPfODXybd
 EIGQ==
X-Gm-Message-State: AOAM531pB2HMeuVAugBYeCljaHRlT7FcaJy+gIBEUDOWmTMH/UflwMMC
 +cR2cbfNy2MHz/lwvbUAoKc=
X-Google-Smtp-Source: ABdhPJzORD9yoNrpSJbRKCEq5yqI7amhR01ohBlHpENK4Q2tvPD5x4/UKvULs5WxoawgTvYwDLTRdg==
X-Received: by 2002:a05:6000:11cc:: with SMTP id
 i12mr57968344wrx.224.1594218120348; 
 Wed, 08 Jul 2020 07:22:00 -0700 (PDT)
Received: from [192.168.0.142] ([109.110.245.170])
 by smtp.googlemail.com with ESMTPSA id d132sm6454229wmd.35.2020.07.08.07.21.58
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jul 2020 07:21:59 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
 <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
 <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
 <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
 <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN>
 <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <7cc227db-f748-67d8-83b3-75502b9dbd9f@HIDDEN>
Date: Wed, 8 Jul 2020 17:21:57 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 08.07.2020 16:25, Stefan Monnier wrote:
> - do a quick version of the code for yourself.
> - then compare that with Joao's version.
> - then do a mix of:
>    - argue to change or remove some parts of his code (those that would
>      make it difficult for you to install your code on top of his)
>    - keep the other changes to apply them after he installs his

Since he went ahead, ignored the review and pushed the changes, 
apparently I can just do the same now.

That just leaves the buggy new features which went in without proper 
justification. Can I go ahead and remove them, then?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 08 Jul 2020 15:13:01 +0000
Resent-Message-ID: <handler.41531.B41531.159422117124840 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dgutov@HIDDEN>
Cc: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159422117124840
          (code B ref 41531); Wed, 08 Jul 2020 15:13:01 +0000
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 15:12:51 +0000
Received: from localhost ([127.0.0.1]:38932 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jtBkg-0006SZ-9J
	for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 11:12:51 -0400
Received: from mail-wm1-f48.google.com ([209.85.128.48]:55417)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <joaotavora@HIDDEN>) id 1jtBke-0006SM-BM
 for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 11:12:48 -0400
Received: by mail-wm1-f48.google.com with SMTP id g75so3614377wme.5
 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 08:12:48 -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=JSpg5unCxqWnXUsUvu2+Z0vifH96jB45jawovCQ5r1Y=;
 b=jorUetZr7pX2v3mmOOP2ds07WKBwHzRXYhnMdl3WABV24P0eRTeA2bWquQOoIInJj4
 yef5FYTyNk8HUIHL6S8movXlf8EOoj+Kq3WfyullnqQeipAWE8igqBQ3JZh1JWhWswrX
 tADMzcBE1fH7xiuaX5QsJBoAOOg3MLzK8eJTRiVuEXOi6QzGoA0IkKam0piOZpx3rqv4
 XTK3ElXvF6Mjn2SzjEqK2DpdsBEMGymt39rRKjpXmfjjCy4QEbqpC9V3ReBbEs/VHlFE
 IdMjrW8pMNda5o7Og7Q9eYtJrPX/GreLOO3vtDWZQvM/oJlUVtvfZgB+dU1R5ABUoXdO
 W4Mg==
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=JSpg5unCxqWnXUsUvu2+Z0vifH96jB45jawovCQ5r1Y=;
 b=R7S/bQ1vVrY4l7D8zprb3DEMsPbrZhengTUuzsfSxtRsPdkTIBTBOEiyyqhCZTw5HX
 sgFLVlr+aGN7Hltx1STaCdJRokZy9a00ZJqrIYDJiYITAlgGjMnVRAe4XWMeq5CRMDww
 Fk354Cvt0jVv03J0uUEUEkyuX+SRnFVSSpn4KkWj8SFDMhh+ZOiaNSjJRJVSVVigaNEP
 a/kj20agD13ywT4DL7Yf0ReqHa5wQRhyCzWLssU32MCrt5X5Fsii2zznpPXOeSKppNEs
 xBFg4SODWmsDt6L5LUeT5090T6yixLuH8WST96WBp7DpcpAIyuiIKcjGWWr7A5RymIQ/
 aMxQ==
X-Gm-Message-State: AOAM532UAq8m0d/7U9dAkGFWChuNCqjUXpfL3Lw3PqHEIAmvKeoxmSmL
 bYgGftckBUPUD9kQKOa0mDI=
X-Google-Smtp-Source: ABdhPJzIOYsqPMNzud4qtqyPiROBxNUWRgD7nmQv3SlcLfh9m9rflABVY38jo/43M580ojqJuN6PWQ==
X-Received: by 2002:a1c:7717:: with SMTP id t23mr9641530wmi.75.1594221162535; 
 Wed, 08 Jul 2020 08:12:42 -0700 (PDT)
Received: from krug ([2001:818:d820:9500:824a:171:15a:2213])
 by smtp.gmail.com with ESMTPSA id r28sm397388wrr.20.2020.07.08.08.12.40
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 Jul 2020 08:12:41 -0700 (PDT)
From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= <joaotavora@HIDDEN>
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN>
 <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN>
 <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN>
 <877dvfiofy.fsf@HIDDEN> <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
 <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
 <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
 <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
 <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN>
 <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN>
 <7cc227db-f748-67d8-83b3-75502b9dbd9f@HIDDEN>
Date: Wed, 08 Jul 2020 16:12:40 +0100
In-Reply-To: <7cc227db-f748-67d8-83b3-75502b9dbd9f@HIDDEN> (Dmitry Gutov's
 message of "Wed, 8 Jul 2020 17:21:57 +0300")
Message-ID: <87k0zef3br.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 08.07.2020 16:25, Stefan Monnier wrote:
>> - do a quick version of the code for yourself.
>> - then compare that with Joao's version.
>> - then do a mix of:
>>    - argue to change or remove some parts of his code (those that would
>>      make it difficult for you to install your code on top of his)
>>    - keep the other changes to apply them after he installs his
>
> Since he went ahead, ignored the review and pushed the changes,
> apparently I can just do the same now.
>
> That just leaves the buggy new features which went in without proper
> justification. Can I go ahead and remove them, then?

I think you should M-x report-emacs-bug and explain the bug.=20

Please stop falsely claiming I "ignored" you review.  This is distateful
and offensive.  I replied to both emails: neither were a code review
like Eli's and Stefan's were, which were much easier to follow.  For the
first one I replied diligently to each point as I could, especially when
direct mentions to code that weren't related to futures and when I could
understand your question.  While the first email was already quite full
of tension and off-hand remarks about my code being offensive and
undemonstrated claims about code being bad in general, the second one
was worse in that respect, it was purely opinative and again conflated
most issues with your penchant for an implementation based on futures,
making it extremely hard to follow your point, as I already told you.

Therefore, I suggest you describe the issues with M-x report-emacs-bug
for bugs and for features that you don't understand the value of.  Make
a separate bug report for each problem.  Again, I promise to reply to
those.  Here are suggestions for subject lines of those bug reports, as
I gathered them from my reading of your emails:

- No purpose in `eldoc-documentation-enthusiast`
- `eldoc-documentation-compose` causes blinking
- `eldoc-documentation-functions` should use futures library
- `eldoc-print-current-symbol-info` is extremely complicated
- This much simpler patch would solve all of Eldoc's asynchronous problems
- Eldoc now eats my homework

Etc, etc.  Hopefully some progress can be made in those discussions.

Thank you very much,
Jo=C3=A3o

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#41531: 27.0.91; Better handle asynchronous eldoc backends
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: Wed, 08 Jul 2020 18:33:01 +0000
Resent-Message-ID: <handler.41531.B41531.159423316319130 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 41531
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: 41531 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>, andreyk.mad@HIDDEN
Received: via spool by 41531-submit <at> debbugs.gnu.org id=B41531.159423316319130
          (code B ref 41531); Wed, 08 Jul 2020 18:33:01 +0000
Received: (at 41531) by debbugs.gnu.org; 8 Jul 2020 18:32:43 +0000
Received: from localhost ([127.0.0.1]:39062 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1jtEs6-0004yU-RQ
	for submit <at> debbugs.gnu.org; Wed, 08 Jul 2020 14:32:43 -0400
Received: from mail-wm1-f41.google.com ([209.85.128.41]:40918)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <raaahh@HIDDEN>) id 1jtEs5-0004yC-G1
 for 41531 <at> debbugs.gnu.org; Wed, 08 Jul 2020 14:32:41 -0400
Received: by mail-wm1-f41.google.com with SMTP id f139so4220285wmf.5
 for <41531 <at> debbugs.gnu.org>; Wed, 08 Jul 2020 11:32:41 -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=k9uBWhAimbshRgi1fv6bV7CWP09g1xda4vsB9LaCEgc=;
 b=SpRVbLgCp4ETBEuN6cNLxQBJiRG5Mn7jr7YishikJPj2fvmYrjAnOfu8rU3Hkj+D6i
 0IHBKw0mdmTdS4FCU0fnsC5AXbyRartWHHFIMLjLXrMtRhyOGmsKidimX1nByt3r4+S5
 MKWeNAVUc4sl5YCSXKHnqkWOPYl6bzWuwTKwmkHHbnzRP/f9r6H+N4tTmI5LC1m3gXe1
 cqo9dKM2Z5s0UfWD4VFiSD6wqZdhg0RVA1XRiaoBgi8YQdk9aZO0nbhH6OUuh2stFUjp
 ESKZAlfXDI3EK+/0pUs1F4ZLoSvGzHUe32P+iD3EQl6LkpRlpwJRSzHNs+bZeE1buAmT
 CQQg==
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=k9uBWhAimbshRgi1fv6bV7CWP09g1xda4vsB9LaCEgc=;
 b=QxwAS/ZMVeGho92MWTglA2xWUYo7/fgkiLDGLWyrJA3yjDA4SFecJsF62A5k6Av+Mr
 YcDxB5tfJOAmd/l1eZbBl1P5Wd6qoQh2vkjYQQPvE+MtcMRNVH8oubqHEppYev2E4GF9
 3Md27346ShT9HBdS96vxIBfLeA19hD6FG7ID0zERHBXRO4ROTCD2cA9zUTP40A4aCujF
 Ezf/Es2Fu85pM/oKZ7491NUwAGOyiWmk+X+tmkj5aF5IycbCF0ktvNAJIBCqKIOdkXda
 y2MP6HHL3SehzSnJfv2fX6sq+20Qtgh8cwaeMFe9a1SNgmXhdpZkA34JYH9j6MF4PXS8
 wf9w==
X-Gm-Message-State: AOAM531fO4LQGt32zfdE11zVEYzEjCLGFXXHcA3VCwzrz2S595Q4w/pZ
 hFI6+IBVKynfz5jwySKWJlg=
X-Google-Smtp-Source: ABdhPJxW6F375OUfvUioNHAF7JCsM+DLknkWGdK5hDeavjE8DBE+ROoZB+KFCyRtDTGrNBRoMhJNhg==
X-Received: by 2002:a1c:8117:: with SMTP id c23mr10129681wmd.157.1594233155428; 
 Wed, 08 Jul 2020 11:32:35 -0700 (PDT)
Received: from [192.168.0.3] ([66.205.73.129])
 by smtp.googlemail.com with ESMTPSA id h84sm1015731wme.22.2020.07.08.11.32.34
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Wed, 08 Jul 2020 11:32:34 -0700 (PDT)
References: <875zckuet9.fsf@HIDDEN> <87sgecssch.fsf@HIDDEN>
 <ee83696d-dc53-a33c-eb42-3699d0fc18b4@HIDDEN> <87tuynsdp6.fsf@HIDDEN>
 <5d768a69-3574-10c5-e80a-8ab77ec60462@HIDDEN> <87h7umop62.fsf@HIDDEN>
 <671983cf-e4f5-f128-541b-ceac793f35e5@HIDDEN> <877dvfiofy.fsf@HIDDEN>
 <jwvwo3fjvuk.fsf-monnier+emacs@HIDDEN>
 <3211602a-ccc6-aa53-d192-77f27c2060ce@HIDDEN>
 <jwvzh8bia9e.fsf-monnier+emacs@HIDDEN>
 <5a258c2b-39e7-76d7-0867-181ae3171710@HIDDEN>
 <jwvimeyy8k6.fsf-monnier+emacs@HIDDEN>
 <7f1ec72b-2608-ad60-573d-528d22671ff6@HIDDEN>
 <jwv7dvei3cm.fsf-monnier+emacs@HIDDEN>
 <7cc227db-f748-67d8-83b3-75502b9dbd9f@HIDDEN> <87k0zef3br.fsf@HIDDEN>
From: Dmitry Gutov <dgutov@HIDDEN>
Message-ID: <64585842-bd25-8610-153a-2143750e3ee8@HIDDEN>
Date: Wed, 8 Jul 2020 21:32:33 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <87k0zef3br.fsf@HIDDEN>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Spam-Score: 0.2 (/)
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: -0.8 (/)

On 08.07.2020 18:12, João Távora wrote:
> Please stop falsely claiming I "ignored" you review.  This is distateful
> and offensive.

Not as offensive as having one's writing ignored.

 > I replied to both emails: neither were a code review
like Eli's and Stefan's were, which were much easier to follow.

Both Stefan and Eli were too busy to do an in-depth review. And I now 
know better than to do one for you either.

 > While the first email was already quite full
of tension and off-hand remarks about my code being offensive and
undemonstrated claims about code being bad in general, the second one
was worse in that respect,

There was a lot of different issues discussed in those emails. You 
ignoring most of them and retelling the contents now in this simplistic 
way is offensive (but about on par with your other messages in this 
discussion). I'm not going to describe the same things again and again, 
in many different ways. I have wasted enough time on this already.

And if you didn't want reviews this long, you shouldn't have submitted a 
branch with multiple orthogonal features intermixed. You should have 
picked a proper solution to the issue #1, then filed a bug for the next 
one. Then we could have had much easier, targeted reviews.

Last modified: Wed, 8 Jul 2020 18:45:01 UTC

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