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
