Problem with parenthesis matching and autoindentation in MacOS X version of emacs

Problem with parenthesis matching and autoindentation in MacOS X version of emacs

[Juha Nieminen]

   I'm using emacs in MacOS X, and it reports its version as:
GNU Emacs 22.1.50.1 (i386-apple-darwin8.10.1, Carbon Version 1.6.0) of 
2007-08-20 on macpro

   It has an annoying problem/bug regarding parenthesis matching and 
autoindentation. (These problems do not happen in the linux nor the 
Windows versions.) For example if I write this code in C++ mode:

void foo()
{
     if(x < 0 || x >= puzzleWidth || y < 0 || y >= puzzleHeight)
         {
         }
}

it will report a "Mismatched parenteses" at the parenthesis which ends 
the if conditional, and after that it will autoindent the {} symbols 
wrongly (as seen above). If I replace the above with this:

void foo()
{
     const bool isOutside =
         x < 0 || x >= puzzleWidth || y < 0 || y >= puzzleHeight;
     if(isOutside)
     {
     }
}

then it will not report the mismatch, and will indent the {} properly.

   Any idea what could be wrong? (As said, this doesn't happen in linux 
nor Windows.)

Re: Problem with parenthesis matching and autoindentation in MacOS X version of emacs

[Alan Mackenzie]

Hi, Juha!

On Mon, Dec 15, 2008 at 01:18:42PM +0200, Juha Nieminen wrote:
>   I'm using emacs in MacOS X, and it reports its version as:
> GNU Emacs 22.1.50.1 (i386-apple-darwin8.10.1, Carbon Version 1.6.0) of 
> 2007-08-20 on macpro

>   It has an annoying problem/bug regarding parenthesis matching and 
> autoindentation. (These problems do not happen in the linux nor the 
> Windows versions.) For example if I write this code in C++ mode:

> void foo()
> {
>     if(x < 0 || x >= puzzleWidth || y < 0 || y >= puzzleHeight)
>         {
>         }
> }

> it will report a "Mismatched parenteses" at the parenthesis which ends 
> the if conditional, and after that it will autoindent the {} symbols 
> wrongly (as seen above). If I replace the above with this:

> void foo()
> {
>     const bool isOutside =
>         x < 0 || x >= puzzleWidth || y < 0 || y >= puzzleHeight;
>     if(isOutside)
>     {
>     }
> }

> then it will not report the mismatch, and will indent the {} properly.

>   Any idea what could be wrong?

Yes.  There're bugs in C++ Mode to do with template brackets (who on
earth "designed" this feature in C++?).  C++ Mode is probably marking
your (newly typed) "<" and ">" as template delimiters, than unmarking the
">" as soon as it has become a ">=".

In C++, it's impossible, in the general case, to distinguish < "less
than" from < "open template", unless the thing doing the analysis is a
compiler.  C++ Mode tries to mark template delimiters as parentheses, but
sometimes it gets it badly wrong.  I've almost finished a fix for a
problem here, which I'm hoping will be ready in time for Emacs 23.  (Hi,
Yidong and Stefan!).

Please try your code snippets in C mode.  There probably isn't a problem
there.  If there is, could you report it to bug-cc-mode@gnu.org, please.

> (As said, this doesn't happen in linux nor Windows.)

I suspect this isn't actually the case.  Whether or not problems appear
is highly dependent on the order you type the characters.  Anyhow, I'm
trying to fix the cause of the problem by always marking "<" and ">" as
parens in matching pairs.

Could you please check again, typing the EXACT SAME sequence of
characters on the Mac and either GNU/Linux or Windows, whether you
actually do get different results on different systems.  Thanks in
advance!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Problem with parenthesis matching and autoindentation in MacOS X version of emacs

[Juha Nieminen]

Alan Mackenzie wrote:
> Yes.  There're bugs in C++ Mode to do with template brackets (who on
> earth "designed" this feature in C++?).  C++ Mode is probably marking
> your (newly typed) "<" and ">" as template delimiters, than unmarking the
> ">" as soon as it has become a ">=".

  It behaves very erratically (although predictably). For example if I
start typing this:

    if(x < 0)

then the parenthesis matching works ok. However, if I know delete the )
and change it to:

    if(x < 0>

it will now match the "closing angle bracket" to the <. Ok, fine, I
suppose. However, now it's when it becomes weird. If I now delete the <
and replace it again with ), that is:

    if(x < 0)

in other words, it's now exactly like the first version above, it will
mismatch the ) with the <, and indentation goes haywire. It will keep
this erroneous matching mode until I delete everything from the 'x'
forward and write it again. It's rather annoying.

  I really don't want to sound rude, but given how usual expressions
like "x < something || x > something_else" are, how come this problem
got into a released version?

  OTOH, who am I to talk? I have been using emacs for something like 10
years to write C++, and only now do I notice this problem. I suppose I
don't use that kind of expression all that often, after all.

  How recently was this new parenthesis matching code introduced into emacs?

> In C++, it's impossible, in the general case, to distinguish < "less
> than" from < "open template", unless the thing doing the analysis is a
> compiler.  C++ Mode tries to mark template delimiters as parentheses, but
> sometimes it gets it badly wrong.  I've almost finished a fix for a
> problem here, which I'm hoping will be ready in time for Emacs 23.  (Hi,
> Yidong and Stefan!).

  Would it be a great loss if the <> "brackets" were not included in the
matching logic at all?

  Is there a way to turn the matching off for <>?

