[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#21409: 24.5; Wrong syntactic information for two line statement in a
From: |
Alan Mackenzie |
Subject: |
bug#21409: 24.5; Wrong syntactic information for two line statement in an arglist |
Date: |
Sat, 12 Mar 2022 11:32:50 +0000 |
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).