Yes, you're right - I put LF as default option into config, but maybe it
would clash with this settings - I'll comment out it right now.
And I completely agree with you about discussion about SOCI source code
style - we need to define defaults for putting braces, etc. I planned to
start this discussion in my next emails :-)
In my work project we did try to use clang-format, and it worked well, the
main problem was the people's inertia that prevent us from putting it. And
your proposal is very well formulated.
As I know, there should be clang-format integration/plugins for many of
editors/IDEs, so it should be no problem to integrate it into editors, or
maybe as hooks for Git, etc.
On Sun, Sep 10, 2017 at 8:04 PM, Mateusz Loskot <mate...@loskot.net> wrote:
> On 10 September 2017 at 17:58, Alex Ott <alex...@gmail.com> wrote:
> > Hello all
> >
> > I've just merged pull request that adds EditorConfig support for SOCI
> source
> > code.
>
> Thanks Alex.
>
> I wonder if there is need to take care of EOLs.
> I'm quite certain, most if not all of us who develop/build SOCI on Windows
> follow the Git/GitHub guidelines for dealing with EOLs
> https://help.github.com/articles/dealing-with-line-endings/
>
> git config --global core.autocrlf true
>
> and let Git on Windows to autoconvert to CRLF.
>
> This seems to clash with the .editorconfig forcing EOL to LF.
>
> So, perhaps we should also specify EOL for source code and other files
> with .gitattributes and keep it in sync with .editorconfig
>
> Thoughts?
>
> > There is one thing that I want to ask people who currently work on source
> > code - in merged .editorconfig, the configuration
> trim_trailing_whitespace
> > is set to true, meaning that all trailing whitespaces will be removed
> from
> > lines on save. But we may have these trailing whitespace already, and
> > applying this setting to actual source code when working on issues/new
> code
> > will lead to not necessary changes. To avoid this I can do this change
> on
> > whole source code & commit it as one single change, but this may lead to
> not
> > necessary conflicts.
> >
> > Does anybody have not committed changes that may be broken from such
> > cleanup?
>
> Perhaps, this is a good opportunity to discuss SOCI source code style
> and formatting maintenance in long term.
>
> Shortly, perhaps, we could agree together on using clang-format
> I've learned it works for MongoDB.
> I work with largish projects which also benefit from that.
>
> Long story with details about what I'm actually proposing here
> can be found in RFC proposal which I prepared for another project I'm a
> part of.
>
> https://trac.osgeo.org/geos/wiki/RFC4
> (it includes references to MongoDB (detailed!) story about clang-format).
>
> Despite which reformat we agree upon, either whitespaces for .editorconfig
> only
> or the complete using clang-format (which would include the
> .editorconfig one of course),
> I'd vote for one big reformat with single commit.
>
> Thoughts?
>
> Best regards,
> --
> Mateusz Loskot, http://mateusz.loskot.net
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> soci-devel mailing list
> soci-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/soci-devel
>
--
With best wishes, Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)
Skype: alex.ott
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
soci-devel mailing list
soci-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-devel
