From unknown Sat Jun 21 10:43:59 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#41781 <41781@debbugs.gnu.org> To: bug#41781 <41781@debbugs.gnu.org> Subject: Status: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Reply-To: bug#41781 <41781@debbugs.gnu.org> Date: Sat, 21 Jun 2025 17:43:59 +0000 retitle 41781 27.0.91; [PATCH] Eldoc describes the wrong function when read= ing an expression from the minibuffer reassign 41781 emacs submitter 41781 Daniel Koning severity 41781 minor tag 41781 patch thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 09 22:56:28 2020 Received: (at submit) by debbugs.gnu.org; 10 Jun 2020 02:56:28 +0000 Received: from localhost ([127.0.0.1]:33100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jiquh-0004Eq-LM for submit@debbugs.gnu.org; Tue, 09 Jun 2020 22:56:28 -0400 Received: from lists.gnu.org ([209.51.188.17]:43258) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jiquf-0004Eg-Q4 for submit@debbugs.gnu.org; Tue, 09 Jun 2020 22:56:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:53740) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jiquf-0005SG-HA for bug-gnu-emacs@gnu.org; Tue, 09 Jun 2020 22:56:25 -0400 Received: from sender4-of-o56.zoho.com ([136.143.188.56]:21653) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1jique-0006hc-CS for bug-gnu-emacs@gnu.org; Tue, 09 Jun 2020 22:56:25 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1591757778; cv=none; d=zohomail.com; s=zohoarc; b=HAZ4zOk5SxpymvHXOmQGCgeBnCQx1hl47bGgDUSNxgFsezL2FcpbyBH8Bnnw5DBDNq1C0MFc4OhbqcIhXN8d2vbHvSCXNUgVwo1qJ6Pg8vfGjrblCvLMSjAzAJvJcLVTP1KEOjwZIBGwHXQ0KXHBx+4Rs6VJU2DH8xAyc60SV90= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1591757778; h=Content-Type:Date:From:MIME-Version:Message-ID:Subject:To; bh=MVMydE3AvfGLURR34mlVxp8EUCjXR6/GCd4qp3qCXN4=; b=QpnMPIUZeeREehEeibL+zz2i9SGIBiggDNO3DexX/Bdv5yybBa4lSb+XzjOIibDDYawg7PnWdExOJJTopz+84DyT8szlCYyLHY9dNrvBug2aHkjni8b2kDqXG1g8qAgWGOq3yK3tbCk5Ykk4I/F6Pvx8xLVpczzPFEgFhzRAEHo= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=dk@danielkoning.com; dmarc=pass header.from= header.from= Received: from cornelius (112.157.239.35.bc.googleusercontent.com [35.239.157.112]) by mx.zohomail.com with SMTPS id 1591757776290483.59589247107033; Tue, 9 Jun 2020 19:56:16 -0700 (PDT) From: Daniel Koning To: bug-gnu-emacs@gnu.org Subject: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Date: Tue, 09 Jun 2020 21:56:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Zoho-Virus-Status: 1 X-ZohoMailClient: External Received-SPF: pass client-ip=136.143.188.56; envelope-from=dk@danielkoning.com; helo=sender4-of-o56.zoho.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/06/09 22:56:20 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Score: -1.3 (-) 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 Severity: minor Tags: patch The Eldoc message shows the documentation for the wrong function (or no documentation at all) in this specific situation: (a) You're typing an elisp expression into `read-from-minibuffer', and (b) the function name contains punctuation, such as ! or ?, whose character class is "punctuation" and not "symbol" in the standard syntax table. Function names as described in (b) are not only legal but quite common in third-party code. There aren't many in the standard distribution, but you'll notice a few here and there. Try this: (require 'pcvs) (call-interactively #'eval-expression) ----- Eval: (cvs-mode! ----- The mode line shows the documentation for `cvs-mode' (without the !), which is a different function and has a different lambda list. This is happening because the syntax table in the minibuffer never gets changed to the elisp table, which acknowledges all the valid symbol characters as part of the "symbol" class. There are a couple different spots in the code to which you could attribute this lapse. For one, the elisp-mode.el function `elisp--current-symbol' isn't wrapped in a `with-syntax-table', unlike other similar definitions in the same file. I think anyone invoking this function could reasonably expect it to observe elisp syntax, so that's what my tiny patch addresses. This fixes the Eldoc problem. But here's another weird thing further down the call stack. `read--expression' has a FIXME comment saying to turn on `emacs-lisp-mode' in the minibuffer -- which would also set the appropriate syntax table -- but it doesn't actually do it. I guess that must not work for whatever reason (since it has to have taken longer to write the comment than it would have taken to add the code). Should it be changed now so that it does set the major mode? Is there a problem with specialized major modes in the minibuffer? I hereby kick the can over to whoever knows more. Daniel --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-lisp-progmodes-elisp-mode.el-elisp-current-symbol-Se.patch Content-Description: elisp--current-symbol patch >From 1d4ed0e89b4ebc040609b7476128062685843c7f Mon Sep 17 00:00:00 2001 From: Daniel Koning Date: Tue, 9 Jun 2020 19:24:11 -0500 Subject: [PATCH] lisp/progmodes/elisp-mode.el (elisp--current-symbol): Set syntax table. Even if `elisp-current-symbol' is called from a buffer with a different active syntax table (such as the minibuffer in `read-from-minibuffer'), use `emacs-lisp-mode-syntax-table' to determine the symbol boundaries. Copyright-paperwork-exempt: yes --- lisp/progmodes/elisp-mode.el | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el index f39ecf9b7b..65c01b2ce1 100644 --- a/lisp/progmodes/elisp-mode.el +++ b/lisp/progmodes/elisp-mode.el @@ -1615,10 +1615,11 @@ elisp--beginning-of-sexp ;; returns nil unless current word is an interned symbol. (defun elisp--current-symbol () - (let ((c (char-after (point)))) - (and c - (memq (char-syntax c) '(?w ?_)) - (intern-soft (current-word))))) + (with-syntax-table emacs-lisp-mode-syntax-table + (let ((c (char-after (point)))) + (and c + (memq (char-syntax c) '(?w ?_)) + (intern-soft (current-word)))))) (defun elisp-function-argstring (arglist) "Return ARGLIST as a string enclosed by (). -- 2.20.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 20 03:49:40 2020 Received: (at 41781) by debbugs.gnu.org; 20 Jun 2020 07:49:40 +0000 Received: from localhost ([127.0.0.1]:57215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jmYFw-0005pP-CE for submit@debbugs.gnu.org; Sat, 20 Jun 2020 03:49:40 -0400 Received: from eggs.gnu.org ([209.51.188.92]:57906) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jmYFl-0005p1-RC for 41781@debbugs.gnu.org; Sat, 20 Jun 2020 03:49:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36287) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmYFf-0002N3-M8; Sat, 20 Jun 2020 03:49:23 -0400 Received: from [176.228.60.248] (port=2940 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jmYFe-0000uM-Og; Sat, 20 Jun 2020 03:49:23 -0400 Date: Sat, 20 Jun 2020 10:49:14 +0300 Message-Id: <83h7v6w51h.fsf@gnu.org> From: Eli Zaretskii To: Daniel Koning , Stefan Monnier In-Reply-To: (message from Daniel Koning on Tue, 09 Jun 2020 21:56:14 -0500) Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41781 Cc: 41781@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: -3.3 (---) Stefan, any comments? > From: Daniel Koning > Date: Tue, 09 Jun 2020 21:56:14 -0500 > > The Eldoc message shows the documentation for the wrong function (or no > documentation at all) in this specific situation: > > (a) You're typing an elisp expression into `read-from-minibuffer', and > (b) the function name contains punctuation, such as ! or ?, whose > character class is "punctuation" and not "symbol" in the standard syntax > table. > > Function names as described in (b) are not only legal but quite common > in third-party code. There aren't many in the standard distribution, but > you'll notice a few here and there. Try this: > > (require 'pcvs) > (call-interactively #'eval-expression) > ----- > Eval: (cvs-mode! > ----- > > The mode line shows the documentation for `cvs-mode' (without the !), > which is a different function and has a different lambda list. > > This is happening because the syntax table in the minibuffer never gets > changed to the elisp table, which acknowledges all the valid symbol > characters as part of the "symbol" class. > > There are a couple different spots in the code to which you could > attribute this lapse. For one, the elisp-mode.el function > `elisp--current-symbol' isn't wrapped in a `with-syntax-table', unlike > other similar definitions in the same file. I think anyone invoking this > function could reasonably expect it to observe elisp syntax, so that's > what my tiny patch addresses. This fixes the Eldoc problem. > > But here's another weird thing further down the call stack. > `read--expression' has a FIXME comment saying to turn on > `emacs-lisp-mode' in the minibuffer -- which would also set the > appropriate syntax table -- but it doesn't actually do it. I guess that > must not work for whatever reason (since it has to have taken longer to > write the comment than it would have taken to add the code). Should it > be changed now so that it does set the major mode? Is there a problem > with specialized major modes in the minibuffer? I hereby kick the can > over to whoever knows more. > > Daniel > > > [2:text/x-patch Hide Save:0001-lisp-progmodes-elisp-mode.el-elisp-current-symbol-Se.patch (1kB)] > > >From 1d4ed0e89b4ebc040609b7476128062685843c7f Mon Sep 17 00:00:00 2001 > From: Daniel Koning > Date: Tue, 9 Jun 2020 19:24:11 -0500 > Subject: [PATCH] lisp/progmodes/elisp-mode.el (elisp--current-symbol): Set > syntax table. > > Even if `elisp-current-symbol' is called from a buffer with a different > active syntax table (such as the minibuffer in `read-from-minibuffer'), > use `emacs-lisp-mode-syntax-table' to determine the symbol boundaries. > > Copyright-paperwork-exempt: yes > --- > lisp/progmodes/elisp-mode.el | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el > index f39ecf9b7b..65c01b2ce1 100644 > --- a/lisp/progmodes/elisp-mode.el > +++ b/lisp/progmodes/elisp-mode.el > @@ -1615,10 +1615,11 @@ elisp--beginning-of-sexp > > ;; returns nil unless current word is an interned symbol. > (defun elisp--current-symbol () > - (let ((c (char-after (point)))) > - (and c > - (memq (char-syntax c) '(?w ?_)) > - (intern-soft (current-word))))) > + (with-syntax-table emacs-lisp-mode-syntax-table > + (let ((c (char-after (point)))) > + (and c > + (memq (char-syntax c) '(?w ?_)) > + (intern-soft (current-word)))))) > > (defun elisp-function-argstring (arglist) > "Return ARGLIST as a string enclosed by (). > -- > 2.20.1 > From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 20 12:51:35 2020 Received: (at 41781) by debbugs.gnu.org; 20 Jun 2020 16:51:35 +0000 Received: from localhost ([127.0.0.1]:58664 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jmgiN-0006ZO-2k for submit@debbugs.gnu.org; Sat, 20 Jun 2020 12:51:35 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:47065) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jmgiK-0006ZA-JL for 41781@debbugs.gnu.org; Sat, 20 Jun 2020 12:51:33 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3182244061D; Sat, 20 Jun 2020 12:51:27 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4632C44059F; Sat, 20 Jun 2020 12:51:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1592671881; bh=1jKygRt+r6uOv+zPAyWtARy6Y1r4MzuUBsiXT8h/9Ik=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=jhYibClTnRtXPuWcEWPh83hYFijimnpLgbkp3bYOvQ5w62Cz5C0NAndt4v+qIi4bW n74MeaJMdIUDrhhRYzGYlWbieAGXu2h4u20aLyuYZ5Ho/bas5XF3kkO58/RudOBwcy 11FlnmNwpbASvVCJ+I4Jky0fiTZNLwMRMIYwc1P56kV1qYB/JosfHVkrZikVaoxOcN IJ8qzwQYCGNUX0HArFfqQN7wXQTAgQ4YxYVMCaG9kw9RsqXMikUKx1u6Vrwo/zhLIR ZYKE7NGgPrdTpbe1EcP5ZbSrxYJ3KL8OqHH7fUjcP7krlmpUFQLYSK/h7ZQl/czXuy KFiprk8EHLFDw== Received: from alfajor (unknown [108.175.228.207]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6D04D1203A5; Sat, 20 Jun 2020 12:51:20 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Message-ID: References: <83h7v6w51h.fsf@gnu.org> Date: Sat, 20 Jun 2020 12:51:19 -0400 In-Reply-To: <83h7v6w51h.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 20 Jun 2020 10:49:14 +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.150 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-Debbugs-Envelope-To: 41781 Cc: 41781@debbugs.gnu.org, Daniel Koning 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: -3.3 (---) >> (a) You're typing an elisp expression into `read-from-minibuffer', and >> (b) the function name contains punctuation, such as ! or ?, whose >> character class is "punctuation" and not "symbol" in the standard syntax >> table. When eldoc is activated in the minibuffer and uses the elisp backend because we're reading an elisp expression, then the syntax-table should also be set accordingly, indeed (not only for eldoc but also for forward-sexp, ...). Looks like a bug in the corresponding function (`read-expression` or nearby). >> There are a couple different spots in the code to which you could >> attribute this lapse. For one, the elisp-mode.el function >> `elisp--current-symbol' isn't wrapped in a `with-syntax-table', unlike >> other similar definitions in the same file. I think anyone invoking this >> function could reasonably expect it to observe elisp syntax, so that's >> what my tiny patch addresses. This fixes the Eldoc problem. It's probably OK to do it as in your patch, yes. Switching the syntax-table can mess up `syntax-ppss`, so it's better if we can avoid it, but in this specific case it seems unlikely to lead to a problem. >> But here's another weird thing further down the call stack. >> `read--expression' has a FIXME comment saying to turn on >> `emacs-lisp-mode' in the minibuffer -- which would also set the >> appropriate syntax table -- but it doesn't actually do it. I guess that >> must not work for whatever reason (since it has to have taken longer to >> write the comment than it would have taken to add the code). Should it >> be changed now so that it does set the major mode? I'm probably to blame for the comment. I'm pretty sure just calling the major will break something. I can't offhand tell you what, tho. Writing the comment was faster than trying it out and then seeing how to fix the corresponding problems. >> Is there a problem with specialized major modes in the minibuffer? There's the fact that it's not (never?) used, so it's a big unknown. I think we *should* use major modes in the minibuffer (tho those major modes will probably need to be custom tailored in most cases). Any progress in that direction (e.g. just trying it to and reporting the problems you encounter) will be welcome. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 22 20:09:14 2020 Received: (at 41781) by debbugs.gnu.org; 23 Jun 2020 00:09:15 +0000 Received: from localhost ([127.0.0.1]:34935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnWV0-0006qY-Dw for submit@debbugs.gnu.org; Mon, 22 Jun 2020 20:09:14 -0400 Received: from sender4-of-o56.zoho.com ([136.143.188.56]:21666) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnWUx-0006qP-GS for 41781@debbugs.gnu.org; Mon, 22 Jun 2020 20:09:13 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1592870943; cv=none; d=zohomail.com; s=zohoarc; b=IwEiNcp8Xr/QUgfzQRiywToy7b1ZWvC+/ScZuTbjM7qFDkly3uVaHA0MkTCcIhAkZzKLzRt4HJLsXdJLB62tTv7RJMBmTQ2veIIzPKE6GseUrJn2mAhFyPbP+Cflja2HlX8B5J6g5gv0cO8+n4MQnfuF4VIl4NavOP9LHbVuv78= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1592870943; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=3wvp9xTxht8ax045CBPx6RwDuaNinRRCyr3Q+qJxK7g=; b=Nj/pizLMkCpvvp9qU+yFRAJOUQbZkfJxhG5v21XaIo7e0qcYgkLmwiqwqqIl8CiTNZvbhU55i5J8MuXNOvF85Imjmrhn2HIirijVQr3DRV0CH8GKqnLdJsSkTMNx4gJ2yLT8w7egf3IyA6+Owz4TO0UVHMtWx2zek7CUP7SK9eo= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=dk@danielkoning.com; dmarc=pass header.from= header.from= Received: from cornelius (112.157.239.35.bc.googleusercontent.com [35.239.157.112]) by mx.zohomail.com with SMTPS id 159287093969054.55676420915347; Mon, 22 Jun 2020 17:08:59 -0700 (PDT) From: Daniel Koning To: Stefan Monnier Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer References: <83h7v6w51h.fsf@gnu.org> Date: Mon, 22 Jun 2020 19:08:57 -0500 In-Reply-To: (Stefan Monnier's message of "Sat, 20 Jun 2020 12:51:19 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (darwin) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Zoho-Virus-Status: 1 X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41781 Cc: Eli Zaretskii , 41781@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 (-) --=-=-= Content-Type: text/plain Stefan Monnier writes: > When eldoc is activated in the minibuffer and uses the elisp backend > because we're reading an elisp expression, then the syntax-table should > also be set accordingly, indeed (not only for eldoc but also for > forward-sexp, ...). > > Looks like a bug in the corresponding function (`read-expression` or nearby). OK, I've attached another patch for that function. >>> For one, the elisp-mode.el function `elisp--current-symbol' isn't >>> wrapped in a `with-syntax-table', unlike other similar definitions >>> in the same file. I think anyone invoking this function could >>> reasonably expect it to observe elisp syntax, so that's what my tiny >>> patch addresses. > > It's probably OK to do it as in your patch, yes. > If you change `read--expression', I don't know whether you'll think it makes sense to add the extra overhead to `elisp--current-symbol'. It does have a silent dependency on the syntax table, which is arguably an inherent bug. But it's an internal function which only (right now) gets called in one place. > I'm pretty sure just calling the major will break something. > I can't offhand tell you what, tho. Writing the comment was faster than > trying it out and then seeing how to fix the corresponding problems. I can confirm that it suffers from the fairly significant drawback of not working at all. Since the major replaces the minibuffer-specific keymap, nothing ends up bound to `exit-minibuffer', so you can't even enter an expression (or do anything else, like history paging). You could bind `overriding-local-map' at the top of the function, but with that and the syntax table you're getting close to implementing a de facto new mode inside the de jure old one. At that point it might as well be a real custom major mode, as you suggested. And then there's the possibility that some people's `emacs-lisp-mode-hook' might contain code that assumes it's in a real buffer and misbehaves in the minibuffer. On the other hand, you could do what eshell does for `eshell-command' and turn on its major mode in the minibuffer while selectively binding C-j, C-m, M-p, etc., inside the setup hook. I don't like this design at all: if I were to make changes to my `minibuffer-local-map' bindings, eshell would silently ignore them. Any custom mode for minibuffer input should inherit an existing minibuffer keymap, in my book at least. Daniel --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=0001-lisp-simple.el-read-expression-Set-syntax-table.patch Content-Description: read--expression patch >From 7b3a19b3616b3a1c8dbd26673f2034bc6b19ebed Mon Sep 17 00:00:00 2001 From: Daniel Koning Date: Mon, 22 Jun 2020 19:03:20 -0500 Subject: [PATCH] lisp/simple.el (read--expression): Set syntax table. Use `emacs-lisp-mode-syntax-table' when reading a Lisp expression from the minibuffer. Copyright-paperwork-exempt: yes --- lisp/simple.el | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/lisp/simple.el b/lisp/simple.el index ea16d1400c..8e71432f9c 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -1608,8 +1608,11 @@ read--expression (let ((minibuffer-completing-symbol t)) (minibuffer-with-setup-hook (lambda () - ;; FIXME: call emacs-lisp-mode (see also - ;; `eldoc--eval-expression-setup')? + ;; FIXME: instead of just applying the syntax table, maybe + ;; use a special major mode tailored to reading Lisp + ;; expressions from the minibuffer? (`emacs-lisp-mode' + ;; doesn't preserve the necessary keybindings.) + (set-syntax-table emacs-lisp-mode-syntax-table) (add-hook 'completion-at-point-functions #'elisp-completion-at-point nil t) (run-hooks 'eval-expression-minibuffer-setup-hook)) -- 2.20.1 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 23 00:17:44 2020 Received: (at 41781) by debbugs.gnu.org; 23 Jun 2020 04:17:44 +0000 Received: from localhost ([127.0.0.1]:35236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnaNU-0004QE-4P for submit@debbugs.gnu.org; Tue, 23 Jun 2020 00:17:44 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23838) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnaNQ-0004Px-Dd for 41781@debbugs.gnu.org; Tue, 23 Jun 2020 00:17:42 -0400 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 24EEB1007CA; Tue, 23 Jun 2020 00:17:35 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id A8FEA100363; Tue, 23 Jun 2020 00:17:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1592885848; bh=aonId9ExeRCElGI1vyqkG7oyYc3eQJrSihNBmpM+3QQ=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=OSi/WsAk9UNoITvwcBYAZ05z1jfTwzAH4cAxyqzjKTQHG5e1w8moAQJyfJK1JwyZ5 BxbIKSpQUMwUqc+2KxGQfKcB13B4FtQAu2jUDnAG/3sswNaiWUYxJQ4SIdngBTd+Eg 29RonMywmSjk2eXKvnhRoWbIsuUX7+sZ39RmhI2zvWhsYZlBLvpVr4GM3Ucp9WEuQY MZ08WkCK7XlCAtjRJEHPS50y+YioyhNhkHAyp3Yzb2+dkcnAYA+8c+RJmrkfR5gxel M7YlxYBVpnhb2uF/4UwWKVhUSfTVdjhMYSY+ggQC9YsLAVmstgB8dLuqNfsmLUKAkI Efz3kCAOr2G5Q== Received: from alfajor (unknown [108.175.228.207]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 62BC0120A06; Tue, 23 Jun 2020 00:17:28 -0400 (EDT) From: Stefan Monnier To: Daniel Koning Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Message-ID: References: <83h7v6w51h.fsf@gnu.org> Date: Tue, 23 Jun 2020 00:17:27 -0400 In-Reply-To: (Daniel Koning's message of "Mon, 22 Jun 2020 19:08:57 -0500") 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.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-Debbugs-Envelope-To: 41781 Cc: Eli Zaretskii , 41781@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: -3.3 (---) >> Looks like a bug in the corresponding function (`read-expression` or nearby). > OK, I've attached another patch for that function. Looks good to me, thanks. > If you change `read--expression', I don't know whether you'll think it > makes sense to add the extra overhead to `elisp--current-symbol'. I'm not worried about the overhead, but I don't like the potential syntax-ppss interaction, so if it's not needed, I'd rather not go there. > I can confirm that it suffers from the fairly significant drawback of > not working at all. Since the major replaces the minibuffer-specific > keymap, nothing ends up bound to `exit-minibuffer', so you can't even > enter an expression (or do anything else, like history paging). Fun! Thanks for trying ;-) > You could bind `overriding-local-map' at the top of the function, but > with that and the syntax table you're getting close to implementing > a de facto new mode inside the de jure old one. At that point it might > as well be a real custom major mode, as you suggested. Right. It's probably worth doing something here in the longer run, tho. E.g. the `minibuffer-local-map` and friends should really be major mode maps (and the inheritance between the maps should probably be reflected as inheritance between corresponding modes). Then you'd create an `emacs-lisp-minibuffer-mode` by deriving from some "normal" `minibuffer-local-mode`. > And then there's the possibility that some people's > `emacs-lisp-mode-hook' might contain code that assumes it's in a real > buffer and misbehaves in the minibuffer. Indeed. > On the other hand, you could do what eshell does for `eshell-command' > and turn on its major mode in the minibuffer while selectively binding > C-j, C-m, M-p, etc., inside the setup hook. I don't like this design at > all: if I were to make changes to my `minibuffer-local-map' bindings, > eshell would silently ignore them. Any custom mode for minibuffer input > should inherit an existing minibuffer keymap, in my book at least. Agreed. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 23 09:58:24 2020 Received: (at 41781) by debbugs.gnu.org; 23 Jun 2020 13:58:24 +0000 Received: from localhost ([127.0.0.1]:36891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnjRQ-0002LT-8U for submit@debbugs.gnu.org; Tue, 23 Jun 2020 09:58:24 -0400 Received: from sender4-of-o56.zoho.com ([136.143.188.56]:21664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnjRO-0002LK-Sj for 41781@debbugs.gnu.org; Tue, 23 Jun 2020 09:58:23 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1592920696; cv=none; d=zohomail.com; s=zohoarc; b=NqCEJBYjUaJlO/BjZWFUoIQHSp6z3uTuVJsW7ylBIymD75jI9H8pUPoKrVwMlUlUe3jq33HFnipO53FogbTB14KlAP/6wkQl6u9dcBdhTSqg3X3oKqp7/sDMT1rVuviYRQar1u1DMfpbERHpQJMjkdgIQwRMZdcILIz0P+mMPfw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1592920696; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=QrY6Z4dDRoaY5U30vFbm25Y0vi49B97K6/bZK4duE58=; b=S4HrDKwkmTkfNjbbnxaJnjjcBxPqAtjU9gh9vs92/yA1lcUW9cqpR3efBQUjdqAy//x7B1jT+jiZW+jPis/LbDjKfsYVqpy76VtVu0+ZYzeNWl6RS4fiblMW245644cvWze5z+jxplMx0EX3s+BHVYqaEUhidaZZEoJXqEn+tDQ= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=dk@danielkoning.com; dmarc=pass header.from= header.from= Received: from cornelius (112.157.239.35.bc.googleusercontent.com [35.239.157.112]) by mx.zohomail.com with SMTPS id 1592920693347136.37499441957368; Tue, 23 Jun 2020 06:58:13 -0700 (PDT) From: Daniel Koning To: Stefan Monnier Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer References: <83h7v6w51h.fsf@gnu.org> Date: Tue, 23 Jun 2020 08:58:11 -0500 In-Reply-To: (Stefan Monnier's message of "Tue, 23 Jun 2020 00:17:27 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41781 Cc: Eli Zaretskii , 41781@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 (-) Stefan Monnier writes: > Then you'd create an `emacs-lisp-minibuffer-mode` by deriving from > some "normal" `minibuffer-local-mode`. Do you suppose it might be sensible to rename `minibuffer-inactive-mode' to `minibuffer-local-mode' right away (or `minibuffer-mode', `minibuffer-base-mode', or some such)? While preserving the old name as an alias, of course. Right now, unless overridden by eshell or another package like it, the minibuffer is always in `minibuffer-inactive-mode', and it's kind of confusing that an active minibuffer calls itself inactive when you ask for its major mode. Daniel From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 23 10:09:17 2020 Received: (at 41781) by debbugs.gnu.org; 23 Jun 2020 14:09:17 +0000 Received: from localhost ([127.0.0.1]:36919 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnjbw-0004kn-LV for submit@debbugs.gnu.org; Tue, 23 Jun 2020 10:09:16 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnjbu-0004kY-Qm for 41781@debbugs.gnu.org; Tue, 23 Jun 2020 10:09:15 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3BFA280AB3; Tue, 23 Jun 2020 10:09:09 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 639AE805BA; Tue, 23 Jun 2020 10:09:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1592921347; bh=FReRrCLoyo1y6/318cYjg1Nf9UfAa4yhGpGYJjxQAlc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=fVgcVDDLyTc0tJIVy4OLtHwjIkvcP0Ej6KmJrqRNSj3GS2XYGn91X3YM1rOkO1ZMC ls2NDI9kxHzr/g0+fZD6qnS5GLTBM6BRctPAidlvAnL10mVA4BkO4uZjaplZTULZ+w V8T9RWfuVeVRC/vJcMMWUmcse9zU9y+t4KFbxQUes2TvRzil2tmNzTB/dsJ6MEPE/K 83U52kbjZaNkpgZ+YaCD+UOZ6HiNKToZ0qR7oosXtKKKN8UYx2BITK2QXTSBBGLOLK 2gegsGCWvau5hhTvXYNsqEx27CPGaHfaPWLmPSMigs3YFe8bafkH844BVPyU3lRYKD cP/K3J92kgrww== Received: from alfajor (unknown [108.175.228.207]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 146C0120302; Tue, 23 Jun 2020 10:09:07 -0400 (EDT) From: Stefan Monnier To: Daniel Koning Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Message-ID: References: <83h7v6w51h.fsf@gnu.org> Date: Tue, 23 Jun 2020 10:09:05 -0400 In-Reply-To: (Daniel Koning's message of "Tue, 23 Jun 2020 08:58:11 -0500") 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.075 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-Debbugs-Envelope-To: 41781 Cc: Eli Zaretskii , 41781@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: -3.3 (---) >> Then you'd create an `emacs-lisp-minibuffer-mode` by deriving from >> some "normal" `minibuffer-local-mode`. > Do you suppose it might be sensible to rename > `minibuffer-inactive-mode' to `minibuffer-local-mode' right away (or > `minibuffer-mode', `minibuffer-base-mode', or some such)? No, the `minibuffer-inactive-mode` is the mode used when *not* in the minibuffer. Its main purpose is to install a special keymap (which can basically only be really used when you have a separate minibuffer frame). > Right now, unless overridden by eshell or another package like it, the > minibuffer is always in `minibuffer-inactive-mode', I don't think that's true in the sense of "you get the behavior of minibuffer-inactive-mode" (most importantly you don't get its keymap). It may be true in the sense of "that's what `major-mode` says", but that's rather irrelevant. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 23 12:42:57 2020 Received: (at 41781) by debbugs.gnu.org; 23 Jun 2020 16:42:57 +0000 Received: from localhost ([127.0.0.1]:37031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnm0f-0002A4-0M for submit@debbugs.gnu.org; Tue, 23 Jun 2020 12:42:57 -0400 Received: from sender4-of-o56.zoho.com ([136.143.188.56]:21655) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnm0a-00029u-TW for 41781@debbugs.gnu.org; Tue, 23 Jun 2020 12:42:55 -0400 ARC-Seal: i=1; a=rsa-sha256; t=1592930566; cv=none; d=zohomail.com; s=zohoarc; b=mqkj3PvpynDVeDcs8+TIGROLpiuYLzfMTRdLHUmEEnglTN/g500LC3XkWu9PDx1CnddW+l7IkKnPNuSSf/QcmPRQIfy5y4i6g7AryVxjVeSNhxfa7iCZ+jDsAhWCridc61ZRPSHCshii4hQ2U2if42XvMKFZS1GYwvqq+dqHR6U= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1592930566; h=Content-Type:Content-Transfer-Encoding:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=f9+y9J2Zlh09dfp9pBG7WPARrqJlsoir5iHP1kTuKJc=; b=hUEr/c9wXwnEMSDK0pg8IaO+GYEoh0kY+ngU7N/zRXh9MEVxxpW+wff7g3c9a9nwtHyCZK0qnTjAANQNRrLKRHgTupqnJiIe7ijGu6/5rD5RV4PM8lpZ+RGJOtqXAeu6ebPunvIFxN/hOHoSMYWn/CZw84c1i/4puU6RaPe7780= ARC-Authentication-Results: i=1; mx.zohomail.com; spf=pass smtp.mailfrom=dk@danielkoning.com; dmarc=pass header.from= header.from= Received: from cornelius (112.157.239.35.bc.googleusercontent.com [35.239.157.112]) by mx.zohomail.com with SMTPS id 1592930563198738.6216582644768; Tue, 23 Jun 2020 09:42:43 -0700 (PDT) From: Daniel Koning To: Stefan Monnier Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer In-Reply-To: (Stefan Monnier's message of "Tue, 23 Jun 2020 10:09:05 -0400") References: <83h7v6w51h.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.91 (darwin) Date: Tue, 23 Jun 2020 11:42:39 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-ZohoMailClient: External X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41781 Cc: Eli Zaretskii , 41781@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 (-) Stefan Monnier writes: >> Right now, unless overridden by eshell or another package like it, the >> minibuffer is always in `minibuffer-inactive-mode', > > I don't think that's true in the sense of "you get the behavior of > minibuffer-inactive-mode" (most importantly you don't get its keymap). > It may be true in the sense of "that's what `major-mode` says", but > that's rather irrelevant. I see your point, but I doubt most users and elisp writers would agree that it's irrelevant what the value of `major-mode' says in plain English. We should be able to count on drawing some conclusions from it. Generally, the use of one major for two very different keymaps and program states (while circumventing the problems by changing things =C3=A0 = la carte) strikes me as a pattern worth deprecating. But I think we agree on that. Daniel From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 23 14:37:46 2020 Received: (at 41781) by debbugs.gnu.org; 23 Jun 2020 18:37:47 +0000 Received: from localhost ([127.0.0.1]:37098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnnnm-00055o-MM for submit@debbugs.gnu.org; Tue, 23 Jun 2020 14:37:46 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:36791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jnnnh-00055Q-RV for 41781@debbugs.gnu.org; Tue, 23 Jun 2020 14:37:45 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5B18C81281; Tue, 23 Jun 2020 14:37:36 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8FA2280245; Tue, 23 Jun 2020 14:37:34 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1592937454; bh=nN4SPBIZZUtCz3E0tL6XZSsJB+MPvTDnyY5570iE95s=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=mvfXGatWYxyfr80ftpArpmSpYbXkCVH/Fvb+CmHXyFZnfFo/KL7c7gPeiOmZFCg6R pXajVCMm1Eeit4/sYNFarLg709BG/HDIp5GAf3U7KdmIVV8ICpWgFUV2rY3GJA9VBc Qdp6L8CybLLNo8iktz2MuSGzJFG7qmqFwDhvL5sP07jVtTTYlhw2/VO8WXeyduFwM1 r8lpXy2/sZKlVr18XEx5LxB6+HYEAXCPJkhcQjWOeR51cnJ8FyRRaQJ7ltxtiKxT2c ciGIKUFbUq4ZaaOBmTfL4IGyWEr2RSGDBayEr888b7RxIW/oQHRC/nqcxfuILR5lAY BLgZU/ztVv5hQ== Received: from alfajor (unknown [108.175.228.207]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E964512084F; Tue, 23 Jun 2020 14:37:33 -0400 (EDT) From: Stefan Monnier To: Daniel Koning Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Message-ID: References: <83h7v6w51h.fsf@gnu.org> Date: Tue, 23 Jun 2020 14:37:32 -0400 In-Reply-To: (Daniel Koning's message of "Tue, 23 Jun 2020 11:42:39 -0500") 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.083 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-Debbugs-Envelope-To: 41781 Cc: Eli Zaretskii , 41781@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: -3.3 (---) > I see your point, but I doubt most users and elisp writers would agree > that it's irrelevant what the value of `major-mode' says in plain > English. We should be able to count on drawing some conclusions from it. What I meant is that the value of `major-mode` you see is just an accident because the minibuffer-setup code doesn't bother to really set a new major mode (or call kill-all-local-variables), so you get a stale value in the `major-mode` variable. Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 04 03:57:57 2020 Received: (at 41781) by debbugs.gnu.org; 4 Jul 2020 07:57:57 +0000 Received: from localhost ([127.0.0.1]:57992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrd3d-00019f-8W for submit@debbugs.gnu.org; Sat, 04 Jul 2020 03:57:57 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33840) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jrd3a-00019R-92 for 41781@debbugs.gnu.org; Sat, 04 Jul 2020 03:57:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59705) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jrd3U-00022W-Hr; Sat, 04 Jul 2020 03:57:48 -0400 Received: from [176.228.60.248] (port=2403 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jrd3S-00064U-Cn; Sat, 04 Jul 2020 03:57:47 -0400 Date: Sat, 04 Jul 2020 10:57:48 +0300 Message-Id: <83h7unvhj7.fsf@gnu.org> From: Eli Zaretskii To: Daniel Koning In-Reply-To: (message from Daniel Koning on Mon, 22 Jun 2020 19:08:57 -0500) Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer References: <83h7v6w51h.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41781 Cc: monnier@iro.umontreal.ca, 41781@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: -3.3 (---) > From: Daniel Koning > Cc: Eli Zaretskii , 41781@debbugs.gnu.org > Date: Mon, 22 Jun 2020 19:08:57 -0500 > > OK, I've attached another patch for that function. Thanks, I installed this on the master branch. From debbugs-submit-bounces@debbugs.gnu.org Wed Aug 05 11:59:50 2020 Received: (at 41781) by debbugs.gnu.org; 5 Aug 2020 15:59:50 +0000 Received: from localhost ([127.0.0.1]:52057 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k3LpW-0003nD-9p for submit@debbugs.gnu.org; Wed, 05 Aug 2020 11:59:50 -0400 Received: from quimby.gnus.org ([95.216.78.240]:43156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k3LpU-0003my-Df for 41781@debbugs.gnu.org; Wed, 05 Aug 2020 11:59:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=x6SXr3kKYVbNjDEtM9N/DhnwVXXCIX/4n3JuvPn4+9g=; b=O642t8+u9vJ1XreR5xKTaOZNrJ /qOJDQlLIozWBdyquh/aFfEpCrD4DgqIgBM1bQqca/exqbxC5t8DDByzlzj8vh6yADUw9IdIqUqtt 9jSZycpzoyA69bnbv23NuRGBz4OwaHTRu2npq4fturcJWJmU468dt9DO0lt+ykbOyO1Y=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k3LpB-0006OJ-Jl; Wed, 05 Aug 2020 17:59:35 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer References: <83h7v6w51h.fsf@gnu.org> <83h7unvhj7.fsf@gnu.org> Date: Wed, 05 Aug 2020 17:59:28 +0200 In-Reply-To: <83h7unvhj7.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Jul 2020 10:57:48 +0300") Message-ID: <878setjd7j.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.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 @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> From: Daniel Koning >> Cc: Eli Zaretskii , 41781@debbugs.gnu.org >> Date: Mon, 22 Jun 2020 19:08:57 -0500 >> >> OK, I've attached another patch for that function [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 41781 Cc: 41781@debbugs.gnu.org, monnier@iro.umontreal.ca, Daniel Koning 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 (-) Eli Zaretskii writes: >> From: Daniel Koning >> Cc: Eli Zaretskii , 41781@debbugs.gnu.org >> Date: Mon, 22 Jun 2020 19:08:57 -0500 >> >> OK, I've attached another patch for that function. > > Thanks, I installed this on the master branch. I've only skimmed this thread, but it seems like the patch that was installed fixed the problem that was being discussed? It's a bit unclear... So should this bug report be closed? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Sat Aug 08 04:10:10 2020 Received: (at 41781-done) by debbugs.gnu.org; 8 Aug 2020 08:10:10 +0000 Received: from localhost ([127.0.0.1]:58009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4Jve-0007Ki-Gq for submit@debbugs.gnu.org; Sat, 08 Aug 2020 04:10:10 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33820) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k4Jvc-0007KR-Rp for 41781-done@debbugs.gnu.org; Sat, 08 Aug 2020 04:10:09 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43564) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k4JvW-0001u4-MS; Sat, 08 Aug 2020 04:10:02 -0400 Received: from [176.228.60.248] (port=1817 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1k4JvV-0004Dk-Hi; Sat, 08 Aug 2020 04:10:02 -0400 Date: Sat, 08 Aug 2020 11:09:58 +0300 Message-Id: <83a6z57e3t.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <878setjd7j.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 05 Aug 2020 17:59:28 +0200) Subject: Re: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer References: <83h7v6w51h.fsf@gnu.org> <83h7unvhj7.fsf@gnu.org> <878setjd7j.fsf@gnus.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 41781-done Cc: 41781-done@debbugs.gnu.org, monnier@iro.umontreal.ca, dk@danielkoning.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: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Daniel Koning , monnier@iro.umontreal.ca, > 41781@debbugs.gnu.org > Date: Wed, 05 Aug 2020 17:59:28 +0200 > > Eli Zaretskii writes: > > >> From: Daniel Koning > >> Cc: Eli Zaretskii , 41781@debbugs.gnu.org > >> Date: Mon, 22 Jun 2020 19:08:57 -0500 > >> > >> OK, I've attached another patch for that function. > > > > Thanks, I installed this on the master branch. > > I've only skimmed this thread, but it seems like the patch that was > installed fixed the problem that was being discussed? It's a bit > unclear... > > So should this bug report be closed? I think it should be closed, indeed, so I have now done so. Thanks. From unknown Sat Jun 21 10:43:59 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 05 Sep 2020 11:24:06 +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