On 09/18/2014 09:20 PM, Segher Boessenkool wrote:
> 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 :-)
But that's already the case for some other GCC targets e.g. "make TAGS".
So I'm just following an established practice here.
>>> 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 :-)
Ah, ok. Then I'll mention thinca's plugin as a secondary option with a
disclaimer then.
>>>> +" 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.
Ok.
>>>> +" 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.
For many people that would be a hassle (judging by my colleagues).
> 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.
> ...
> 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.
Depending on whether you treat shiftwidth as "amount of spaces that is
inserted when I press >" or "default indent for a particular class of
files". For example with shiftwidth=2 user could (un)indent block of C
code with < or > which seems to be useful.
> The coding standard says
> "indent two spaces" etc. anyway.
That's what I meant by "matching with GNU indent".
>>>> + 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.
Indeed: "Lines shall be at most 80 columns" (from
https://gcc.gnu.org/codingconventions.html#Line).
-Y
