From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Parenthesis matching should consider the kind of parenthesis during pair-search Date: Mon, 12 Feb 2024 15:57:32 +0000 Message-ID: References: <87r0hh6g1d.fsf@gmail.com> <87mss56cgs.fsf@gmail.com> <87wmr9hh8e.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26292"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?Herman=2C_G=E9za?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 12 16:58:25 2024 Return-path: Envelope-to: ged-emacs-devel@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 1rZYhN-0006fu-4F for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Feb 2024 16:58:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZYge-0007l9-5U; Mon, 12 Feb 2024 10:57:40 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZYgc-0007l0-Cl for emacs-devel@gnu.org; Mon, 12 Feb 2024 10:57:38 -0500 Original-Received: from mail.muc.de ([193.149.48.3]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rZYga-0006vh-7m for emacs-devel@gnu.org; Mon, 12 Feb 2024 10:57:38 -0500 Original-Received: (qmail 90743 invoked by uid 3782); 12 Feb 2024 16:57:33 +0100 Original-Received: from acm.muc.de (pd953abfc.dip0.t-ipconnect.de [217.83.171.252]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 12 Feb 2024 16:57:33 +0100 Original-Received: (qmail 24514 invoked by uid 1000); 12 Feb 2024 15:57:32 -0000 Content-Disposition: inline In-Reply-To: <87wmr9hh8e.fsf@gmail.com> X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de Received-SPF: pass client-ip=193.149.48.3; envelope-from=acm@muc.de; helo=mail.muc.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:316140 Archived-At: Hello, Géza. On Mon, Feb 12, 2024 at 15:10:12 +0100, Herman, Géza wrote: > >> The only gain with the current way is that Emacs will point out the > >> mismatch (considering my Makefile example), if the cursor is on the > >> opening '('. With my suggested method, it's not the mismatch which > >> would be shown, but the pair of '(' would (which is actually a > >> correct behavior in this case, the pair of '(' is indeed the ')' ). > > OK, I don't agree with some of the things you're saying > I think I just wrote facts here. Well, you wrote "All the other interactions would be the same.", which is not yet an established fact. > If the matching algorithm were modified in the way I described, that > would be the result. Which parts do you not agree with? > > but why don't you implement your idea so that we can try it out? > If it's an easy thing to do for someone who doesn't really know Emacs's > codebase too much, I can do that. But, tbh, it shouldn't be too hard > to imagine how it worked. Also, all the other editors I know works > similarly like I described. So it's easy to try this out with other > editors. I would say the exercise is moderately difficult for somebody who hasn't worked with the Emacs codebase before. But experience indicates that none of the other readers of emacs-devel is likely to be enthused enough by your suggestion actually to take it up and implement it. If you want to see it in Emacs, you're going to have to implement it yourself. But help would be available on the list. > >> If you put the cursor on the '}', Emacs would still show that it is > >> a paren without a pair, just like now (but instead of saying that > >> its "pair" is the '(', it wouldn't show anything, because '}' > >> doesn't have a pair. > > What if earlier on in the file there were a > > ({) > > ? Should your new way of matching find that {? Or would the > > enclosing ( and ) prevent this being a match? If so, what are the > > exact criteria? > It would find it. My suggested algorithm is simple: when > searching for a pair of '{', the algorithm should only consider > '{' and '}'. All the other kind of parens should be ignored. > That's it. OK, I understand. > >> Why is it a desired thing that Emacs should show some mismatching > >> paren if the cursor is on a completely unrelated paren? > > Emacs doesn't have the facilities to determine that the mismatching > > paren is "completely unrelated". > Emacs already tells that '(' and '}' are unrelated, because it > shows them as mismatching. I don't think that there should be any > sophisticated facilities to determine unrelatedness. If the paren > Emacs find is a mismatching one, then it should continue finding > the proper pair, that's it. OK. > > It's fairly likely to be a typo. > Yes, that is an example that I can accept. But I don't think that this > is a very common thing. At least, for me, this Emacs behavior was > never useful. For editing files written in C or C++, all of (), {}, [], and (in C++) <> are used as paren pairs. They've got to match properly. After killing and yanking a large chunk of text, the current paren matching is useful to indicate any "missing" parens at the start or end of the region just yanked, for example. > But it annoys me that sometimes I cannot move to the pair of a paren > because of this behavior. To be honest, things like that annoy me a bit, too, like when typing in a regexp into the minibuffer. But it would annoy me more not to have any mismatches highlighted in a C buffer. > But thinking about it further, maybe this problem shouldn't be solved > like this, because there is a better solution: makefile-mode should be > more clever - if it is possible - to not mark } as a paren in my > example case, because from the semantics of the Makefile viewpoint, it > is not actually a paren, '}' should behave like if it were in a string. Yes, this would be possible too, but likely quite a bit more complicated. -- Alan Mackenzie (Nuremberg, Germany).