[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with parenthesis matching and autoindentation in MacOS X ver
From: |
Alan Mackenzie |
Subject: |
Re: Problem with parenthesis matching and autoindentation in MacOS X version of emacs |
Date: |
Wed, 17 Dec 2008 16:29:00 +0000 |
User-agent: |
Mutt/1.5.9i |
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).