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, 1 Aug 2021 05:06:35 +0000 Message-ID: References: <801r7vgoxm.fsf@felesatra.moe> <87im11gbxf.fsf_-_@gnus.org> <8735rybg2f.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27231"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 49629@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 01 07:07:13 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 1mA3gu-0006uv-8L for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Aug 2021 07:07:12 +0200 Original-Received: from localhost ([::1]:46542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mA3gs-0002Uh-Qt for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 01 Aug 2021 01:07:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44820) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mA3gk-0002UI-Mf for bug-gnu-emacs@gnu.org; Sun, 01 Aug 2021 01:07:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52022) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mA3gk-0008Q3-FY for bug-gnu-emacs@gnu.org; Sun, 01 Aug 2021 01:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mA3gj-0006Hi-Ut for bug-gnu-emacs@gnu.org; Sun, 01 Aug 2021 01:07: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: Sun, 01 Aug 2021 05:07: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.162779441524121 (code B ref 49629); Sun, 01 Aug 2021 05:07:01 +0000 Original-Received: (at 49629) by debbugs.gnu.org; 1 Aug 2021 05:06:55 +0000 Original-Received: from localhost ([127.0.0.1]:35335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mA3gc-0006Gz-So for submit@debbugs.gnu.org; Sun, 01 Aug 2021 01:06:55 -0400 Original-Received: from mail-oi1-f171.google.com ([209.85.167.171]:34674) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mA3ga-0006Gk-3X for 49629@debbugs.gnu.org; Sun, 01 Aug 2021 01:06:53 -0400 Original-Received: by mail-oi1-f171.google.com with SMTP id t128so19957229oig.1 for <49629@debbugs.gnu.org>; Sat, 31 Jul 2021 22:06:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=felesatra-moe.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iPBcsuJ4mA3Wwh4s1MBX4/Tm2e0FOaVdajKaWWneWP8=; b=KVlZpPABN/xaZ0ycpUgRSWsJbf6XfyTli3Q2/oU9GnvYMekd3cfL4uNdj5IaVJbm+A XMcGwQ+3GMrcCon+SlRF9Xg/wV5W4SBmD8i19ivtNmFXMQoZByD6YpiEcVxfy4TjsbgS +lsDRvDHWjNFMpX7nGwBjAsc/UY5V7bqCs66Uzz4zqlLsxU/VWTb4D0OyhMFMhdHB1HS dcTvUEr49YWvfwyEnP4DTZN6gW7rhdOIXPWAZ0IexHpnSK90RndMT18Nym4Z4wyQ1Gk3 4uexjW4YtyjJlKa0tvE1cQrKbzeqRNVcB1pIHHlhseTCSVeFjR+IM+/QN+l9CAQ0ihCd Ru5Q== 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=iPBcsuJ4mA3Wwh4s1MBX4/Tm2e0FOaVdajKaWWneWP8=; b=QMkdn4Ic0tN2pQegVwa3V2tXHEWDEraI944aMXdK2oGzzYmd6HBeUdOe05zAWA+jU3 atRTWuGDhWGynUQpt0Vh9bbpU7Qck99bzGpP19q/Axb9KUtdlJQo0tr+gaPgupWI6zST ZrU8NRbVM2r4VbiZtBu/WCSdzKBkj/gKFk+4sgXmDc+ELtVgM7JYvsyN8zlxxKV/ANm2 NBGJUlr6yoDzaQ43i1k+AmOv9bd4sIYP9pnDdgqtJoN3llp9S0XIEQoPZXShHB6KbFQy tDbL4oN8k6lV/4lsgA7d/4iBuT7Jt1jFPnouLEtFK1NG0J4uoR/beaK+/iMnQ1zzpVE8 9hYg== X-Gm-Message-State: AOAM530TUFyk8i5BxLYAmJpwf2QldYsXmhMO8sd0z+F537Prb+qbZbA/ ddH7Iqdr70Y8TD2AwXXf9RJBT6SW1Z07NEibZ0LvXg== X-Google-Smtp-Source: ABdhPJzoOqPjDf1+VrIZZLEww/VNo4+3q+CsqlBn8lTWwOghfJrWHZ3H17sH4YkPOsQrSXblnEDngU/4PdT4maWPvlg= X-Received: by 2002:a05:6808:138c:: with SMTP id c12mr6902383oiw.178.1627794406383; Sat, 31 Jul 2021 22:06:46 -0700 (PDT) In-Reply-To: <8735rybg2f.fsf@gnus.org> 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:211035 Archived-At: On Wed, Jul 28, 2021 at 3:42 PM Lars Ingebrigtsen wrote: > > Allen Li writes: > > > I tried some printf debugging and I noticed that the bug goes away > > when I add (message "%S" (buffer-substring-no-properties (point-min) > > (point-max))) to the top of electric-pair--balance-info. Maybe I'm > > being dense, but I think that expression should not have this kind of > > side effect. > > It should not, but it sounds like whatever's going on might be redisplay > dependent? In which case it might be better to say > > (push (buffer-string) my-var) > > at strategic places in the code instead of messaging, and then examining > my-var afterwards. I can't reproduce my previous fix of adding `(message "%S" (buffer-substring-no-properties (point-min) (point-max)))` to the top of `electric-pair--balance-info`. At the time, I had many more `message`s scattered throughout the function, but I could reliably make the bug disappear and reappear by adding/removing this particular `message`. Of course, I don't remember exactly what `message`s I had at the time. Thus, I resorted to actually trying to understand the code. I've tracked down the bug to unexpected behavior from the `scan-sexps` call in this part of `electric-pair--balance-info`: (ended-prematurely-fn ;; called when `scan-sexps' crashed against a parenthesis ;; pointing opposite the direction of travel. After ;; traversing that character, the idea is to travel one sexp ;; in the opposite direction looking for a matching ;; delimiter. #'(lambda () (let* ((pos (point)) (matched (save-excursion (cond ((< direction 0) (condition-case err (eq (char-after pos) (electric-pair--with-uncached-syntax (table) (debug) ;; Added by me (matching-paren (char-before (scan-sexps (point) 1))))) (scan-error nil))) The state of my test buffer at this point is `^

` where ^ is point. The buffer starts as ``, and like the comment states, we move point past the `<` "pointing opposite the direction of travel" and look for a match for the opening `<`. However, the `(scan-sexps (point) 1)` here signals `Scan error: "Unbalanced parentheses", 1, 4`. Again, the buffer state here is `^

`. Since `scan-sexps` is C, I haven't dug into it yet, but it seems like it should work. I also checked `(matching-paren ?<)` and `(matching-paren ?>)` here to see if the syntax table recognizes the angle brackets and it appears to do so, so I don't know why `scan-sexps` is complaining. While I don't know how the `syntax-ppss` cache works, I tried added an extra `syntax-ppss-flush-cache` call to the start of the `electric-pair--with-uncached-syntax`, but that doesn't help. My current hypothesis is some odd behavior in how setting the syntax table works.