From unknown Sat Jun 21 12:17:28 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#42421 <42421@debbugs.gnu.org> To: bug#42421 <42421@debbugs.gnu.org> Subject: Status: 28.0.50; ElDoc requests too much documentation Reply-To: bug#42421 <42421@debbugs.gnu.org> Date: Sat, 21 Jun 2025 19:17:28 +0000 retitle 42421 28.0.50; ElDoc requests too much documentation reassign 42421 emacs submitter 42421 Jo=C3=A3o T=C3=A1vora severity 42421 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 18 20:02:15 2020 Received: (at submit) by debbugs.gnu.org; 19 Jul 2020 00:02:15 +0000 Received: from localhost ([127.0.0.1]:59447 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jwwmV-0002yt-Bn for submit@debbugs.gnu.org; Sat, 18 Jul 2020 20:02:15 -0400 Received: from lists.gnu.org ([209.51.188.17]:51056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jwwmU-0002ym-Cr for submit@debbugs.gnu.org; Sat, 18 Jul 2020 20:02:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35852) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwwmU-0007nI-5q for bug-gnu-emacs@gnu.org; Sat, 18 Jul 2020 20:02:14 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:45162) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jwwmS-0008Jz-6S for bug-gnu-emacs@gnu.org; Sat, 18 Jul 2020 20:02:13 -0400 Received: by mail-wr1-x434.google.com with SMTP id s10so14465762wrw.12 for ; Sat, 18 Jul 2020 17:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=W4jQpLzwRxg1rbpqw1E1lVyWgRhenn3V7EGC9jxCnao=; b=q6pCYDH7EUOL/fCrB7CXYSp7NNvuY9yQhtYORE9uR1p8IHroq6fTykTyl7WXb8BM3m 55jFJp8CXC/yzllg5VbZv5v7AyU00qgL4Ls6l8odB1P4s3X8667xsaLMrjFjOmmmecGe 9po0Eq/Gjk3+DTQXm0DxzkdfWfTAbayCXgTh8iPbavQp2Aac96+zqukouYk9hZRCehNb EZ5dDFFPheYZGjTjPnKhIUR9yVcyZ4FSZBVtexrkcTQnm3BeprkrhY0UceaimglNtl45 ha5oQUMnwg8SAkj0G1eMd+1ClLdNnTsmI/EP2xFbc4Msh2SLBvWSfggfxeiyNDrHIT8b K6zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=W4jQpLzwRxg1rbpqw1E1lVyWgRhenn3V7EGC9jxCnao=; b=FT//fwpXABc12RCysPVZ3kGtTNFnc1buDzWtoTW+oeBGm4f8iTNOWy1aYNs5v5TxDN p/1wh1XOlK6H/1Nyli0fWDTsskm2w/CV+3qkbBOXx0bLm80/96CRq7ObsN+kL3o/K/mb mNAND6Vw3WxaaLlnV1cjbQx6aqpO3QIpys4i3V2V4BpkQ/m/O3IbxsCZB5ImOCSocLox lsVcSnQLanpltZkNrAzm1hXKRcYe90V2L5ZwqbxKaSyoAbrJFG8bwFS19p6XJq9fJgjg xkM+5UxqkZgKg3ttm43QAt2PyV7MFqtLPnu+JYiG6L/Ig4NYUsllU8gN+q8FzuJf/ilB c/3g== X-Gm-Message-State: AOAM5303OPoes0N15LenRC3s/HfQQWDXdobX3L5bRGEisPkhH7nMWtpx BOC0982f9FVUKPbPrsSptrvgk5gz X-Google-Smtp-Source: ABdhPJymls2Ch3Tvdl+gsQnL2UD2XMZmTHgfa7bxblnRMXnHcZd7Cf37b/VcUtTt0Urbczj6D8nL/w== X-Received: by 2002:a5d:42c9:: with SMTP id t9mr3180948wrr.38.1595116930034; Sat, 18 Jul 2020 17:02:10 -0700 (PDT) Received: from krug ([89.180.151.184]) by smtp.gmail.com with ESMTPSA id t14sm11218782wrv.14.2020.07.18.17.02.09 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Jul 2020 17:02:09 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: bug-gnu-emacs@gnu.org Subject: 28.0.50; ElDoc requests too much documentation X-Debbugs-CC: felician.nemeth@gmail.com Date: Sun, 19 Jul 2020 01:02:07 +0100 Message-ID: <87imeke5j4.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=2a00:1450:4864:20::434; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x434.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I'm following up on a bug started in https://github.com/joaotavora/eglot/issues/445. In the latest ElDoc, when the *eldoc* buffer is showing a lenghty docstrings for some situation in a source buffer, switching to that buffer scrolling around, then switching back to the same position in the source buffer will lead to that very documentation being re-requested, ultimately undoing the scrolling work done previously by the user. The attached patch prevents needless, superfluous doc requests when the requester's state is found to be identical to the state recorded in a visible *eldoc* buffer. These kinds of situation must be taken into account when redesigning the mechanism for allowing multiple outlets for documentation. For now, the patch should fix the situation. Felici=C3=A1n, please try it out. Notice that it probably needs the Emacs master version of eldoc.el (where, BTW, I have already fixed the other bug you report in the Github issue). Jo=C3=A3o --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Don-t-needlessly-request-docs-from-ElDoc-functions.patch >From 526dcda35ca2b61ffda7005fb0fd62ae2f80bc06 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jo=C3=A3o=20T=C3=A1vora?= Date: Sun, 19 Jul 2020 00:48:43 +0100 Subject: [PATCH] Don't needlessly request docs from ElDoc functions Do this conservatively for now: if the ElDoc doc buffer is visible and showing documentation for the very same situation the source buffer is still in, don't request it again. * lisp/emacs-lisp/eldoc.el (eldoc--request-docs-p): Rework from eglot-display-message-p. (eldoc--last-request-state): New variable. (eldoc--request-state): New helper. (eldoc--handle-docs): Memorize state of request in doc buffer. (eldoc-print-current-symbol-info): Pass a token to eldoc--request-docs-p. --- lisp/emacs-lisp/eldoc.el | 59 ++++++++++++++++++++++++++++------------ 1 file changed, 41 insertions(+), 18 deletions(-) diff --git a/lisp/emacs-lisp/eldoc.el b/lisp/emacs-lisp/eldoc.el index 6ed5bff9f4..20b796c529 100644 --- a/lisp/emacs-lisp/eldoc.el +++ b/lisp/emacs-lisp/eldoc.el @@ -340,16 +340,32 @@ eldoc-pre-command-refresh-echo-area ;; for us, but do note that the last-message will be gone. (setq eldoc-last-message nil)))) -;; Decide whether now is a good time to display a message. -(defun eldoc-display-message-p () - "Return non-nil when it is appropriate to display an ElDoc message." - (and (eldoc-display-message-no-interference-p) - ;; If this-command is non-nil while running via an idle - ;; timer, we're still in the middle of executing a command, - ;; e.g. a query-replace where it would be annoying to - ;; overwrite the echo area. - (not this-command) - (eldoc--message-command-p last-command))) +(defvar-local eldoc--last-request-state nil + "Tuple containing information about last ElDoc request.") +(defun eldoc--request-state () + "Compute information to store in `eldoc--last-request-state'." + (list (current-buffer) (buffer-modified-tick) (point))) + +(defun eldoc--request-docs-p (request-state) + "Return non-nil when it is appropriate to request docs. +REQUEST-STATE is a candidate for `eldoc--last-request-state'" + (and + ;; FIXME: The original idea behind this function is to protect the + ;; Echo area from ElDoc interference, but since that is only one of + ;; the possible outlets of ElDoc, this must soon be reworked. + (eldoc-display-message-no-interference-p) + (not (and eldoc--doc-buffer + (get-buffer-window eldoc--doc-buffer) + (equal request-state + (with-current-buffer + eldoc--doc-buffer + eldoc--last-request-state)))) + ;; If this-command is non-nil while running via an idle + ;; timer, we're still in the middle of executing a command, + ;; e.g. a query-replace where it would be annoying to + ;; overwrite the echo area. + (not this-command) + (eldoc--message-command-p last-command))) ;; Check various conditions about the current environment that might make @@ -400,7 +416,8 @@ eldoc-documentation-functions taken into account if the major mode specific function does not return any documentation.") -(defvar eldoc--doc-buffer nil "Buffer holding latest eldoc-produced docs.") +(defvar eldoc--doc-buffer nil "Buffer displaying latest ElDoc-produced docs.") + (defun eldoc-doc-buffer (&optional interactive) "Get latest *eldoc* help buffer. Interactively, display it." (interactive (list t)) @@ -410,6 +427,7 @@ eldoc-doc-buffer (setq eldoc--doc-buffer (get-buffer-create "*eldoc*"))) (when interactive (display-buffer eldoc--doc-buffer)))) + (defun eldoc--handle-docs (docs) "Display multiple DOCS in echo area. DOCS is a list of (STRING PLIST...). It is already sorted. @@ -429,9 +447,12 @@ eldoc--handle-docs (integer val) (t 1))) (things-reported-on) + (request eldoc--last-request-state) single-doc single-doc-sym) ;; Then, compose the contents of the `*eldoc*' buffer. (with-current-buffer (eldoc-doc-buffer) + ;; Set doc-buffer's `eldoc--last-request-state', too + (setq eldoc--last-request-state request) (let ((inhibit-read-only t)) (erase-buffer) (setq buffer-read-only t) (local-set-key "q" 'quit-window) @@ -741,14 +762,16 @@ eldoc--invoke-strategy (defun eldoc-print-current-symbol-info (&optional interactive) "Document thing at point." (interactive '(t)) - (cond (interactive - (eldoc--invoke-strategy)) - (t - (if (not (eldoc-display-message-p)) - ;; Erase the last message if we won't display a new one. - (when eldoc-last-message - (eldoc--message nil)) + (let ((token (eldoc--request-state))) + (cond (interactive + (eldoc--invoke-strategy)) + ((not (eldoc--request-docs-p token)) + ;; Erase the last message if we won't display a new one. + (when eldoc-last-message + (eldoc--message nil))) + (t (let ((non-essential t)) + (setq eldoc--last-request-state token) ;; Only keep looking for the info as long as the user hasn't ;; requested our attention. This also locally disables ;; inhibit-quit. -- 2.25.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 23 07:04:21 2020 Received: (at 42421-done) by debbugs.gnu.org; 23 Jul 2020 11:04:21 +0000 Received: from localhost ([127.0.0.1]:44170 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jyZ1R-0001Ud-8B for submit@debbugs.gnu.org; Thu, 23 Jul 2020 07:04:21 -0400 Received: from mail-wr1-f50.google.com ([209.85.221.50]:34922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jyZ1Q-0001UR-7p for 42421-done@debbugs.gnu.org; Thu, 23 Jul 2020 07:04:20 -0400 Received: by mail-wr1-f50.google.com with SMTP id f1so4192702wro.2 for <42421-done@debbugs.gnu.org>; Thu, 23 Jul 2020 04:04:20 -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=khVnbHvT9Hyzx2zGIPsKweNKuuZ1lPbntdvDmmHMFps=; b=X8elmyL6edl6A3YUhbO7pwAsHfZqU5GvKgA+cr9lKgCwetcoYvAzH6LlDBkb8vgqxR EyRKU2VLPk/zoii4ebYG6oUEW6v4+cx3pQJ3agyIvCyStZVespIUZfnxKakqaiPSkuNM JM1TL/qaMwT81ax0C+2w0RhIpcYJ21oT7N85tXOaSM2exLtVBOZNMBbxHlTHxKE5DGdQ s6a6sA47ZdWmTzBBWblbToUXYbWN6VnbvK9bIVpyZCflZjJ1EPPsWiqToSRsLYATT+oB +zwU/BgXbrOw8k27psJtyZrAZTyEomrf1tdqjf+CDxhP2myTvilGJ6eix1nuiuyC8PD2 knwQ== 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=khVnbHvT9Hyzx2zGIPsKweNKuuZ1lPbntdvDmmHMFps=; b=YAoPSlBQAQ8cFb9N75gW4Eb8HxUhw3JBDJXI7nigNJszqwi4QwD3e3OyldCclg7K4B waj51Be34RA95ihwa1+bg8/Zc9Oy0iUxY/7deLcvN46dN0lyNN1FWmLkNMZ13r838wp/ /skBRwaeo+g0p0IjzUD07pXoZm0UvKIEFAW6OEPNm3iOa/wcPbpFaoAOjYREyu3FOTGS Xui8/f6zsN7sfFpgL/RLenghmp4deNltlbssk1K2w2AMwTIoqa15jFLE7pxOgUJOnIpU eg91KxM2npQDsKlg5LM0nVyu5/l42cL5u3L9yqv6eq7/jFB5Y4u2yVxpkdwv6twb944U Zirw== X-Gm-Message-State: AOAM532CeAWZoHK0cD10BbZ2zuRfvt/Wb1XuQS4GFH7ftRXV7MgKt+ps xNfSPvNi6LUopsZ5rOyELIK+6C4lya8VTzlqO967INSu X-Google-Smtp-Source: ABdhPJxLNlLhNk9FAK+rlILzvQ8ZjupAhooonDjORzWsmqqqb1uaTqmxhvBTszkyi9J2rAbp7LOdxjdQbFnomTRxi4s= X-Received: by 2002:adf:fb87:: with SMTP id a7mr1752604wrr.390.1595502253991; Thu, 23 Jul 2020 04:04:13 -0700 (PDT) MIME-Version: 1.0 References: <87imeke5j4.fsf@gmail.com> In-Reply-To: <87imeke5j4.fsf@gmail.com> From: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Date: Thu, 23 Jul 2020 12:04:02 +0100 Message-ID: Subject: Re: bug#42421: 28.0.50; ElDoc requests too much documentation To: 42421-done@debbugs.gnu.org Content-Type: multipart/alternative; boundary="000000000000166c3705ab19d190" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42421-done Cc: felician.nemeth@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000166c3705ab19d190 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've pushed the patch that fixes this. The commit message hints at the steps needed to prevent a resurgence of this bug when more developments in eldoc.el are performed: Author: Jo=C3=A3o T=C3=A1vora Date: Sun Jul 19 00:48:43 2020 +0100 Don't needlessly request docs from ElDoc functions Fixes: bug#42421 Do this conservatively for now: if the ElDoc helper buffer (as returned by eldoc--doc-buffer) is visible and showing documentation for the very same "situation" (as computed by the the new eldoc--request-state helper), don't request that documentation from sources again. Before this change, not only was that request inefficient but if the user invoked scroll-other-window to see more of the helper buffer, that would eventually cause it to be reformatted and unexpectedly recentered. Later on, when a customizable list of documentation "sinks" is offered to the user, say, something like eldoc-display-functions, this process must be consolidated. In those circumstances, as soon as one of those sinks signals that it doesn't have up-to-date documentation for the state computed by eldoc--request-state, documentation will have to be requested anew from eldoc-documentation-functions via eldoc--invoke-strategy. * lisp/emacs-lisp/eldoc.el (eldoc--request-docs-p): Rework from eglot-display-message-p. (eldoc--last-request-state): New variable. (eldoc--request-state): New helper. (eldoc--handle-docs): Memorize state of request in doc buffer. (eldoc-print-current-symbol-info): Pass a token to eldoc--request-docs-p. (Version): Bump to 1.6.0 On Sun, Jul 19, 2020 at 1:03 AM Jo=C3=A3o T=C3=A1vora wrote: > Hello, I'm following up on a bug started in > https://github.com/joaotavora/eglot/issues/445. > > In the latest ElDoc, when the *eldoc* buffer is showing a lenghty > docstrings for some situation in a source buffer, switching to that > buffer scrolling around, then switching back to the same position in the > source buffer will lead to that very documentation being re-requested, > ultimately undoing the scrolling work done previously by the user. > > The attached patch prevents needless, superfluous doc requests when the > requester's state is found to be identical to the state recorded in a > visible *eldoc* buffer. > > These kinds of situation must be taken into account when redesigning the > mechanism for allowing multiple outlets for documentation. > > For now, the patch should fix the situation. Felici=C3=A1n, please try i= t > out. Notice that it probably needs the Emacs master version of eldoc.el > (where, BTW, I have already fixed the other bug you report in the Github > issue). > > Jo=C3=A3o > > --=20 Jo=C3=A3o T=C3=A1vora --000000000000166c3705ab19d190 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've pushed the patch that fixes this.=C2=A0 The = commit message hints at the
steps needed to prevent a resurg= ence of this bug when more developments
in eldoc.el are performed= :

