Menu
▾
▴
cc-mode-help
|
From: Glenn M. <rg...@gn...> - 2015-02-16 19:10:18
|
Simon wrote: > Severity: important Unless it leads to invalid code (eg Python-style languages), I tend to think of indentation bugs as minor problems, since it's just cosmetic. Why do you think this one is important? |
|
From: Glenn M. <rg...@gn...> - 2015-02-17 19:24:12
|
In Emacs, we traditionally reserve severity > normal for failure to build, security issues etc. So I'll downgrade this to normal, but don't worry, because I have seen very little evidence that the severity makes any difference to whether something gets fixed. :), and :( too. |
|
From: Simon <tur...@gm...> - 2015-02-17 19:40:27
|
> In Emacs, we traditionally reserve severity > normal for failure to > build, security issues etc. So I'll downgrade this to normal, but don't > worry, because I have seen very little evidence that the severity makes > any difference to whether something gets fixed. :), and :( too. Sounds good. Thank you Glenn. I hope someone can look into this within a year or two. Ideally, before C++17 becomes a reality and swizzles the syntax further with its "concepts lite" and other features. I also noticed some more strange indentation cases with nested constructor initialization lists. I'll be available to test any improvements made and provide more test cases if needed. Thanks again. |
|
From: Stefan K. <st...@ma...> - 2020-11-23 14:15:28
|
Simon <tur...@gm...> writes:
> Initializer lists use curly braces, but their contents do not indent properly with emacs' c++-mode.
> In short, one may use an initializer list to declare and initialize a vector of integers as such:
> std::vector<int> Foo( { 1, 2, 3, 4, 5 } );
>
> Problems arise when the elements of the list span on multiple line and it gets even worse when the elements are lambda-expressions
> and nested initializer lists.
> The following code illustrate most cases and related situations. The code below compiles without error or warning with gcc 4.8.3.
I had a look at the fairly long example provided here, and AFAICT, the
indentation is incorrect in the below cases (trimmed down from the
original). Some of the examples of incorrect indentation were already
fixed.
Alan, could you perhaps take a look at this and see if this is something
that is fixable? Thanks in advance.
#include <vector>
#include <functional>
namespace emacs_initlist_indentation_bug {
struct DEF {
int d, //
e, // indented from "int" + 2
f; //
};
struct GHI {
int //
g, // indented from "int" +0
h, // indented from "int" + 2
i; //
};
void f4 (int a, int b, int c)
{
std::vector<ABC> abcList2( // Source of
alignment for closing ")" below
{{a+6,
b+6,
c+6}
} //
); /* Somehow, this
one aligns with first line's comment position!! */
}
lambda_initlist_bug.push_back( //
[](int p) // OK, text-book indentation
{ //
return p+p; //
} //
); /* Aligned with
first comment! */
}
}
|
|
From: Alan M. <ac...@mu...> - 2025-03-11 20:16:22
|
Hello, Stefan.
On Tue, Mar 11, 2025 at 09:54:20 -0700, Stefan Kangas wrote:
> Stefan Kangas <ste...@gm...> writes:
> > Simon <tur...@gm...> writes:
> >> Initializer lists use curly braces, but their contents do not indent properly with emacs' c++-mode.
> >> In short, one may use an initializer list to declare and initialize a vector of integers as such:
> >> std::vector<int> Foo( { 1, 2, 3, 4, 5 } );
> >> Problems arise when the elements of the list span on multiple line and it gets even worse when the elements are lambda-expressions
> >> and nested initializer lists.
> >> The following code illustrate most cases and related situations. The code below compiles without error or warning with gcc 4.8.3.
> > I had a look at the fairly long example provided here, and AFAICT, the
> > indentation is incorrect in the below cases (trimmed down from the
> > original). Some of the examples of incorrect indentation were already
> > fixed.
> > Alan, could you perhaps take a look at this and see if this is something
> > that is fixable? Thanks in advance.
> Alan, any chance you could look into the below cases? Thanks in advance.
Yes, I'll do this. Sorry I never replied to your post in 2020. I
started looking at the bug then, but somehow didn't get very far with it.
Maybe it was because there were so many individual glitches in the
report. Thanks for distilling the cases which still remain unfixed.
[ .... ]
--
Alan Mackenzie (Nuremberg, Germany).
|
|
From: Alan M. <ac...@mu...> - 2025-03-27 10:43:21
|
Hello, Stefan. On Tue, Mar 11, 2025 at 16:23:13 -0400, Stefan Kangas wrote: > Alan Mackenzie <ac...@mu...> writes: > > Yes, I'll do this. Sorry I never replied to your post in 2020. I > > started looking at the bug then, but somehow didn't get very far with it. > > Maybe it was because there were so many individual glitches in the > > report. Thanks for distilling the cases which still remain unfixed. > Thanks! I've just committed a fix (a ~700 line patch ;-), so I think this bug is finally solved. I'm closing the bug with this post. -- Alan Mackenzie (Nuremberg, Germany). |
|
From: Stefan K. <ste...@gm...> - 2025-04-10 00:55:31
|
Alan Mackenzie <ac...@mu...> writes: > I've just committed a fix (a ~700 line patch ;-), so I think this bug is > finally solved. Thank you! |
|
From: Mattias E. <mat...@gm...> - 2025-04-17 13:44:26
|
Thank you for fixing this. A minor oversight in the committed patch, in cc-align.el:
351 (skip-syntax-backward " \t([{" (c-point 'boi))
This call should probably use `skip-char-backward`, because `\t`, `[`, and `{` aren't syntax chars.
It currently works by accident because of the ` ` and `(` syntax classes.
|
|
From: Alan M. <ac...@mu...> - 2025-04-21 20:36:34
|
Hello, Mattias.
On Thu, Apr 17, 2025 at 15:42:59 +0200, Mattias Engdegård wrote:
> Thank you for fixing this. A minor oversight in the committed patch, in cc-align.el:
> 351 (skip-syntax-backward " \t([{" (c-point 'boi))
> This call should probably use `skip-char-backward`, because `\t`, `[`, and `{` aren't syntax chars.
> It currently works by accident because of the ` ` and `(` syntax classes.
Thanks for spotting this and telling me about it. I'll get around to
fixing it in the next few days.
--
Alan Mackenzie (Nuremberg, Germany).
|
|
From: Alan M. <ac...@mu...> - 2025-04-30 18:59:25
|
Hello again, Mattias.
On Mon, Apr 21, 2025 at 20:35:22 +0000, Alan Mackenzie wrote:
> On Thu, Apr 17, 2025 at 15:42:59 +0200, Mattias Engdegård wrote:
> > Thank you for fixing this. A minor oversight in the committed patch, in cc-align.el:
> > 351 (skip-syntax-backward " \t([{" (c-point 'boi))
> > This call should probably use `skip-char-backward`, because `\t`, `[`, and `{` aren't syntax chars.
> > It currently works by accident because of the ` ` and `(` syntax classes.
> Thanks for spotting this and telling me about it. I'll get around to
> fixing it in the next few days.
DONE.
--
Alan Mackenzie (Nuremberg, Germany).
|
|
From: Mattias E. <mat...@gm...> - 2025-05-15 18:44:15
|
30 apr. 2025 kl. 20.58 skrev Alan Mackenzie <ac...@mu...>: > DONE. Thank you! |
|
From: Simon <tur...@gm...> - 2015-02-16 19:30:16
|
On Mon, Feb 16, 2015 at 2:09 PM, Glenn Morris <rg...@gn...> wrote: > Simon wrote: > >> Severity: important > > Unless it leads to invalid code (eg Python-style languages), I tend to > think of indentation bugs as minor problems, since it's just cosmetic. > Why do you think this one is important? I am inclined to follow your lead. C++ code compiles without errors as I mentioned. The bug affects "c++-mode" and since c++-mode mostly (solely?) affects cosmetics, then the bug makes c++-mode difficult to use. In fact, I have been searching for alternatives, in vain. I would suggest keeping severity as "important" if this report can be assigned more precisely to the "c++-mode" sub-package or group. If not, then you may downgrade to "minor" as you said. |
|
From: Daniel C. <da...@da...> - 2015-02-16 21:39:17
Attachments:
signature.asc
|
On 02/16/2015 11:29 AM, Simon wrote: > On Mon, Feb 16, 2015 at 2:09 PM, Glenn Morris <rg...@gn...> wrote: >> Simon wrote: >> >>> Severity: important >> >> Unless it leads to invalid code (eg Python-style languages), I tend to >> think of indentation bugs as minor problems, since it's just cosmetic. >> Why do you think this one is important? > > I am inclined to follow your lead. C++ code compiles without errors > as I mentioned. > > The bug affects "c++-mode" and since c++-mode mostly (solely?) affects > cosmetics, then the bug makes c++-mode difficult to use. In fact, I > have been searching for alternatives, in vain. > > I would suggest keeping severity as "important" if this report can be > assigned more precisely to the "c++-mode" sub-package or group. If > not, then you may downgrade to "minor" as you said. OP, your best bet is to dive into cc-engine.el and fix it yourself. |
|
From: Daniel C. <da...@da...> - 2015-02-16 21:04:14
Attachments:
signature.asc
|
On 02/16/2015 11:09 AM, Glenn Morris wrote: > Simon wrote: > >> Severity: important > > Unless it leads to invalid code (eg Python-style languages), I tend to > think of indentation bugs as minor problems, since it's just cosmetic. > Why do you think this one is important? Indentation bugs are infuriating because I use electric mode, which means that even if I fix the indentation, the fixes are undone automatically. |
Thanks for helping keep SourceForge clean.
X