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

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

[Herman, Géza]

Hi all,

Emacs parenthesis matching works differently than I'd have 
expected (what show-paren-mode shows).  As I understand it, it 
searches for the matching pair by not considering the kind of the 
parenthesis (no matter whether it's a curly/square/etc bracket). 
And after it found it, then it considers the kind, and if there is 
a mismatch then it is shown in red.  Usually this is not a 
problem, because parentheses come in pairs which are usually 
nested.  But if this is not true, then Emacs works unexpectedly in 
my opinion.  See this Makefile example: "$(info })" (this prints a 
} to stdout).  In this case, emacs shows } as the "matching" pair 
of the (.  And as the kind doesn't match, it's a mismatch.  But 
I'd have expected that the pair of ( is the ), and } doesn't have 
a matching pair (because this is what actually happens in this 
example).

What do you think, shouldn't Emacs consider the kind of 
parenthesis when during searching for a pair? (in other words, it 
should ignore all other kinds of parentheses when it searches for 
a pair)

Thanks,
Geza

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

[Joost Kremers]

On Mon, Feb 12 2024, Herman, Géza wrote:
[...]
> this is not true, then Emacs works unexpectedly in my opinion.  See this
> Makefile example: "$(info })" (this prints a } to stdout).  In this case, emacs
[...]
> What do you think, shouldn't Emacs consider the kind of parenthesis when during
> searching for a pair? (in other words, it should ignore all other kinds of
> parentheses when it searches for a pair)

In my opinion, it should not consider the type of parenthesis, because I mess up
my parentheses much more often than I run into cases where I'm using a
parenthesis that is not part of a pair and where it's impossible to escape it.


-- 
Joost Kremers
Life has its moments

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

[Alan Mackenzie]

Hello, Géza.

On Mon, Feb 12, 2024 at 12:49:03 +0100, Herman, Géza wrote:
> Hi all,

> Emacs parenthesis matching works differently than I'd have 
> expected (what show-paren-mode shows).  As I understand it, it 
> searches for the matching pair by not considering the kind of the 
> parenthesis (no matter whether it's a curly/square/etc bracket).

The low level routines like scan-lists work by scanning over text
counting the nesting level of open and close parentheses, "ignoring"
comments and strings as it goes.  (That "ignoring" is somewhat
complicated.)  When the depth of nesting gets back to zero, that's where
the matching close paren is.

> And after it found it, then it considers the kind, and if there is 
> a mismatch then it is shown in red.  Usually this is not a 
> problem, because parentheses come in pairs which are usually 
> nested.  But if this is not true, then Emacs works unexpectedly in 
> my opinion.  See this Makefile example: "$(info })" (this prints a 
> } to stdout).  In this case, emacs shows } as the "matching" pair 
> of the (.  And as the kind doesn't match, it's a mismatch.  But 
> I'd have expected that the pair of ( is the ), and } doesn't have 
> a matching pair (because this is what actually happens in this 
> example).

> What do you think, shouldn't Emacs consider the kind of 
> parenthesis when during searching for a pair? (in other words, it 
> should ignore all other kinds of parentheses when it searches for 
> a pair)

No, I don't think that.  ;-)  A lot of the time (?most of the time), we
want Emacs to point out paren mismatch errors, and that alternative way
of scanning parens would prevent this.

If you have a specific need to consider only ( and ) as the balancing
parens, ignoring [, ], {, }, etc., you can achieve this by removing the
open/close syntax-table entries from these characters first.  See the
chapter "Syntax Tables" in the Elisp manual for details.  Be aware that
swapping syntax tables repeatedly can slow your program down, since it
clears useful caches in doing so.

> Thanks,
> Geza

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Herman, Géza]

Alan Mackenzie <acm@muc.de> writes:

>> What do you think, shouldn't Emacs consider the kind of
>> parenthesis when during searching for a pair? (in other words, 
>> it
>> should ignore all other kinds of parentheses when it searches 
>> for
>> a pair)
>
> No, I don't think that.  ;-)  A lot of the time (?most of the 
> time), we
> want Emacs to point out paren mismatch errors, and that 
> alternative way
> of scanning parens would prevent this.
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 ')' ).  All the other interactions would be the same. 
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.

Why is it a desired thing that Emacs should show some mismatching 
paren if the cursor is on a completely unrelated paren?

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

[Alan Mackenzie]

Hello, Géza

On Mon, Feb 12, 2024 at 14:10:06 +0100, Herman, Géza wrote:

> Alan Mackenzie <acm@muc.de> writes:

> >> What do you think, shouldn't Emacs consider the kind of parenthesis
> >> when during searching for a pair? (in other words, it should ignore
> >> all other kinds of parentheses when it searches for a pair)

> > No, I don't think that.  ;-)  A lot of the time (?most of the time),
> > we want Emacs to point out paren mismatch errors, and that
> > alternative way of scanning parens would prevent this.

> 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, but why don't
you implement your idea so that we can try it out?

> All the other interactions would be the same.

That's a bold thing to say, indeed!

> 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?

> 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".  It's fairly likely to be a typo.  For
example, on some keyboard layouts (including British English), ] and }
are on the same key.  It's easy to mistype } as ] and not notice right
away.  The show-paren-mode mismatch facility helps notice it sooner.

But, as I say, the best way to go from here would be to implement your
new matching scheme and then we can try it out.  I can think of some
uses for it, for example for commands like `occur' on M-s o, where a
regexp gets entered into the minibuffer.  Regexps frequently have
unmatched parens.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Herman, Géza]

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

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

[Alan Mackenzie]

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

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

[Herman, Géza]

Alan Mackenzie <acm@muc.de> 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.