Author: Jo=C3=A3o T=C3=A1vora <joaotavora@gmail.com>
Date: =C2=A0 Sun = Jul 19 00:48:43 2020 +0100

=C2=A0 =C2=A0 Don't needlessly reques= t docs from ElDoc functions
=C2=A0 =C2=A0
=C2=A0 =C2=A0 Fixes: bug#4= 2421
=C2=A0 =C2=A0
=C2=A0 =C2=A0 Do this conservatively for now: if = the ElDoc helper buffer (as
=C2=A0 =C2=A0 returned by eldoc--doc-buffer)= is visible and showing documentation
=C2=A0 =C2=A0 for the very same &q= uot;situation" (as computed by the the new
=C2=A0 =C2=A0 eldoc--req= uest-state helper), don't request that documentation from
=C2=A0 =C2= =A0 sources again.
=C2=A0 =C2=A0
=C2=A0 =C2=A0 Before this change, n= ot only was that request inefficient but if the
=C2=A0 =C2=A0 user invok= ed scroll-other-window to see more of the helper buffer,
=C2=A0 =C2=A0 t= hat would eventually cause it to be reformatted and unexpectedly
=C2=A0 = =C2=A0 recentered.
=C2=A0 =C2=A0
=C2=A0 =C2=A0 Later on, when a cust= omizable list of documentation "sinks" is offered
=C2=A0 =C2= =A0 to the user, say, something like eldoc-display-functions, this process<= br>=C2=A0 =C2=A0 must be consolidated.=C2=A0 In those circumstances, as soo= n as one of those
=C2=A0 =C2=A0 sinks signals that it doesn't have u= p-to-date documentation for the
=C2=A0 =C2=A0 state computed by eldoc--r= equest-state, documentation will have to be
=C2=A0 =C2=A0 requested anew= from eldoc-documentation-functions via
=C2=A0 =C2=A0 eldoc--invoke-stra= tegy.
=C2=A0 =C2=A0
=C2=A0 =C2=A0 * lisp/emacs-lisp/eldoc.el (eldoc-= -request-docs-p): Rework from
=C2=A0 =C2=A0 eglot-display-message-p.
= =C2=A0 =C2=A0 (eldoc--last-request-state): New variable.
=C2=A0 =C2=A0 (= eldoc--request-state): New helper.
=C2=A0 =C2=A0 (eldoc--handle-docs): M= emorize state of request in doc buffer.
=C2=A0 =C2=A0 (eldoc-print-curre= nt-symbol-info): Pass a token to
=C2=A0 =C2=A0 eldoc--request-docs-p.=C2=A0 =C2=A0 (Version): Bump to 1.6.0

