From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dale Sedivec Newsgroups: gmane.emacs.bugs Subject: bug#44653: 28.0.50; sql-mode gets confused about string literals Date: Wed, 27 Jan 2021 12:09:52 -0600 Message-ID: <46E97503-64A9-4B54-ADA7-C71F7F39FB5B@codefu.org> References: <04127C97-3437-4A95-9640-92347FB62FE4@codefu.org> <87o8hbc9qu.fsf@gnus.org> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33613"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44653@debbugs.gnu.org, Stefan Monnier To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 27 19:11:12 2021 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 1l4pHb-0008ar-OO for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Jan 2021 19:11:12 +0100 Original-Received: from localhost ([::1]:46548 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l4pHa-0001ZX-Oz for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 27 Jan 2021 13:11:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l4pHS-0001YL-9X for bug-gnu-emacs@gnu.org; Wed, 27 Jan 2021 13:11:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34520) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l4pHS-00047K-1T for bug-gnu-emacs@gnu.org; Wed, 27 Jan 2021 13:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l4pHR-0005Jo-Rf for bug-gnu-emacs@gnu.org; Wed, 27 Jan 2021 13:11:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dale Sedivec Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Jan 2021 18:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44653 X-GNU-PR-Package: emacs Original-Received: via spool by 44653-submit@debbugs.gnu.org id=B44653.161177100620364 (code B ref 44653); Wed, 27 Jan 2021 18:11:01 +0000 Original-Received: (at 44653) by debbugs.gnu.org; 27 Jan 2021 18:10:06 +0000 Original-Received: from localhost ([127.0.0.1]:46063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l4pGY-0005IN-9V for submit@debbugs.gnu.org; Wed, 27 Jan 2021 13:10:06 -0500 Original-Received: from mail-io1-f51.google.com ([209.85.166.51]:34392) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l4pGS-0005Hj-Eh for 44653@debbugs.gnu.org; Wed, 27 Jan 2021 13:10:05 -0500 Original-Received: by mail-io1-f51.google.com with SMTP id u17so2827870iow.1 for <44653@debbugs.gnu.org>; Wed, 27 Jan 2021 10:10:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codefu-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I3blo+BhhIQNm0jvVPQ3yDXiDaTSFFZI1CM6YF5qlAM=; b=rP8WxR9dM1z9ipDoY3w5i5y+QExLPIbLbL6eeGyeEAEsQUpOkEJBKWSRfa9ktq7/7J d9LB4z4zMnUILPGyBnNgl+asppZUHb81cI/GDDF0O/RhnRRVFznxTjN1FbcsjHbHPG0m Ox2zM5wijjKqtSgDdrsNMndCKIhqn8wP83DGvvqc/TPikNNaUwlEd5sysSFoStBCwIwk R/9cM/GDuvX5taYFxIeads5WXRT7Gg2Xj4UboFBxBnGGwb4DhALRSH4dMJfXpvHUJg+M i8aZg/UkaWcvb1ZFkXJMShnL6ewIkhB98HfgTXTM1YzjSei3TgnuxZGaQzfFHsLpLge0 Ab5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I3blo+BhhIQNm0jvVPQ3yDXiDaTSFFZI1CM6YF5qlAM=; b=cNsOZBVA0LHzgLeT9GXmKteaiDSGwMzLFXCNvtT2exOXs/HbW2IH6SYKUtYV5zixzK ORW8sU2Q6Z3u+DDxfA8Q3nXZhFkhWVpyE1o39eDMbutKxt5ia+UmvNvbElQKvL6kwvgJ zhQPwN1u7w8OZo3tBNwGK33EC26PRWi6sTmtaqLYt4LL+dVE8gI2678VWfvidVbU75sW sHUnQ9f4elBY4SxdELUunp2bMD/h5fUip9wwRcSbzvuW+Jzhxs+xFVZMZ3pxJ+EoEV3p jBoIIEEC2YsxE8+oDaCQCoXHnaq/eMkk4iR4rAlpuvajmXza3fJcsLl9bMe62mjM5umf ydhw== X-Gm-Message-State: AOAM5321RqiJsNvKcrf/0LOhQJZHT92jTlhPKLfQdgXAZGSsL1JDx8Ft UtI8sdZnSy4qGp2hSRtxASOLpQ== X-Google-Smtp-Source: ABdhPJxUjDO58JKdUaNpFw1Pbe/5brXkOij3/yriXB2WvcarlwhSY/h7ieJlw8kt3Zr6zmgcOBz68Q== X-Received: by 2002:a6b:681a:: with SMTP id d26mr8356485ioc.144.1611770994590; Wed, 27 Jan 2021 10:09:54 -0800 (PST) Original-Received: from dale.caliginous.net (152.160.30.136.in-addr.arpa. [136.30.160.152]) by smtp.gmail.com with ESMTPSA id l7sm1355790iln.74.2021.01.27.10.09.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jan 2021 10:09:54 -0800 (PST) In-Reply-To: <87o8hbc9qu.fsf@gnus.org> X-Mailer: Apple Mail (2.3445.104.17) 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:198710 Archived-At: On Jan 26, 2021, at 21:57, Lars Ingebrigtsen wrote: > Dale Sedivec writes: >=20 >> I think `syntax-ppss' has started returning incorrect information = about >> apostrophe-delimited strings in sql-mode in master. [...] >>=20 >> Steps to reproduce: >>=20 >> 1. emacs -Q >>=20 >> 2. Evaluate the following in *scratch*: >>=20 >> (let ((buf (generate-new-buffer "sql"))) >> (switch-to-buffer buf) >> (sql-mode) >> (insert "select '''") >> (goto-char 1) >> (delete-region 1 8) >> (goto-char (point-max))) >>=20 >> Point should now be at the end of an `sql-mode' buffer containing >> "'''" (three apostrophes). >>=20 >> 4. Press backspace to erase the third apostrophe. >>=20 >> 5. M-: (nth 3 (syntax-ppss)) RET >>=20 >> Expected result: fourth element of syntax-ppss, the delimiter = character >> for the current string, is nil, since we are no longer in a string >>=20 >> Observed result: fourth element is ?' (39), indicating that point is >> still inside a string >=20 > I can reproduce this behaviour... but if I then type, say, "a DEL", > then (nth 3 (syntax-ppss)) returns nil. >=20 > So it seems like syntax-ppss doesn't recompute the status until a new > character is inserted... which I think makes sense? Until you've = typed > something more, Emacs doesn't really know whether we've entered a new > syntax state or not here. Thanks for looking at this. Do I correctly understand your statement to mean that parse state is = only updated when characters are added to a buffer, not when characters = are deleted? If so, that would indeed seem to mean that this is not a = bug. I tested something similar in a python-mode buffer, and indeed = syntax-ppss still thinks it's in a string when I delete an apostrophe, = just as in the above example. It's possible I just missed that = explanation in the manual. If things are working as expected, please feel free to close this. It's = probably inconvenient that syntax parsing can't be relied upon after = deleting characters, but I can imagine that changing this is not simple. > (I'm also wondering what the actual bug you're experiencing is, since > I', guessing you don't go typing M-: (nth 3 (syntax-ppss)) RET at = random > just for fun. :-)) [...] While acknowledging that I sometimes forget the names of my family = members: I *think* I was trying to change how apostrophe (') behaves in = sql-mode buffers with electric-pair-mode turned on. In case it helps, = or you're just curious, specifics follow. #40231 (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D40231) made a = change to the syntax of apostrophe in an SQL string, which made = electric-pair-mode behave in a way I did not appreciate. While writing = code to make ' behave in the way I expected, I ran into difficulties due = to the behavior of syntax-ppss I described in my original message. To demonstrate what I was trying to change: 1. Create an sql-mode buffer with electric-pair-mode turned on 2. Type ', which results in '|' with point at | 3. Type ' again Desired behavior, and pre-40231's patch behavior (IIRC): ''| with point = at | Post-40231 behavior: ''|' I wanted the pre-40231 behavior. Here's what I'm currently using to achieve the pre-40231 behavior (it = ain't pretty and I'm struggling to remember why the third cond clause is = there): ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D40231 ;; ;; In addition to test case in comment below, also try '''''' at BOB ;; and try inserting ' at BOB with '' in front of point. Also make ;; sure apostrophes don't pair in comments. (defun my:sql-mode-electric-apostrophe (arg) (interactive "P") (cond ((or (not electric-pair-mode) arg) (call-interactively #'self-insert-command)) ((and (eq (char-after) ?') (eq (nth 3 (syntax-ppss)) ?')) ;; We were already at a string, and the character after point is ;; an apostrophe. Just move beyond it. (Behavior changed after ;; changes from Emacs bug #40231.) (forward-char 1)) ;; XXX I have no idea if any of this makes sense if/when ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D44653 gets fixed. ;; Check back then. I think `self-insert-command' should be ;; sufficient, but ISTR I had to avoid using it in this case ;; because elec-pair was confounding me? I don't quite remember. ((and (eq (char-before) ?') (not (nth 3 (progn ;; (syntax-ppss-flush-cache (- (point) 2)) (syntax-ppss))))) ;; (self-insert-command 1) (insert "'") (save-excursion (electric-pair--insert ?'))) (t (self-insert-command 1)))) (with-eval-after-load 'sql (define-key sql-mode-map "'" #'my:sql-mode-electric-apostrophe)) Dale=