On Wed, Mar 20, 2019 at 6:44 PM Wayne Stambaugh <stambau...@gmail.com> wrote:
> It looked like in the example that Brian posted the indent was more than > eight spaces but that may have been a font spacing issue. I'm fine with > eight spaces as the continuation indent. Hmm, you're right, I didn't notice that. It seems clang-format "compensates" for the alignment of other declarations in the block: static LIB_TEXT* loadText( std::unique_ptr<LIB_PART>& aPart, LINE_READER& aReader, int aMajorVersion, int aMinorVersion ); static LIB_RECTANGLE_but_long* loadRectangle( std::unique_ptr<LIB_PART>& aPart, LINE_READER& aReader, int aMajorVersion, int aMinorVersion ); I'm not sure why this is, or if it's by bug or design in clang-format. However, this does only happen when you have declarations with no spaces between then. Adding newlines gets: static LIB_TEXT* loadText( std::unique_ptr<LIB_PART>& aPart, LINE_READER& aReader, int aMajorVersion, int aMinorVersion ); static LIB_RECTANGLE_but_long* loadRectangle( std::unique_ptr<LIB_PART>& aPart, LINE_READER& aReader, int aMajorVersion, int aMinorVersion ); The coding policy specifies 1 line spacing above declarations with Doxygen comments, and 2 above "bare" declarations like these. So this bug/quirk/feature should rarely be encountered. So the original code here is wrong. Of course, it always pays to be careful with the auto-formatter - I normally get the editor to do most of it, and then manually check changes with "git clang-format --diff" if I get a commit failure for formatting. Normally a botched space-in-parens, for me! Cheers, John _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp