unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Juha Nieminen <nospam@thanks.invalid>
To: help-gnu-emacs@gnu.org
Subject: Re: Problem with parenthesis matching and autoindentation in MacOS X version of emacs
Date: Tue, 16 Dec 2008 19:46:31 GMT	[thread overview]
Message-ID: <rAT1l.199$e9.187@read4.inet.fi> (raw)
In-Reply-To: <mailman.2805.1229365442.26697.help-gnu-emacs@gnu.org>

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


  parent reply	other threads:[~2008-12-16 19:46 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-15 11:18 Problem with parenthesis matching and autoindentation in MacOS X version of emacs Juha Nieminen
2008-12-15 18:39 ` Alan Mackenzie
     [not found] ` <mailman.2805.1229365442.26697.help-gnu-emacs@gnu.org>
2008-12-16 19:46   ` Juha Nieminen [this message]
2008-12-17 16:29     ` Alan Mackenzie
     [not found]     ` <mailman.2957.1229530429.26697.help-gnu-emacs@gnu.org>
2008-12-18  0:32       ` Juha Nieminen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='rAT1l.199$e9.187@read4.inet.fi' \
    --to=nospam@thanks.invalid \
    --cc=help-gnu-emacs@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).