From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Allen Li Newsgroups: gmane.emacs.bugs Subject: bug#49629: 27.2; electric-pair-mode doesn't work for angle brackets in HTML file Date: Sun, 26 Jun 2022 17:33:37 -0700 Message-ID: References: <801r7vgoxm.fsf@felesatra.moe> <87im11gbxf.fsf_-_@gnus.org> <8735rybg2f.fsf@gnus.org> <87tuk978gm.fsf@gnus.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d04b9805e26312d2" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23027"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , 49629@debbugs.gnu.org, Noam Postavsky To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jun 27 02:34:34 2022 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 1o5ci1-0005kk-Vc for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Jun 2022 02:34:34 +0200 Original-Received: from localhost ([::1]:33860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o5ci0-0001no-Eb for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 26 Jun 2022 20:34:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44602) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o5chW-0001nL-8c for bug-gnu-emacs@gnu.org; Sun, 26 Jun 2022 20:34:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55417) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o5chV-0002sD-Vf for bug-gnu-emacs@gnu.org; Sun, 26 Jun 2022 20:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1o5chV-0002TR-Rx for bug-gnu-emacs@gnu.org; Sun, 26 Jun 2022 20:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Allen Li Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Jun 2022 00:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49629 X-GNU-PR-Package: emacs Original-Received: via spool by 49629-submit@debbugs.gnu.org id=B49629.16562900389500 (code B ref 49629); Mon, 27 Jun 2022 00:34:01 +0000 Original-Received: (at 49629) by debbugs.gnu.org; 27 Jun 2022 00:33:58 +0000 Original-Received: from localhost ([127.0.0.1]:49314 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5chS-0002T9-Cw for submit@debbugs.gnu.org; Sun, 26 Jun 2022 20:33:58 -0400 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:37565) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1o5chO-0002Su-Mx for 49629@debbugs.gnu.org; Sun, 26 Jun 2022 20:33:57 -0400 Original-Received: by mail-ed1-f49.google.com with SMTP id c65so10831197edf.4 for <49629@debbugs.gnu.org>; Sun, 26 Jun 2022 17:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=felesatra-moe.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jbbHhY7ggAmp2LuwABj7Yb1d0V2H+4fAUL3p/XpcBBg=; b=Pf1dnKPeVSBf0hgmK0vil17BIXnzh3CgD+TdjgzjKR2ARklnY6F+CGquJvPh9BJZ2h KsOWsFshmj2zzfYvTwCsK7j37bBjusUqS/S54q9kbCjcu5i9zPBIe0ZxO2RbPI93SfR3 2lKnrQ5z60cmIRkOkFUSRbVx7QYDs4zDeiLv5VZ82/4BqMZuFJ6RFtlcgPHkObzJr+Zt LawWDClrGbMOjx7KhsiyJkhrsQDne5d7JA180F4Mw3tiM3qlpB/vr0/0C+U0f9ok/Wwn uGzZJHRBrnZlG+lrXEIaEeGdTCBIZYb2OQVUN5UH9llyUXrbxDWP4757hSYzJRqKfkCz A/Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jbbHhY7ggAmp2LuwABj7Yb1d0V2H+4fAUL3p/XpcBBg=; b=o/TpY5l7gNAUM1NwOBm10IKhGaHWGMLhf+S8D07nUyeg3H9GOtDaCIpXS6gpY2WIEd 6PiYSJ8rtChuc6A+SlzAJSPvxOhF7WALgR65z3gjbUwHe1Yl356a9IKL6HKzIq1tD2el 554BPVCZA5D4KVa9HB7y7T6RW1Vldb6zg/be+yZjF3XpBxlZfNC54M/7FQD/t2R0lqgy yW63X06ZBvgqu4NVJsPMvwvONN4Ogdqt7oKCPN8uhoZMXUciEdHLC7sbRocoCZWXNNq2 nk2/Gab+CJNZq/xy1/7jeXQ1KtuFXXly21SCN/uNxfNUKXCuUHeVnQIjpsKqbMfbZjiF DR1g== X-Gm-Message-State: AJIora/EFt3mzXwqwcmTLUiChBnympgpK+YygE1Cu3dUk5B1FujUeV/s EbEzvpuahVAF/oKzQW5Qd9tmGx1jNpBgwcDoAtXu4A== X-Google-Smtp-Source: AGRyM1toHpAwhNoKiEaspTY6yRes4eC2MBpgJTONOaEMAouEt2H3fKDuQGCH05t1Ap+WwqQrrfeQjLqn57O8LOm9rRQ= X-Received: by 2002:a05:6402:22a1:b0:437:78c2:d02b with SMTP id cx1-20020a05640222a100b0043778c2d02bmr9555269edb.64.1656290028828; Sun, 26 Jun 2022 17:33:48 -0700 (PDT) In-Reply-To: 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:235405 Archived-At: --000000000000d04b9805e26312d2 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 26, 2022 at 5:17 AM Stefan Monnier wrote: > > I *think* I've fixed this, but it's complicated. Also I could be > > completely wrong. For what it's worth, I can reproduce the bug without > the > > patch and cannot with the patch, which see attached. > > AFAICT you've indeed found the origin of the problem. > > > If this sounds sensible, then a slightly different patch is needed, > because > > `electric-pair--with-uncached-syntax` is used in some contexts where > hiding > > `syntax-propertize-function` is the correct behavior. > > I think the code deserves a comment when/where it overrides > `syntax-propertize-function` to explain why it's needed. > AFAICT it was introduced in commit > 89cfdbf729bc731331358e0efc69547547aa3ca2 but that commit doesn't explain > why it bound it to nil (which I later changed to `ignore`). > > Furthermore, the cache could be filled with entries before `start` while > the syntax-table (and/or `syntax-propertize-function`) is temporarily > changed, so the flush doesn't seem sufficient. [ It's unlikely, because > usually the cache will have been pre-filled via font-lock and friends, > but it can still occur in corner cases. ] > > IIUC we use `with-syntax-table` there specifically when we want to > provide text-mode style paren matching within comments and strings. > Maybe a good way to avoid problem with syntax-ppss/properties is to > narrow the buffer to the comment/string at the same time as we > `with-syntax-table` and let-bind `syntax-propertize-function`. > Thanks. Two observations: FIrst, changing `syntax-propertize-function` from nil to `ignore` was wrong IIUC. If the function is set, then it is wholly responsible for applying syntax table. When set to nil the default behavior is used, but when set to `ignore`, that should mean that no syntax is applied at all. In practice, I don't know what behavior that causes. Second, since `electric-pair--with-uncached-syntax` appears to be used for doing text-mode matching (as you've also observed), maybe we should de-generalize it to do only that. I think that allows us to make some simplifying assumptions about the state of the world. > > > Stefan > > --000000000000d04b9805e26312d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 26, 2022 at 5:17 AM Stefan Mo= nnier <monnier@iro.umontreal= .ca> wrote:
> I *think* I've fixed this, but it= 9;s complicated.=C2=A0 Also I could be
> completely wrong.=C2=A0 For what it's worth, I can reproduce the b= ug without the
> patch and cannot with the patch, which see attached.

