From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: npostavs@users.sourceforge.net Newsgroups: gmane.emacs.bugs Subject: bug#24195: 25.0.95; Wrong indentation after a 'less < than' comparison (c++-mode) Date: Wed, 24 Aug 2016 21:24:43 -0400 Message-ID: <87fupttzc4.fsf@users.sourceforge.net> References: <86a8glhsk3.fsf@gmail.com> <20160811121421.GA3753@acm.fritz.box> <877fbm7wpm.fsf@linux-m68k.org> <87inuyuvip.fsf@users.sourceforge.net> <20160822110802.GB2571@acm.fritz.box> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1472088324 20808 195.159.176.226 (25 Aug 2016 01:25:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 25 Aug 2016 01:25:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: Arash , Andreas Schwab , 24195@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 25 03:25:20 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bcjQ0-00050X-0C for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Aug 2016 03:25:20 +0200 Original-Received: from localhost ([::1]:54043 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcjPx-0005dC-Aj for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Aug 2016 21:25:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcjPm-0005Vq-MP for bug-gnu-emacs@gnu.org; Wed, 24 Aug 2016 21:25:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bcjPi-0002Du-Fr for bug-gnu-emacs@gnu.org; Wed, 24 Aug 2016 21:25:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41816) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bcjPi-0002Dn-CV; Wed, 24 Aug 2016 21:25:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bcjPi-0007SS-40; Wed, 24 Aug 2016 21:25:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 25 Aug 2016 01:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24195 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: Original-Received: via spool by 24195-submit@debbugs.gnu.org id=B24195.147208827628634 (code B ref 24195); Thu, 25 Aug 2016 01:25:02 +0000 Original-Received: (at 24195) by debbugs.gnu.org; 25 Aug 2016 01:24:36 +0000 Original-Received: from localhost ([127.0.0.1]:39528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bcjPH-0007Rg-KC for submit@debbugs.gnu.org; Wed, 24 Aug 2016 21:24:35 -0400 Original-Received: from mail-it0-f49.google.com ([209.85.214.49]:37926) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bcjPE-0007RO-DX; Wed, 24 Aug 2016 21:24:33 -0400 Original-Received: by mail-it0-f49.google.com with SMTP id n128so66321530ith.1; Wed, 24 Aug 2016 18:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=4G1HGcCBE8ShndLSnph2RcZl63rMg0+43yvQLt3C6SI=; b=ukRz7RyVbXK3IlKm83nR8QTgNHHuP/dkuNTqBD7pUZ4f2JPcGkR180iqVH3qpyQWQe MqBdIkAWIuMHKjlKzxqjDdb2fg4G26LhP+9ItvsMt8Ad24C9MnF4R4Qrm6QiQ57BvT92 CCApLfqvHgtVpHNNWAhSWtGH4afhQzRYvAlTgYpR3bAEPJP7zmr2+SyuBgfyakEY4WF6 qw23Msewo35WSJqo6gVOhO2Fvfn5HgVgOX4JGdyIIAj7XKdtRxBpagoBhh8K/b+Rxsf2 FEZ7DQTmdHbA0nRc0biSaMdxr57NExFZAOyhB57Z8sZcFpMuwbcAE2hZ8EZq7gFhgV/P 9fTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=4G1HGcCBE8ShndLSnph2RcZl63rMg0+43yvQLt3C6SI=; b=BHxnA3Jq3F1W/b6p1/teWgQ+et63uxry1kqRHl7QV5FcqXpcz2776mPzGedW+Pr0hc SHn6QLvIcwg3jmDX41MAnDDa5kVzFYcSaQ7mxNW+3azs9smFui0BpgpUfIjm77fCHPOw tGIkDRQDq0S1bGc75BsQ/Ny/dEWur/NaDlrZ9jsyDiGdYqA3m6z+jscMsjvlL0qdoU+L zRAaM4vJdLd7kSnaSofZXaifrqh0o5BO7ZvHZDANQROt3/fKEiY8LMwaSzbgebUU0Efi t3PdtE2uyR+QmgQPW19HytqBjTA/yIi/tW7rt+MSdzKizBj9jbFpU3ZJiRg9YijLrhZR PyBg== X-Gm-Message-State: AE9vXwOg/utYO1oDMQ60zOW9hsmZ3/pUAiV6nhfUQqQNFWwuE6S6JHWTpjRb8YqTmoyK9g== X-Received: by 10.36.10.145 with SMTP id 139mr2180814itw.68.1472088266809; Wed, 24 Aug 2016 18:24:26 -0700 (PDT) Original-Received: from zony ([45.2.7.130]) by smtp.googlemail.com with ESMTPSA id o201sm4522161iod.16.2016.08.24.18.24.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Aug 2016 18:24:26 -0700 (PDT) In-Reply-To: <20160822110802.GB2571@acm.fritz.box> (Alan Mackenzie's message of "Mon, 22 Aug 2016 11:08:02 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:122615 Archived-At: tags 24195 wontfix quit Alan Mackenzie writes: >> So could we say "<" can't be a template opener when it comes after a >> close paren except for the close paren of "operator()"? > > We could, but I can't see it helping very much (though it might help a > little bit). > > There are probably quite a lot of special cases like that where it is > possible to say for sure that the "<" does/doesn't introduce a template > construct. But that will leave a lot of ambiguous cases. The more we > try to analyse these, the closer we get to building a compiler inside CC > Mode. For example, the example given might have been "k < l() && ....", > leaving no syntactic clues about the templateicity of "<". > > Analysing the C++ syntax to determine these determinable cases would be > a lot of work, and it would be a lot of work to implement it, too. > > The C++ standards people haven't thought it worthwhile to preserve > unambigious syntax in their language, so there is no way CC Mode can get > it right every time. Makes sense, I've been out of C++ for some time, so I kind of forgot how ridiculous the syntax is. Marking as wontfix.