From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#41781: 27.0.91; [PATCH] Eldoc describes the wrong function when reading an expression from the minibuffer Date: Sat, 20 Jun 2020 12:51:19 -0400 Message-ID: References: <83h7v6w51h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="130773"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Daniel Koning , 41781@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 20 18:52:14 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jmgiz-000Xvz-ME for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 20 Jun 2020 18:52:13 +0200 Original-Received: from localhost ([::1]:50232 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jmgiy-00026V-NJ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 20 Jun 2020 12:52:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47404) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jmgio-00025f-BU for bug-gnu-emacs@gnu.org; Sat, 20 Jun 2020 12:52:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47118) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jmgio-00088h-2e for bug-gnu-emacs@gnu.org; Sat, 20 Jun 2020 12:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jmgin-0006a8-Vy for bug-gnu-emacs@gnu.org; Sat, 20 Jun 2020 12:52:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 20 Jun 2020 16:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 41781 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 41781-submit@debbugs.gnu.org id=B41781.159267189525262 (code B ref 41781); Sat, 20 Jun 2020 16:52:01 +0000 Original-Received: (at 41781) by debbugs.gnu.org; 20 Jun 2020 16:51:35 +0000 Original-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 Original-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 Original-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) Original-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== Original-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) In-Reply-To: <83h7v6w51h.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 20 Jun 2020 10:49:14 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:182211 Archived-At: >> (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