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 15:10:12 +0100 Message-ID: <87wmr9hh8e.fsf@gmail.com> References: <87r0hh6g1d.fsf@gmail.com> <87mss56cgs.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="20058"; 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 15:48:34 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 1rZXbm-00054u-8G for ged-emacs-devel@m.gmane-mx.org; Mon, 12 Feb 2024 15:48:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rZXau-0003Xf-R9; Mon, 12 Feb 2024 09:47: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 1rZXas-0003XE-H7 for emacs-devel@gnu.org; Mon, 12 Feb 2024 09:47:38 -0500 Original-Received: from mail-ej1-x62f.google.com ([2a00:1450:4864:20::62f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rZXan-0001cu-Ri for emacs-devel@gnu.org; Mon, 12 Feb 2024 09:47:38 -0500 Original-Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a3c00c98d32so379059866b.3 for ; Mon, 12 Feb 2024 06:47:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1707749251; x=1708354051; 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=LQdDrtKJDpgZ2MGzo2dZLTasfMuuvVcKfukAeLXub3w=; b=m+TZSTURI8324kuuEKOb5m4U0pvD5rbKjq1QqbkfutLq6lV+ARfBAXWtoEa83R2BoO 6npRpPe2X18dRCrG3PPUCIjDrXzjQynBZ4TuVY4d4QfeP62fcSmNJr85CwBzdtK/7UAA 1OE1Zb7Yuye6Dk3qhEXkpDlVksb006FBrc2Gt2fOYSOjnPFTpplKApH+cStmTdPZUGRj vxlq9GCYcSJE/a6B0pukpYLTd9M+21moTdW8/ga1pNrIive7ErHGROc864OuWs8yt5Xe Ttiyz5egG8/pODedhyBUUE5M0Q9P//IIYy/9/arIOmGnPLrdYwQNyAUWG4AQ3rB0K9Zz 9/pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1707749251; x=1708354051; 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=LQdDrtKJDpgZ2MGzo2dZLTasfMuuvVcKfukAeLXub3w=; b=xD4PbV2I5z9mgDjhMRJW25L4Zhzo65mNC8CorN2o7cdgSL0qXDrYiGnHs092dyhhLk +fwa+kMQ57xg6MPefRk70OUfpNs0PCVSyR9UMFLFOemNqQIkuv8Abm4xcJlXHwfAM/9p yDVA0B/OSzK1IEfsLkuB3l6Od2nmaUmPeQ8SbKi4jO+8VfFgxJA0imBbhv6GEbCfWc83 kPL24jEfOlsWTzTQZ9Fc4jefvyFvccRwpvuNzXl++2Y6oxpw+UVP0uZ7BQYkdop3dcoz VclLzkADuTeWX2hLTuzFg7K9Z4Ar9c2Kv6fVcq8qfme/SJbWhCpyz866F5WLXV8ILKcD uqLA== X-Forwarded-Encrypted: i=1; AJvYcCWMmwKzv0nz/QOE3IQQxMxciNsgNYJG9iNCwgnd/QAl4FSul0T2JTvHvDB/K8T+QVAI8M+JhemoT2UdZLCSUBBkwAjV X-Gm-Message-State: AOJu0YxH0zaqXxsBAEMrd0P4spk/g74T/ydrbcNUwNmRKK8/QSRr4dz+ 0Cx+EqNWuYPqCxC1HACb2L2Cm02iT/t5sJxNuq5lsIloAUwofg4y X-Google-Smtp-Source: AGHT+IEEQYZ7CwmpFdAOIpJ0EJ8ClF5GzzHTYGeqnrZ9zqUv4F0Bv1qqaV86lYXwyNXWJqyhSFCRdQ== X-Received: by 2002:a17:906:359b:b0:a38:9eee:30c with SMTP id o27-20020a170906359b00b00a389eee030cmr4536699ejb.15.1707749250617; Mon, 12 Feb 2024 06:47:30 -0800 (PST) X-Forwarded-Encrypted: i=1; AJvYcCULuoYEGEvCO8V1Ad5gWdQgc6di9qQeoupv3NonTxQIuttn7az6cVZEBjOLBV15+R9YdffP3TEH7Rg0cCFJfJ0m4wn1 Original-Received: from localhost (62-77-231-86.static.invitel.hu. [62.77.231.86]) by smtp.gmail.com with ESMTPSA id d21-20020a1709064c5500b00a3c1e1ca800sm282506ejw.11.2024.02.12.06.47.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Feb 2024 06:47:30 -0800 (PST) In-reply-to: Received-SPF: pass client-ip=2a00:1450:4864:20::62f; envelope-from=geza.herman@gmail.com; helo=mail-ej1-x62f.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, 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:316138 Archived-At: >> 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. 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. >> 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. >> 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. > 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. But it annoys me that sometimes I cannot move to the pair of a paren because of this behavior. 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.