[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with parenthesis matching and autoindentation in MacOS X ver
Re: Problem with parenthesis matching and autoindentation in MacOS X version of emacs
Tue, 16 Dec 2008 19:46:31 GMT
Thunderbird 188.8.131.52 (X11/20081112)
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
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...)