[cfe-dev] Slightly improved clang-format vim integration

[Sean Silva]

On Tue, Sep 17, 2013 at 9:22 AM, Daniel Jasper <djasper at google.com> wrote:

>
>
>
> On Tue, Sep 17, 2013 at 3:12 PM, Steffen Prohaska <prohaska at zib.de> wrote:
>
>> On Sep 17, 2013, at 10:10 AM, Daniel Jasper <djasper at google.com> wrote:
>>
>> > So, remind me again, because it seems to have escaped from this
>> discussion: Why is it a benefit to load this as a python module?
>>
>> My main reason was that with Python runtimepath handling (vim >=
>> 7.3.1163), I think it's easier to install and use as a module.
>>
>
> Maybe if someone is used to python modules. Effectively, this is just one
> more line that needs to be put into the .vimrc (or alternatively, this file
> needs to be put into a specific location that one might have to look up).
> Installing by just binding this file to a key seems to be strictly one step
> less.
>
> > I think the capabilities to configure the plugin with global variables
>> is obvious, but it seems unrelated to this being loaded as a module.
>>
>> True, and maybe it's not worth breaking compatibility.
>>
>
> Yeah, we really need to be careful with this. I for one am pushing this
> file to the workstations of many, many developers. Any change where they'd
> need to change their .vimrc would be very tedious.
>

+1 for not breaking compatibility.

-- Sean Silva


>
> > + #     let g:clang_format_style = '{ BasedOnStyle: llvm, IndentWitdh: 4
>> }'
>> > IndentWidth..
>>
>> Thanks.  Fixed.
>>
>>
>> > +  # Use g:clang_format_binary or default 'clang-format'.
>> > +  binary = vim.eval(
>> > +    'exists("g:clang_format_binary") ? g:clang_format_binary :
>> "clang-format"')
>> >
>> > I think we should still default to a constant that is defined higher up
>> in the file, possibly within the introductory paragraph. Yes, it can be
>> configured setting the global options, but in some cases, it might be
>> easier to change an easy to find constant in this file. Same for
>> clang_format_style.
>>
>> How about the attached revision v4?  It's backward compatible.  The
>> defaults for binary and style are specified after the imports.  The binary
>> can be specified in a global vim var.  The style can be specified as an
>> explicit function arg, a buffer-local vim var (useful for autocmd), or a
>> global vim var.  The install instructions are kept simple.  Using a Python
>> module is only mentioned later as an alternative.
>>
>
> Looks good to me. If nobody else has objections, I will experiment a bit
> with it (probably tomorrow) and the check it in.
>
> Thanks for working on this!
> Cheers,
> Daniel
>
> Suggested commit message:
>>
>> '''
>> clang-format (vim): Support configuration via vim vars and import as
>> module
>>
>> 'clang-format.py' can now be configured via vim variables
>> 'g:clang_format_binary' and 'b:clang_format_style' or
>> 'g:clang_format_style'.  Using vim variables is more flexible than
>> hard-coded values in the Python script.  For example, the style can be
>> changed from vim on-the-fly without modifying the Python script.
>>
>> Furthermore, 'clang-format.py' can now alternatively be imported and
>> used as a Python module.  The change is backward compatible.  When used
>> as a module, the style can explicitly specified when calling the
>> format() function.
>>
>> Note also that unnamed buffers are now properly handled.  Previously, a
>> Python exception was raised for unnamed buffers by subprocess.Popen,
>> because it was called with None for vim.current.buffer.name.
>>
>> The implementation should work with vim 7.1 and later (maybe even 7.0).
>> It has been tested with 7.2.330 (Ubuntu 10.04), 7.3.429 (Ubuntu 12.04),
>> and MacVim 7.4.
>> '''
>>
>>         Steffen
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130917/97f9c1a7/attachment.html>