From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Augusto Stoffel Newsgroups: gmane.emacs.bugs Subject: bug#50236: 27.2; electric-pair-mode is inconvenient in comint Date: Tue, 23 Aug 2022 18:56:52 +0200 Message-ID: <87tu62sxt7.fsf@gmail.com> References: <87bl5heuva.fsf@gmail.com> <87zgn4nxv7.fsf@gmail.com> <87tu642sso.fsf@gnus.org> <87v8qk5kit.fsf@gmail.com> <875yijuvzf.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7215"; 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: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Aug 23 18:58:43 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 1oQXEg-0001gB-NG for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Aug 2022 18:58:42 +0200 Original-Received: from localhost ([::1]:57556 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oQXEf-00073C-7S for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Aug 2022 12:58:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58552) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oQXE3-00070B-7z for bug-gnu-emacs@gnu.org; Tue, 23 Aug 2022 12:58:07 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55177) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oQXE2-00078P-63 for bug-gnu-emacs@gnu.org; Tue, 23 Aug 2022 12:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oQXE2-0000Hr-1t for bug-gnu-emacs@gnu.org; Tue, 23 Aug 2022 12:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Augusto Stoffel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Aug 2022 16:58:02 +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.16612738241038 (code B ref 50236); Tue, 23 Aug 2022 16:58:02 +0000 Original-Received: (at 50236) by debbugs.gnu.org; 23 Aug 2022 16:57:04 +0000 Original-Received: from localhost ([127.0.0.1]:44926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQXD5-0000Gg-TP for submit@debbugs.gnu.org; Tue, 23 Aug 2022 12:57:04 -0400 Original-Received: from mail-ed1-f49.google.com ([209.85.208.49]:44916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oQXD3-0000G4-Ov for 50236@debbugs.gnu.org; Tue, 23 Aug 2022 12:57:02 -0400 Original-Received: by mail-ed1-f49.google.com with SMTP id t5so18813593edc.11 for <50236@debbugs.gnu.org>; Tue, 23 Aug 2022 09:57:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc; bh=Q3NfHAmh12KC11+ZCP9Eg0/ptWnWuSlgI2xIUiC4opM=; b=GMl71cxQOPDU4EVL3O0ErxLMIZKMImc2gLRrlmNW3VaCSSFJcVztKub8kSUqwItf4x f6jkOoZnkvcBsu+bPpcQbcEb6UnCH8KW/sfiLLGoLiqn+W9tqJaYnN4C5sgEfILsbQld MnDG/kQXzq/1kLd865hRFp4Ntd9jRFb/E9unamG9eMOguxJKPlA8cSsi2EGQWZEZnlV9 on1+i605XEjm15GfwF3gyB6lRXV+IROWISFC69dQR4Tll0kOuKrFYaJr76Id+NwU472T 5tYS/B7owjkBpBImoH4g1tHjBKWtfHG9MU5BgCkMZS+rpF7lNQA3NT5eHyV/g+onyGm4 jxTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc; bh=Q3NfHAmh12KC11+ZCP9Eg0/ptWnWuSlgI2xIUiC4opM=; b=cpc3MJl0L4U27wrQwJt25QGI28uMMANz6Fobvm2DmEIVeKsCJ14Za5cOnMx7UY7T7Q o/QXQ14o5cnvNIXaU0/Jy3myVvm5RSGwPysZgnEH/HngF6yRsKWFzKiNZb+0LrxL3wNr DgJFEOoo2I7hnH2oWplXgTZKlVZ6Y5GiRfUNmIhFV7Wdr/lxgp/UpAWgjTHxiE7sjd+b 38IwrBORyH7jxXvWHySBagYHgDMRrjgqvENVw4lvPKA0oqYwvh33hJBrOkM3WBImsskd DaEkXje0u0CSZKIVS5cas/dyBxRIJwr/ZXiKonyu+blubHHc/j9694ABSvhUSozN8JML Lmug== X-Gm-Message-State: ACgBeo2OWorXYZO2ZtYho4bleE6DdKSB5KxLFggxBCaCtcdvnpqRuBf9 0K31z7jnxUae2knNwX2OiskG8U8oiJE= X-Google-Smtp-Source: AA6agR6xqSOTPeCBY3EPcvVpCnulEu+XL/hktSk3lF1WWTvI5SpvdtfLvrE6hkWZlb1lJgHix6ob2w== X-Received: by 2002:a05:6402:454:b0:447:59a8:fc7d with SMTP id p20-20020a056402045400b0044759a8fc7dmr789301edw.68.1661273815304; Tue, 23 Aug 2022 09:56:55 -0700 (PDT) Original-Received: from ars3 ([2a02:8109:8ac0:56d0::157b]) by smtp.gmail.com with ESMTPSA id b1-20020a1709063ca100b00728f6d4d0d7sm109656ejh.67.2022.08.23.09.56.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Aug 2022 09:56:54 -0700 (PDT) In-Reply-To: <875yijuvzf.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 23 Aug 2022 11:53:24 +0200") 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:240562 Archived-At: On Tue, 23 Aug 2022 at 11:53, Lars Ingebrigtsen wrote: > > 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. This makes sense. However, in comint the "input" field has no field property; only the output is labeled as such. So the suggestion to do something special if inside a field wouldn't solve the original problem described in the bug. So the conclusion seems to be that a comint-specific electric-pair-skip-self function is needed (namely, one that narrows to the current field provided the current field property is nil, to avoid those performance issues.)