Re: Parenthesis matching should consider the kind of parenthesis during pair-search

[Alan Mackenzie <acm@muc.de>]

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).