>> (As said, this doesn't happen in linux nor Windows.)
> 
> I suspect this isn't actually the case.  Whether or not problems appear
> is highly dependent on the order you type the characters.  Anyhow, I'm
> trying to fix the cause of the problem by always marking "<" and ">" as
> parens in matching pairs.
> 
> Could you please check again, typing the EXACT SAME sequence of
> characters on the Mac and either GNU/Linux or Windows, whether you
> actually do get different results on different systems.  Thanks in
> advance!

  It's strange. I have been using emacs for years to write C++ in both
linux and windows, and only now do I notice this problem happening there
as well. I assumed there was no problem because I had never noticed
before. However, now that I try it in linux, it also happens there.

  I suppose that for the time being I'll just have to code my way around
the problem like this:

    if(0 > x || x >= puzzleWidth || 0 > y || y >= puzzleHeight)

  (I'm just having a very hard time visualizing the meaning of "0 > x"
in my head, as I'm not accustomed to thinking that way. It's a bit like,
instead of saying "if the amount of money you own is less than zero",
you say "if zero is larger than the amount of money you own", which is
rather backwards and hard to understand...)

Re: Problem with parenthesis matching and autoindentation in MacOS X version of emacs

[Alan Mackenzie]

Hi, again!

On Tue, Dec 16, 2008 at 07:46:31PM +0000, Juha Nieminen wrote:
> Alan Mackenzie wrote:
> > Yes.  There're bugs in C++ Mode to do with template brackets (who on
> > earth "designed" this feature in C++?).  C++ Mode is probably marking
> > your (newly typed) "<" and ">" as template delimiters, than unmarking
> > the ">" as soon as it has become a ">=".

>   It behaves very erratically (although predictably). For example if I
> start typing this:

>     if(x < 0)

> then the parenthesis matching works ok. However, if I know delete the )
> and change it to:

>     if(x < 0>

> it will now match the "closing angle bracket" to the <. Ok, fine, I
> suppose. However, now it's when it becomes weird. If I now delete the <
> and replace it again with ), that is:

>     if(x < 0)

> in other words, it's now exactly like the first version above, it will
> mismatch the ) with the <, and indentation goes haywire. It will keep
> this erroneous matching mode until I delete everything from the 'x'
> forward and write it again. It's rather annoying.

It's very annoying indeed.

> I really don't want to sound rude, but given how usual expressions like
> "x < something || x > something_else" are, how come this problem got
> into a released version?

No, that's fine.  This is one of the worst things to have got into a
released version since I've been here.  Sometimes it just happens - C
is a horrendously complex language for an editor to parse, and C++ and
Java take it a further degree.  Mainly, neither my predecessor (Martin
Stjernholm) nor I are heavy C++ hackers, and neither of us realised the
complexity and bugs that this thing would cause.  So sorry!  But I am
fixing it.

On the other hand, I doubt your rudeness comes close to what I feel about
the designers who decided to use "<" and ">" as template delimiters, thus
leaving the language so highly unparseable.  Why, oh why, couldn't they
have used, say, "{[" and "]}", or something similar?  Just as an exercise
for the reader, how many parameters are there in the parentheses in the
following:

    foo (a < b, c > d);

? 

> OTOH, who am I to talk? I have been using emacs for something like 10
> years to write C++, and only now do I notice this problem. I suppose I
> don't use that kind of expression all that often, after all.

But when it does bite, it's painful in the extreme.

>   How recently was this new parenthesis matching code introduced into
>   emacs?

I think it was new in CC Mode 5.30, so would first have been in Emacs
22.1.

>   Would it be a great loss if the <> "brackets" were not included in the
> matching logic at all?

It would be a loss, yes.  Maybe not that great, but it would be a loss in
consistency, since paren matching should match any sort of
parens/braces/brackets, etc.

>   Is there a way to turn the matching off for <>?

The following quick fix in your .emacs, an unofficial workaround, should
do the trick.  (Please forgive me not having tested it, though).  I think
it might have adverse effects in the font locking and even the
indentation of template structures, though.

(defun jn-disable-<> ()
  (setq c-recognize-<>-arglists nil))
(add-hook 'c++-mode-hook 'jn-disable-<>)

I hope you'll be volunteering to test the full fix to the problem when
I've finished it (hopefully in January or February 2009).  ;-)

> >> (As said, this doesn't happen in linux nor Windows.)

> > I suspect this isn't actually the case.  Whether or not problems appear
> > is highly dependent on the order you type the characters.  Anyhow, I'm
> > trying to fix the cause of the problem by always marking "<" and ">" as
> > parens in matching pairs.

> > Could you please check again, typing the EXACT SAME sequence of
> > characters on the Mac and either GNU/Linux or Windows, whether you
> > actually do get different results on different systems.  Thanks in
> > advance!

>   It's strange. I have been using emacs for years to write C++ in both
> linux and windows, and only now do I notice this problem happening there
> as well. I assumed there was no problem because I had never noticed
> before. However, now that I try it in linux, it also happens there.

Oh, good!  ;-)

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Problem with parenthesis matching and autoindentation in MacOS X version of emacs

[Juha Nieminen]

Alan Mackenzie wrote:
>>   Would it be a great loss if the <> "brackets" were not included in the
>> matching logic at all?
> 
> It would be a loss, yes.  Maybe not that great, but it would be a loss in
> consistency, since paren matching should match any sort of
> parens/braces/brackets, etc.

  I know that the C++ language syntax is not a context-free grammar. In
other words, the meaning of tokens (eg. the tokens < and >) cannot be
deduced without the context.

  OTOH, it basically only makes the life of compilers and code editing
software harder, not people writing C++. It *is* the duty of programs to
do all the hard work, rather than leaving it to the user. :)

  OTOH, given that it's impossible to know the meaning of the < and >
symbols in C++ without the full context, I assume it will be impossible
to make any matching logic which would work in all cases. I don't really
think it would be a huge loss if those were not included in the
parenthesis matching rules.