From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.help Subject: Re: Problem with parenthesis matching and autoindentation in MacOS X version of emacs Date: Wed, 17 Dec 2008 16:29:00 +0000 Message-ID: <20081217162900.GA7290@muc.de> References: <49463d12$0$4789$9b536df3@news.fv.fi> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1229530478 14568 80.91.229.12 (17 Dec 2008 16:14:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2008 16:14:38 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 17 17:15:42 2008 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LCz3U-0008NK-8K for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Dec 2008 17:15:24 +0100 Original-Received: from localhost ([127.0.0.1]:38378 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCz2H-000152-V3 for geh-help-gnu-emacs@m.gmane.org; Wed, 17 Dec 2008 11:14:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCz1w-000134-EA for help-gnu-emacs@gnu.org; Wed, 17 Dec 2008 11:13:48 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCz1v-00012J-Tx for help-gnu-emacs@gnu.org; Wed, 17 Dec 2008 11:13:48 -0500 Original-Received: from [199.232.76.173] (port=50403 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCz1v-00011p-Lc for help-gnu-emacs@gnu.org; Wed, 17 Dec 2008 11:13:47 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:2869 helo=mail.muc.de) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LCz1u-0005Yk-VP for help-gnu-emacs@gnu.org; Wed, 17 Dec 2008 11:13:47 -0500 Original-Received: (qmail 15144 invoked by uid 3782); 17 Dec 2008 16:13:39 -0000 Original-Received: from acm.muc.de (pD9E52E1B.dip.t-dialin.net [217.229.46.27]) by colin2.muc.de (tmda-ofmipd) with ESMTP; Wed, 17 Dec 2008 17:13:35 +0100 Original-Received: (qmail 7895 invoked by uid 1000); 17 Dec 2008 16:29:00 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Delivery-Agent: TMDA/1.1.5 (Fettercairn) X-Primary-Address: acm@muc.de X-detected-operating-system: by monty-python.gnu.org: FreeBSD 4.6-4.9 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:60736 Archived-At: 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).