Re: [PATCHv4] Vimrc config with GNU formatting

[Segher Boessenkool <segher@kernel.crashing.org>]

On Thu, Sep 18, 2014 at 12:40:08PM +0400, Yury Gribov wrote:
> When typing 'make .local.vimrc' in GCC build directory one would expect
> .local.vimrc to be created at the root of build directory, not srcdir.

Yes, you would not expect it to do anything to your source dir, ever :-)

> >> +" To enable this for GCC files by default, install thinca's vim-localrc
> >> +" plugin and do
> >> +"   $ make .local.vimrc
> >
> > No, we should *not* advertise an "enough rope" solution without 
> mentioning
> > it *will* kill you.
> 
> How about adding a disclaimer? E.g. "beware that Vim plugins are a 
> GAPING SECURITY HOLE
> so use the at YOUR OWN RISK". (And note that Braun's plugin does use 
> sandboxes).

This *particular* plugin is suicidal.  Most plugins are just fine.

> > Or not mention it at all.  Esp. since your next option
> > has all the same functionality and more.
> 
> It lacks very important functionality: user has to specify path
> to concrete GCC source tree when adding the autocmd.

I was talking about mbr's plugin here :-)

> I have a dozen of trees on my box and I regularly rename, move or copy them.
> With plugins one doesn't have to bother fixing paths in ~/.vimrc
> which is important for productivity.

And  :au bufread ~/src/gcc/* ...  works for me.  To each their own.

> >> +" Or if you dislike plugins, add autocmd in your ~/.vimrc:
> >> +"   :au BufNewFile,BufReadPost path/to/gcc/* :so 
> path/to/gcc/contrib/vimrc
> >
> > There are many more reasons than just "dislike of plugins" to prefer
> > something like this.  For one thing, many Vim users will have many
> > similar statements in their config _already_.
> 
> So "if you don't want to use plugins"?

Just mention it as another option?  Something like
"You can add these options to your .vimrc; or you can :source this script
file; or do either with an :autocmd; or use e.g. the <name of plugin here>
plugin <some vim.org url>".  Don't say "do X if Y"; let people decide for
themselves what fits their situation best.

> >> +" Or just source file manually every time if you are masochist:
> >> +"   :so path/to/gcc/contrib/vimrc
> >
> > How is that masochist?  Typing that cino by hand though, now that would
> > qualify ;-)
> 
> Note that user has to type source command for every newly opened file.
> This indeed looks inconvenient (to me again).

Well for most people it is justt ":so contrib/vimrc".  Or just ":lo" if
you're talking about crazy people with views.

> >> +    setlocal 
> cinoptions=>2s,n-s,{s,^-s,:s,=s,g0,f0,hs,p2s,t0,+s,(0,u0,w1,m0
> >
> > If you write this as absolute numbers instead of as shift widths, you 
> do not
> > need to force sw and sts settings down people's throat.  It might also be
> > easier to read?  Well I doubt that, but it will be slightly shorter 
> at least.
> 
> IMHO matching shiftwidth with GNU indent may be useful.
> E.g. Vim won't reindent when you start editing an empty line and user
> will have to insert indents manually.
> 
> Also replacing offsets with numbers hides the fact
> that they are based on GNU shiftwidth.

I have no idea what you mean with "matching with GNU indent", sorry.
I was suggesting you could write it as
:set cino=>4,n-2,{2,^-2,:2,=2,g0,f0,h2,p4,t0,+2,(0,u0,w1,m0
and you'd be independent of sw setting.  The coding standard says
"indent two spaces" etc. anyway.

And yeah sw=2 does make sense for editing GCC, if you are used to sw=2
that is.  The point is that the sw setting has nothing to do with what
your text will look like, only with what keys you press.

> >> +    setlocal textwidth=79
> >
> > The coding conventions say maximum line length is 80.
> 
> From https://www.gnu.org/prep/standards/html_node/Formatting.html : 
> "Please keep the length of source lines to 79 characters or less, for 
> maximum readability in the widest range of environments."

There is a doc on gcc.gnu.org as well, which describes many more details.

> Now we rarely do violate textwidth in our codes,

"rarely"?  Ho hum.  There are many worse formatting errors, of course.
And how much do those matter _really_.

> > And you do not enable "t" (also
> > on by default), so you do not want to wrap text anyway?  Confused now.
> 
> Me as well, the original config author did it that way. IMHO +t makes 
> sense here.

It is certainly more consistent.


Segher