From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?Herman=2C_G=C3=A9za?= Newsgroups: gmane.emacs.devel Subject: Re: Parenthesis matching should consider the kind of parenthesis during pair-search Date: Mon, 12 Feb 2024 17:05:18 +0100 Message-ID: <871q9h8wmp.fsf@gmail.com> References: <87r0hh6g1d.fsf@gmail.com> <87mss56cgs.fsf@gmail.com> <87wmr9hh8e.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7703"; mail-complaints-to="usenet@ciao.gmane.io" Cc: =?utf-8?Q?Herman=2C_G=C3=A9za?= , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Feb 12 17:40:37 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 1rZZMD-0001mV-3N for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Feb 2024 17:40:37 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZZLV-0005qh-GT; Mon, 12 Feb 2024 11:39:53 -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 1rZZLT-0005qY-Ij for emacs-devel@gnu.org; Mon, 12 Feb 2024 11:39:51 -0500 Original-Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rZZLO-0006Af-SX for emacs-devel@gnu.org; Mon, 12 Feb 2024 11:39:51 -0500 Original-Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-a36126ee41eso446410466b.2 for ; Mon, 12 Feb 2024 08:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707755984; x=1708360784; darn=gnu.org; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :references:from:to:cc:subject:date:message-id:reply-to; bh=DgyDXQVNh1yZ0ReIo1vfB9xefoAeJvhTwNiEYVJCHBE=; b=CwF01JZB7aVbTB2EKGBHGC5aGe4bBlPvL+p8p/eiKgiECcTQwKj5YrHX88YHGYUAVz k4sFvSCtQTicULfT68SM2puVhBJ0n7R+Hzc5Ul5F6H3ITEZE5jpRLJqlIZUGmd3wbUZk JuXJB5q+Ew2QUqfqn8b4oJW02Psr2Smi6Zwee4cZ49wnBIYgADwJ1s1Sqfs+jcVhY0FX 7PTlp4nbfiWn6a0sLekpF9+6GRp9YBZWTYS8X5+ShbdYE8tsEFMV3DJT4eHFyIweR3fB lzqyElWblMhGhoaph0vG+84YfBIyas6EISXq/fyHpKc1yN7rqACcX6tIEjEEZqNFYjS+ 7Dlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707755984; x=1708360784; h=mime-version:message-id:in-reply-to:date:subject:cc:to:from :references:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=DgyDXQVNh1yZ0ReIo1vfB9xefoAeJvhTwNiEYVJCHBE=; b=CzCSgZORFPiwigchH05vP885OgnMaPVyw6LmQcOn/jOezRBEu3QGUR4pqFQkrsnKnr OMpoaQT7V5cstGLkcGxcKel3OPkBiR0dQ5ytLaYqfb0Ad+pW/Cz3lw3q1Fs1h228lqxt Cftbceiz2iB9eh8ryS262frdGLHR2De8G8htdcS/6eo0W2AGwO9pDtVtzv5h/29/wx20 S2fASvNifnYHP95XjGvQPzq7+UBe9vCbTECERa9BT+Vif8qlt1VIZR84BvA/BDS2q/ai Nxm3F7ZRxetJgdZ2zG8lWnVAOxoyZlj6y13bl5jEs5jQKB4n66De5N+F5LehxRGW1Q6j WBHA== X-Gm-Message-State: AOJu0Yyt65jGya/SfYuOuJWiuZ/yB7KSBdG42mMENphnvTL2hEp/mFzz TfoQsJAvEsGW8n8PKcARhUOiK1wAgR/ot5X2BrOZVA+vvAonQVzg X-Google-Smtp-Source: AGHT+IGozgFA+nerWlEG3kw+mMAQsSj4swufN1NJoxjxhFt547PA9s0ySGFXjjwtydWHGOUJCo5Zfw== X-Received: by 2002:a17:906:4a90:b0:a3c:c56f:564c with SMTP id x16-20020a1709064a9000b00a3cc56f564cmr1502166eju.1.1707755984325; Mon, 12 Feb 2024 08:39:44 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCXCHLt0n1LsymzdOl3v0o81kw6PMSpVmB6Ag+LJ7A+xMu25O5jz76jHR0lTpBp4SoETPU1y+mgSbMBrrntopI18zKyv Original-Received: from localhost (62-77-231-86.static.invitel.hu. [62.77.231.86]) by smtp.gmail.com with ESMTPSA id d24-20020a170906371800b00a3c9567736dsm365909ejc.149.2024.02.12.08.39.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 08:39:43 -0800 (PST) In-reply-to: Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=geza.herman@gmail.com; helo=mail-ej1-x636.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=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:316141 Archived-At: Alan Mackenzie writes: >> 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. Maybe I wasn't clear enough, I meant that this is true for this example. And I think this is true, it's easy to verify. > 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. Thanks! I'll check this out. As I see this is a little bit more complicated, because this thing uses a more general scanner function (called scan_list). I think it's easy to hack something so it works for my case, but it can easily break other part of Emacs. > 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. Yes, but you need to move the cursor over some paren, right? Otherwise there is no paren-related info shown. Supposedly the first or last paren is a good candidate for this. But I think that with my suggested method, problems are detected as well. Maybe there are different cases where each method fails, but I don't see any of the methods significantly better than the other in this regard. But, tbh, I think it would be better if Emacs simply had (and maybe it does have) a functionality which simply checks that all the parens are OK. Without ever having to move the point over some paren. I find it a hacky, if one, after some copy-pasting, moves the cursor over the first or last copied paren, and if there is no mismatch detected, then considers that the copy-paste was surely fine. Maybe that's true, but I have to think hard to confirm this. >> 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. Just to clarify, with my suggestion, missing parens are still highlighted. Only "mismatching" parens are not. But I don't think that "mismatching" parens should be a thing. I think that except very beginners, people simply don't write mismatching parens by mistake. So there is no need to detect that. I admit that it can be typo. But if that's a typo, the mistake will still be detected by my suggested method. >> 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. The more I think about it, the clearer that this is the correct solution for this problem. But I agree, it may need way to much of work to solve such a tiny problem.