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.