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

[Alan Mackenzie <acm@muc.de>]

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