AFAICT you've indeed found the origin of the problem.

> If this sounds sensible, then a slightly different patch is needed, be= cause
> `electric-pair--with-uncached-syntax` is used in some contexts where h= iding
> `syntax-propertize-function` is the correct behavior.

I think the code deserves a comment when/where it overrides
`syntax-propertize-function` to explain why it's needed.
AFAICT it was introduced in commit
89cfdbf729bc731331358e0efc69547547aa3ca2 but that commit doesn't explai= n
why it bound it to nil (which I later changed to `ignore`).

Furthermore, the cache could be filled with entries before `start` while the syntax-table=C2=A0 (and/or `syntax-propertize-function`) is temporarily=
changed, so the flush doesn't seem sufficient.=C2=A0 [ It's unlikel= y, because
usually the cache will have been pre-filled via font-lock and friends,
but it can still occur in corner cases.=C2=A0 ]

IIUC we use `with-syntax-table` there specifically when we want to
provide text-mode style paren matching within comments and strings.
Maybe a good way to avoid problem with syntax-ppss/properties is to
narrow the buffer to the comment/string at the same time as we
`with-syntax-table` and let-bind `syntax-propertize-function`.

Thanks.=C2=A0 Two observations:

FIrst, changing `syntax-propertize-function` from nil to `ignore` was= wrong IIUC.=C2=A0 If the function is set, then it is wholly responsible fo= r applying syntax table.=C2=A0 When set to nil the default behavior is used= , but when set to `ignore`, that should mean that no syntax is applied at a= ll.=C2=A0 In practice, I don't know what behavior that causes.
=C2=A0
Second, since `electric-pair--with-uncached-syntax` appe= ars to be used for doing text-mode matching (as you've also observed), = maybe we should de-generalize it to do only that.=C2=A0 I think that allows= us to make some simplifying assumptions about the state of the world.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--000000000000d04b9805e26312d2--