[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14008: Better autoindent for C++11 code?
From: |
Alan Mackenzie |
Subject: |
bug#14008: Better autoindent for C++11 code? |
Date: |
Thu, 7 Nov 2019 18:19:40 +0000 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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).