bug#21409: 24.5; Wrong syntactic information for two line statement in an arglist

[Alan Mackenzie <acm@muc.de>]

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 <larsi@gnus.org> wrote:

> > Gulshan Singh <gsingh2011@gmail.com> 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).