From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#21409: 24.5; Wrong syntactic information for two line statement in an arglist Date: Sat, 12 Mar 2022 11:32:50 +0000 Message-ID: References: <87eek7taft.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32370"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Lars Ingebrigtsen , 21409@debbugs.gnu.org To: Gulshan Singh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 12 12:33:40 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nT00B-0008C3-Hh for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Mar 2022 12:33:39 +0100 Original-Received: from localhost ([::1]:36672 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nT00A-0000PH-Fy for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 12 Mar 2022 06:33:38 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56674) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nSzzb-0000P8-0s for bug-gnu-emacs@gnu.org; Sat, 12 Mar 2022 06:33:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45425) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nSzza-0005mw-Cx; Sat, 12 Mar 2022 06:33:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nSzza-0004im-25; Sat, 12 Mar 2022 06:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sat, 12 Mar 2022 11:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21409 X-GNU-PR-Package: emacs,cc-mode Original-Received: via spool by 21409-submit@debbugs.gnu.org id=B21409.164708478118145 (code B ref 21409); Sat, 12 Mar 2022 11:33:02 +0000 Original-Received: (at 21409) by debbugs.gnu.org; 12 Mar 2022 11:33:01 +0000 Original-Received: from localhost ([127.0.0.1]:39322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nSzzZ-0004iW-4s for submit@debbugs.gnu.org; Sat, 12 Mar 2022 06:33:01 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:34897 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1nSzzW-0004iH-GT for 21409@debbugs.gnu.org; Sat, 12 Mar 2022 06:32:59 -0500 Original-Received: (qmail 82625 invoked by uid 3782); 12 Mar 2022 11:32:51 -0000 Original-Received: from acm.muc.de (p2e5d5b32.dip0.t-ipconnect.de [46.93.91.50]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 12 Mar 2022 12:32:51 +0100 Original-Received: (qmail 7457 invoked by uid 1000); 12 Mar 2022 11:32:50 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:228247 Archived-At: Hello, Gulshan. Sorry I missed your bug report back in 2015. On Fri, Mar 11, 2022 at 17:52:38 -0800, Gulshan Singh wrote: > I know this is an old bug report, but I just realized it got a response, > and it seems like the behavior hasn't changed. Also, a big thank you for cutting the C fragment down to an easy to work with minimum. > On Thu, Dec 3, 2020 at 3:07 AM Lars Ingebrigtsen wrote: > > Gulshan Singh writes: > > > In c-mode (and all derivatives), the following code has the wrong > > > syntactic information (at least, in my opinion): > > > foo(bar > > > .baz() > > > .qux()); > > > Putting point at `.baz()` and pressing C-c C-s shows it as an > > > `arglist-cont-nonempty`, when I'd expect it to be a > > > `statement-cont`. I'm afraid I can't agree with you here. The bar.baz().qux() is an expression, not a statement, as it is lacking the terminating ; which would make it a statement. I think the arglist-cont-nonempty is correct. It is more specific than statement-cont, which could only have the start of foo as its anchor position. > > > This causes the code to have the wrong indentation, as above I > > > would like to have the continued statements to be indented one > > > c-basic-offset, not aligned to the opening brace. I think the best solution to the problem would be to write a new Line-Up function for this particular scenario, and to make it available to users to insert into the c-offsets-alist entry for arglist-cont-nonempty. The page "Customizing Indentation" in the CC Mode manual is pertinent here. But first, we need to firm up the specification. What, precisely, will trigger this new Line-Up function? What about the struct members not being functions: foo(bar .baz .qux); ? What about the . operator being at the end of the previous line: foo(bar. baz(). qux()); ? What is the primary construct which should trigger the new Line-Up function? Am I right in thinking it's the . operator combined with line breaks, and nothing else? What about, for example, the ? : operators: foo(bar ? baz() : qux()); ? This is getting kind of complicated. ;-) Sorry. > > (This bug report unfortunately got no response at the time.) > > I'm not sure how that should be indented, really -- the current > > indentation looks reasonable to me, I think? > It's definitely reasonable, but it's not what I'd prefer, which would be > this: > foo(bar > .baz() > .qux()); > `.baz()` and `.qux()` are indented two spaces (my value for > `c-basic-offset`) from the start of `bar`, as opposed to aligned with > `bar`. This matches what happens if the call to `foo` isn't there: > bar > .baz() > .qux(); > In any case, regardless of what indentation one would prefer for this case, > the issue remains that `c-show-syntactic-information` should be showing > `statement-cont` instead of `arglist-cont-nonempty` at `.baz()`. -- Alan Mackenzie (Nuremberg, Germany).