bug#14008: Better autoindent for C++11 code?

[Alan Mackenzie]

Hello, Stefan.

On Sun, Nov 03, 2019 at 14:29:13 +0100, Stefan Kangas wrote:
> Hi Alan,

> Alan Mackenzie <acm@muc.de> writes:

> >> > C++11 introduced lambda syntax []() { ... } and other strange things 
> >> > that Emacs indents strangely.

> >> > for_each(range.begin(), range.end(), [=](int i) {
> >> >     cout << strings[i] << endl;
> >> >   });

> >> > I would like the final line `});` to have the same indentation level
> >> > as the first line `for_each...`.

> >> I'm seeing the same thing here.

> > I think this is the minimum indentation imposed on all lines within "code
> > blocks" in "gnu" style.  (See the CC Mode manual for a description of CC
> > Mode's style system.)  If you indent the for_each line by, say, 4 columns
> > (put it inside braces if needed) the line with }); then gets indented
> > under the for_each.  As for_each is a function (pretty much equivalent to
> > Lisp's mapc), it's unlikely to be put at column 0 in real source code.

> Indeed.  It seems to work better when you put it in a function.

> >> > Here's another example:

> >> > for_each(range.begin(), range.end(), [&](int i) {
> >> >              std::async(
> >> >                         launch::async,
> >> >                         [&]() { strings[i] = fizzy(i); }
> >> >                         );
> >> >   });

> >> > The arguments to std::async and its closing parenthesis are indented
> >> > much too far; I would like them indented only one level further than
> >> > where std::async is itself indented. Any tips for achieving this?

> > Configure CC Mode, either by activating a different style (with C-c ., or
> > M-x c-set-style if some minor mode is using that key binding), or by
> > directly setting syntactic symbols' "offsets".
> [...]
> > Again, I strongly recommend reading the relevant pages in the CC Mode
> > manual.
> [...]
> >> Perhaps Alan could clarify if this is a bug or if this is just a case
> >> of missing configuration?

> > A bit of a mixture of both, I think.

> Do you think there is anything more to do here, or should this bug be
> closed?

I think the bug should now be closed.

> Best regards,
> Stefan Kangas

-- 
Alan Mackenzie (Nuremberg, Germany).