From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#35496: 27.0.50; smie-blink-matching-open blinks token before point after RET Date: Mon, 13 May 2019 03:52:04 +0300 Message-ID: <572f9293-e6df-6cb0-8829-88e0acd61017@yandex.ru> References: <4cfccfa9-ee9d-3bc0-30a3-36d656f96de8@yandex.ru> <25c51540-6c49-ba79-bbb4-e60b1e616fc6@yandex.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------664B60B9FD51BAF3DC40E627" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="211124"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 Cc: 35496@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 13 03:04:43 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hPzOV-000sla-3p for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 May 2019 03:04:43 +0200 Original-Received: from localhost ([127.0.0.1]:49129 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPzOU-0002xp-55 for geb-bug-gnu-emacs@m.gmane.org; Sun, 12 May 2019 21:04:42 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51934) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hPzO4-0002jJ-9X for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 21:04:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hPzDD-0004TY-V5 for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 20:53:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58455) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hPzDD-0004TM-Me for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 20:53:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hPzDD-0005Uw-8p for bug-gnu-emacs@gnu.org; Sun, 12 May 2019 20:53:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 May 2019 00:53:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35496 X-GNU-PR-Package: emacs Original-Received: via spool by 35496-submit@debbugs.gnu.org id=B35496.155770873621063 (code B ref 35496); Mon, 13 May 2019 00:53:01 +0000 Original-Received: (at 35496) by debbugs.gnu.org; 13 May 2019 00:52:16 +0000 Original-Received: from localhost ([127.0.0.1]:43766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPzCR-0005Te-W4 for submit@debbugs.gnu.org; Sun, 12 May 2019 20:52:16 -0400 Original-Received: from mail-lj1-f173.google.com ([209.85.208.173]:33796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hPzCP-0005TO-Ie for 35496@debbugs.gnu.org; Sun, 12 May 2019 20:52:14 -0400 Original-Received: by mail-lj1-f173.google.com with SMTP id j24so8567508ljg.1 for <35496@debbugs.gnu.org>; Sun, 12 May 2019 17:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=KFWL8sU904WpDD4eNY+3+SAwfll8NcElYr4DI9IcqZ4=; b=uBg4RaLZ58eYOnrusfNo2BN7SL+EnQABMUlUKBVuIldBFVDe8BIlsh3KjTgpxcQEgH rqGXzZVNRkmNwfnIWGb0ftWQKXfxffGqBiHseG2EJS2zs/F7ciEIHuECAw3xbQkwRT9x VSi9KiNt4p4rYQL/m5EVLBYl48rrvZsEC2YJt/AQWAPwdbBB8Can6KzSQHJ3OWUpmffJ 7LwIJ164ThLeUDBGRK6TO7HZ0bx9R/sD+I8rqe4YXD678xjV45D62u9FjDswy73A594n 7CE6sHPfEqoiERDxxcKizg97PuIKDdHRuUup0CMJ/gqpLmVkR9nwOlYtTwNknDsYOs/S GyxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language; bh=KFWL8sU904WpDD4eNY+3+SAwfll8NcElYr4DI9IcqZ4=; b=L2RKTDpr7N5FpWkLJUOiZwKTgh+3xtdOjP+J+/sPIJyL5ocdZR5MUbfYPJ5w6GaG+I 6ITJr05aaWVq+GZ4OxKl8UsA64nA+3RhOjhBmvg4SA4Ny2jTukGZvx22ALmukpfsl1yi J2rfcMoilmyaJGn/P/0j2ttdBZsoOaC8I4TjT12XSQR+Pu/fsWu1Panb/TR2eDidoFUu LWBEhlJkK2GBWcouklgFm8g2+DY/1oId0WR3ICXwX6Jw8BHtcnDBIDWyOgfSFKydrA8l hjppqmrepFkAZYlmsIiKBR7hGt9apy8D1veRfGqnmEH+f2s7qpq9ydAsy9T0e5y1FlhK GWQQ== X-Gm-Message-State: APjAAAVER2LRkXYUMLCm0g/z71zQXPxrDAt+xqhi51pUHYQJirEC44lt Mp6vSOpElzuAkXitgc8kXynMxier X-Google-Smtp-Source: APXvYqzgGMpe+4epNKVRq+yANpjxgo8mQsYAH+t0zDOScXY1TKtgkij4tnJHj8L2tj8R+9UXl1TnJA== X-Received: by 2002:a2e:9b96:: with SMTP id z22mr4472638lji.165.1557708727256; Sun, 12 May 2019 17:52:07 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id m18sm184472lfj.91.2019.05.12.17.52.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 May 2019 17:52:05 -0700 (PDT) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:159165 Archived-At: This is a multi-part message in MIME format. --------------664B60B9FD51BAF3DC40E627 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 08.05.2019 20:42, Stefan Monnier wrote: >> But we don't end up blinking to `def` after RET, we blink to `do`. > > That's not what I see when I try your recipe: it blinks to the "d" of > "def", as it should, for me (both with Emacs'` master` and with > Debian's Emacs-26.1). You are right. Sorry about that. I guess the main problem, both the cause of my misunderstanding and the user aggravation, is that smie-blink-matching-open calls blink-matching-open on a changed position. As a result the sit-for call is issued on the position before the newline instead of after. Which created both the appearance of sluggishness from the original report, and my mistake on which token is highlighted (because the moved cursor is much easier to notice than the subtle paren highlighting, at least on the theme I'm using). I've tried to move all checks smie-blink-matching-open into a save-excursion and call blink-matching-open from the orignal position, but that doesn't work alone, unfortunately, because newline is a separate token. Hence the change in blink-matching-open as well. WDYT? Patch attached. >> SMIE fills it automatically based on the current set of tokens. > > Indeed, but you can tweak it by hand afterwards. > >> If I add it myself, yeah, the behavior is better in this case. > > I've been wondering for a while now if it's not just "in this case" but > in general. I don't know. The highlighting itself is sufficiently unobtrusive here, so it could work either way. If the patch I'm proposing seems like unwanted complexity, we can avoid it also this way, and even simplify more code. >> But I kinda buy your reasoning about not having it there (even though >> it's not a panacea: the user can type whatever token, not only ones in >> the smie-closer-alist. > > I agree that only considering smie-closer-alist is probably not a great > choice. It seemed obvious when I wrote it, but I don't know why, and > I can't justify it now. > > [ Maybe it's because I was working on octave-mode around that time and > didn't want to blink on "end" when the user likes to write the > full-form "endfunction"? But even that doesn't sound like > a good justification. ] I'm guessing that with Elixir's syntax, while the user is typing the last two chars in def sum, do: the 'd' in 'def' would blink twice. Which is maybe not ideal either. >> Overall, I feel that the smie-blink-matching-inners might be too much as >> default anyway. So it's not a big deal if elixir-mode has to disable it. > > I don't think it's specific to elixir-mode but is rather > a user-preference. Maybe it should default to nil, but I haven't > found a mode where smie-blink-matching-inners should be disabled > *because of the mode* rather than because that's what the user prefers. No argument here. Just saying it's an okay workaround as well. --------------664B60B9FD51BAF3DC40E627 Content-Type: text/x-patch; name="smie-blink-matching-do.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="smie-blink-matching-do.diff" diff --git a/lisp/emacs-lisp/smie.el b/lisp/emacs-lisp/smie.el index f2163b243e..c68e55e0b4 100644 --- a/lisp/emacs-lisp/smie.el +++ b/lisp/emacs-lisp/smie.el @@ -997,46 +997,48 @@ smie-blink-matching-open (eq (char-before) last-command-event))))) (memq last-command-event smie-blink-matching-triggers) (not (nth 8 (syntax-ppss)))) - (save-excursion - (setq token (funcall smie-backward-token-function)) - (when (and (eq (point) (1- pos)) - (= 1 (length token)) - (not (rassoc token smie-closer-alist))) - ;; The trigger char is itself a token but is not one of the - ;; closers (e.g. ?\; in Octave mode), so go back to the - ;; previous token. - (setq pos (point)) - (setq token (funcall smie-backward-token-function))) - (when (rassoc token smie-closer-alist) - ;; We're after a close token. Let's still make sure we - ;; didn't skip a comment to find that token. - (funcall smie-forward-token-function) - (when (and (save-excursion - ;; Skip the trigger char, if applicable. - (if (eq (char-after) last-command-event) - (forward-char 1)) - (if (eq ?\n last-command-event) - ;; Skip any auto-indentation, if applicable. - (skip-chars-forward " \t")) - (>= (point) pos)) - ;; If token ends with a trigger char, don't blink for - ;; anything else than this trigger char, lest we'd blink - ;; both when inserting the trigger char and when - ;; inserting a subsequent trigger char like SPC. - (or (eq (char-before) last-command-event) - (not (memq (char-before) - smie-blink-matching-triggers))) - ;; FIXME: For octave's "switch ... case ... case" we flash - ;; `switch' at the end of the first `case' and we burp - ;; "mismatch" at the end of the second `case'. - (or smie-blink-matching-inners - (not (numberp (nth 2 (assoc token smie-grammar)))))) - ;; The major mode might set blink-matching-check-function - ;; buffer-locally so that interactive calls to - ;; blink-matching-open work right, but let's not presume - ;; that's the case. - (let ((blink-matching-check-function #'smie-blink-matching-check)) - (blink-matching-open)))))))) + (when + (save-excursion + (setq token (funcall smie-backward-token-function)) + (when (and (eq (point) (1- pos)) + (= 1 (length token)) + (not (rassoc token smie-closer-alist))) + ;; The trigger char is itself a token but is not one of the + ;; closers (e.g. ?\; in Octave mode), so go back to the + ;; previous token. + (setq pos (point)) + (setq token (funcall smie-backward-token-function))) + (and (rassoc token smie-closer-alist) + (progn + ;; We're after a close token. Let's still make sure we + ;; didn't skip a comment to find that token. + (funcall smie-forward-token-function) + (and (save-excursion + ;; Skip the trigger char, if applicable. + (if (eq (char-after) last-command-event) + (forward-char 1)) + (if (eq ?\n last-command-event) + ;; Skip any auto-indentation, if applicable. + (skip-chars-forward " \t")) + (>= (point) pos)) + ;; If token ends with a trigger char, don't blink for + ;; anything else than this trigger char, lest we'd blink + ;; both when inserting the trigger char and when + ;; inserting a subsequent trigger char like SPC. + (or (eq (char-before) last-command-event) + (not (memq (char-before) + smie-blink-matching-triggers))) + ;; FIXME: For octave's "switch ... case ... case" we flash + ;; `switch' at the end of the first `case' and we burp + ;; "mismatch" at the end of the second `case'. + (or smie-blink-matching-inners + (not (numberp (nth 2 (assoc token smie-grammar))))))))) + ;; The major mode might set blink-matching-check-function + ;; buffer-locally so that interactive calls to + ;; blink-matching-open work right, but let's not presume + ;; that's the case. + (let ((blink-matching-check-function #'smie-blink-matching-check)) + (blink-matching-open)))))) (defvar-local smie--matching-block-data-cache nil) diff --git a/lisp/simple.el b/lisp/simple.el index 4454791ad2..6a077cc55a 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -7648,6 +7648,7 @@ blink-matching-open (condition-case () (progn (syntax-propertize (point)) + (forward-comment -1) (forward-sexp -1) ;; backward-sexp skips backward over prefix chars, ;; so move back to the matching paren. --------------664B60B9FD51BAF3DC40E627--