On Sun, Jul 19, 2020 at 1:= 03 AM Jo=C3=A3o T=C3=A1vora <joa= otavora@gmail.com> wrote:
Hello, I'm following up on a bug started in
https://github.com/joaotavora/eglot/issues/445.
In the latest ElDoc, when the *eldoc* buffer is showing a lenghty
docstrings for some situation in a source buffer, switching to that
buffer scrolling around, then switching back to the same position in the source buffer will lead to that very documentation being re-requested,
ultimately undoing the scrolling work done previously by the user.

The attached patch prevents needless, superfluous doc requests when the
requester's state is found to be identical to the state recorded in a visible *eldoc* buffer.

These kinds of situation must be taken into account when redesigning the mechanism for allowing multiple outlets for documentation.

For now, the patch should fix the situation.=C2=A0 Felici=C3=A1n, please tr= y it
out.=C2=A0 Notice that it probably needs the Emacs master version of eldoc.= el
(where, BTW, I have already fixed the other bug you report in the Github issue).

Jo=C3=A3o



--
Jo=C3=A3o T=C3=A1vora
--000000000000166c3705ab19d190-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 25 13:36:56 2020 Received: (at 42421) by debbugs.gnu.org; 25 Jul 2020 17:36:56 +0000 Received: from localhost ([127.0.0.1]:51077 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzO6S-00071z-ET for submit@debbugs.gnu.org; Sat, 25 Jul 2020 13:36:56 -0400 Received: from mail-ed1-f52.google.com ([209.85.208.52]:32864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jzO6O-00071j-NM for 42421@debbugs.gnu.org; Sat, 25 Jul 2020 13:36:55 -0400 Received: by mail-ed1-f52.google.com with SMTP id h28so9227522edz.0 for <42421@debbugs.gnu.org>; Sat, 25 Jul 2020 10:36:52 -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:face:mime-version:content-transfer-encoding; bh=lSRsHsXInZsbxsgyQ4/wwsZ7ZlgXJo1omi8KJSoGaEQ=; b=gK/1uodt2fM31fs13LtEu7EXtI3yFdf+19h5/yYX6TOzvhJpXqpcLXQWyI0aU6qJXk 79QuF9nEPObTjnhuaaexOa/vCnWs/7WSR3Hsuh2hOd65gQ1BVIujOJgA3f9oME7WyvC0 4viSd8zCogEdrD3xGbfEZwKpLG18KAb2OyefV1XZ+OBdhswt4PAvrg8J2dkQyPQRVe/h fYe0H4MW4sykHgsEjNj3sAcQtliGFallCWnNTXab6XqVHSuS2f0R9w7vjo2wiPDr3O1L VaKxTVbO9sEgKwR5JpzgJhAnU3sab0CobriwvvI2p8IabuTDAh1IJ3X3FqtEGZuOSfJT kOJQ== 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:face:mime-version:content-transfer-encoding; bh=lSRsHsXInZsbxsgyQ4/wwsZ7ZlgXJo1omi8KJSoGaEQ=; b=dXxiYmid/wgRNB8d9h4nRrqA7turSSkAs8PdOvDA1pUvgr8nbqYYzNyhsnxBaDVJ98 LMi9M5UHoXGASOpsy4mFBhDD2bFIGC0UwQqftg94TEsjc6duMAkgOryotBCKwzVcna6j svLEpIRalx6O9PIc2WYzcYylT78WkWCSksOQdSK8/naMfEpeOWCdrEI63tQ0B/0ADBJ1 yf73fPXPxisHlsUZpGYeq0MD0Te5dBDlVdYBxQPhAmXlwKil8sHVRW/eYm7DSZUku+vM G/cb8okAmS26Dx+th/3clppzoeQDsKAgJNPV2bAogz/TBWmwrgGa2KCxHfDMjlHrZ5yV Fsfw== X-Gm-Message-State: AOAM532N22ASs4DzfzGre0bX0Lfa/FMIgePFuY2kQQj9Z6PR2tA+t48W OzlUy222cZFjNhaJ7mme2belyohk X-Google-Smtp-Source: ABdhPJxYejqlpmTO14tyVgEAysSR7XuDtEhewaT6SBRc6QqIlISRPsmgSZiuW5BayNW4i8KQ98/vVQ== X-Received: by 2002:aa7:dc4f:: with SMTP id g15mr1276807edu.335.1595698606579; Sat, 25 Jul 2020 10:36:46 -0700 (PDT) Received: from betli.gmail.com (catv-86-101-17-125.catv.broadband.hu. [86.101.17.125]) by smtp.gmail.com with ESMTPSA id r9sm3385963edt.1.2020.07.25.10.36.45 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 25 Jul 2020 10:36:46 -0700 (PDT) From: Felician Nemeth To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Subject: Re: bug#42421: 28.0.50; ElDoc requests too much documentation References: <87imeke5j4.fsf@gmail.com> Date: Sat, 25 Jul 2020 19:36:44 +0200 In-Reply-To: <87imeke5j4.fsf@gmail.com> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1vor?= =?utf-8?Q?a=22's?= message of "Sun, 19 Jul 2020 01:02:07 +0100") Message-ID: <87wo2rijir.fsf@betli.tmit.bme.hu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEUMBwgHAgMFAAGPjY7/ //80MDHq6eqJt3pKAAABr0lEQVQ4jX2UzZKDIAzHqR177q7TPbtx2HMr6guQcrbY9txZ0fd/hA0f onXazcEJ/CD8E4Js8/HS9mwjXtqeMRxHXJkakTEm4b4GPVQW8PU8ov4fQCqeThlF60MBWdo1IXzd 2nEEZE7CEAZLwI0N/gJAhTj7ESQAX4gPgO8lyI+cvgViSVPlNomAj2M9gW40eg7VWY3cATjUcyiO Z+i03cFruGLYoUR7VyU3HihdmCEVhoDN65FXkpbSxkomOzsTQN/gySaodGb9Gdi1oSRXP46gdBWh LcUKJNdeGCWac74GKakmne0aHCFvyqJPYLsCFAVlhRTvGdzMdLHqtgRyUulyXIAH7CYQ3AB0Nody JQhAkq/qtOnbjhxdzYDkXPxlH5y4WdUAeUcX1NVJ6GR7UQEYPGWoAnA36OQNn5lRRp38vHTAp9Br LoTmvlPPDoRCKzpjG1SXT89AaT5l456BamJuMcs+NIOMzJ/s5dI6yUVcrARlruwOebfdv6gunTn4 ww3+QjGBEn5suVyLHoSGvAqREuDLN+iqZ+VcFg+HBbsJUU9+FZthbez9T+bdb+kPv2Ls6ct3hTkA AAAASUVORK5CYII= MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 42421 Cc: 42421@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Felici=E1n, please try it out. I don't see this issue with the latest master. Thank you, Felici=E1n From unknown Sat Jun 21 12:17:28 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 23 Aug 2020 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator