On Mon, Sep 17, 2018 at 07:18:50PM -0400, Taylor Blau wrote:
> Hi brian,
> 
> Thanks for CC-ing me on this.
> 
> I use editorconfig every day via the configuration in my home directory
> [1], and the Vim plugin editorconfig-vim [2]. It's a great piece of
> software, and I've been using it without any issue since around the
> beginning of 2015.

Yeah, I noticed it in your dotfiles.

> In all *.[ch] files in git.git, I found a total of 817 lines over 79
> characters wide:
> 
>   $ for file in $(git ls-files '**/*.[ch]'); do
>       awk 'length > 79' $f;
>     done | wc -l
> 
> So I think that specifying indent_style, and tab_width to be 'tab' and
> '8' respectively is enough. We shouldn't be enforcing a rule about line
> lengths that we are not ourselves consistently following.

I must admit that some of these are my fault.  I think we're moving to
use clang-format more as a tool, so hopefully those become less of an
issue over time.

> Have you thought about including guidelines on COMMIT_EDITMSG? We prefer
> 72 characters per line [3], and this is enforceable via the following:
> 
>   [COMMIT_EDITMSG]
>   max_line_length = 72

That's an interesting thought.  I know different people have different
settings for this: 70, 72, 74.  72 characters is typical for emails, and
since our commits end up as emails, I think standardizing on 72 would
make sense.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204