From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#50236: 27.2; electric-pair-mode is inconvenient in comint Date: Tue, 23 Aug 2022 11:53:24 +0200 Message-ID: <875yijuvzf.fsf@gnus.org> References: <87bl5heuva.fsf@gmail.com> <87zgn4nxv7.fsf@gmail.com> <87tu642sso.fsf@gnus.org> <87v8qk5kit.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24259"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: 50236@debbugs.gnu.org To: Augusto Stoffel Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 23 11:55:04 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 1oQQch-000641-MV for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Aug 2022 11:55:03 +0200 Original-Received: from localhost ([::1]:36072 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQQcg-000770-NV for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Aug 2022 05:55:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59144) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQQbi-0006dN-Gy for bug-gnu-emacs@gnu.org; Tue, 23 Aug 2022 05:54:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52875) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQQbi-0001LV-8q for bug-gnu-emacs@gnu.org; Tue, 23 Aug 2022 05:54:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oQQbh-0005GZ-UG for bug-gnu-emacs@gnu.org; Tue, 23 Aug 2022 05:54:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Aug 2022 09:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50236 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 50236-submit@debbugs.gnu.org id=B50236.166124841620181 (code B ref 50236); Tue, 23 Aug 2022 09:54:01 +0000 Original-Received: (at 50236) by debbugs.gnu.org; 23 Aug 2022 09:53:36 +0000 Original-Received: from localhost ([127.0.0.1]:42619 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQQbI-0005FQ-Cl for submit@debbugs.gnu.org; Tue, 23 Aug 2022 05:53:36 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:36640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQQbF-0005FC-IV for 50236@debbugs.gnu.org; Tue, 23 Aug 2022 05:53:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:Date:References: In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=32avkb2LJzN1cJvYf7bB78XE/+erxGzaZ6SG3HuJX/U=; b=WhIb/hBc2Q0OYVTU1Q75p8Zj+A jlXGIbwiabEhtv1GYpLzO8YIGjhFMY9AhbT9SSIsOC8fBBoE2tZjEVyU3mL1h91B/OS7/O9KaE1W7 1dQu7eo3HnOHDcociwSb0WgD8LOEWSq/6gWPWd7rvM6Fd8gWDNU+7cz0qBnHGlzY1XxU=; Original-Received: from [84.212.220.105] (helo=joga) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oQQb7-00079N-2Q; Tue, 23 Aug 2022 11:53:27 +0200 In-Reply-To: <87v8qk5kit.fsf@gmail.com> (Augusto Stoffel's message of "Mon, 22 Aug 2022 18:07:54 +0200") Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEUzGBdPKiJtTD+f emP///+YbcQvAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+YIFwkHALHn25AAAAGQSURBVDjLbZTbdcAg CEAlXQDIAgEXaGT/3QqiiUnKjx4vD3loKSFAiFC+QgEoVXA5r0YpEiCRq4H+7n5YAOzAsKAjQTGu tbHaVptqVbWTpYNqZq2Z1b1Z31utCarvm+0GvgmNVrX4HcGAqHmUHQEEaCMPExZ78zRc8MfcP1Hm E678KiRxr2qihDcoaRHInYwEaSyLJIEvKAuAj8FwlUewWMBcLhtEfAdnSdKPYAnOZ5zOGAvYzxF8 bZXrdwu5ol+ZVwfMOmPcrgLQAhYLLyArf10pbhIWD1CIN+9386YLPWMgn2a935iZDABsvzEHpoY5 c7O6bGcHZlIewbWmK3eW+lkxhqY2RfEqOwj6CKa+K5w3OBRa0yYdVlkadRTulVf1RNYEs4Fy9xaW uRJSVmF51gqnI34XMUTlDcYAuYW+qjs99RhrEZlF+zPzlsgcBowpogDsPXHQtaHktPR58yyF7q7j iIJjFpHyNcXidqQk0iuSgAotqfjU+VPrY4rX5wF97zW46rS8FChLcv/8Rh38AdXYQFTLI7H7AAAA JXRFWHRkYXRlOmNyZWF0ZQAyMDIyLTA4LTIzVDA5OjA3OjAwKzAwOjAws9CHUwAAACV0RVh0ZGF0 ZTptb2RpZnkAMjAyMi0wOC0yM1QwOTowNzowMCswMDowMMKNP+8AAAAASUVORK5CYII= X-Now-Playing: Fairport Convention's _Come All Ye (6)_: "Dirty Linen" 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:240511 Archived-At: Augusto Stoffel writes: >> That would make sense in this case... I'm trying to think of instances >> where it wouldn't make sense, and I can't think of any. [...] > So I guess my question here is: does it make sense for a major mode with > a notion of "code blocks" set field properties as part of the > font-locking? Or is there any reason not to mix up fields with > font-locking? Hm, that's an interesting question. I think that, basically, the only usage for the "field" thing is to divide a line up into bits so that `C-a' takes you to the start of the field instead of the start of the line. Extending the "field" thing to mark larger blocks is might well make sense. Anyway, this reminds me of a performance problem we have when making commands field sensitive: It's generally kinda slow. It's no problem in the `C-a' case -- we're limited to the current line, so our search for field properties is very short. I was making some other command field sensitive (I forget which), but had to abandon it, because it was too slow. The problem is, generally, that when you're not in a field, you want to find the end the previous field and delimit the command to that region. However, the previous field may be anywhere, so the searches for the field text property goes back to point-min. And that's just unworkably slow for functions that trigger a lot -- and I think that this may be the case for electric-pair-mode, too. I mean -- we could delimit electric-pair-mode to the current field, if there is one, but we can't do the same if we're not in a field. So if you have --- *Here's a field with (* Here we, much later in the buffer, are outside of a field and we type ) --- we can't (for these performance reasons) just use a `narrow-to-field' first when checking whether that ) matches that other (. Once we have the pairs, we could check whether both are in the same field, though.