<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 17, 2013 at 3:12 PM, Steffen Prohaska <span dir="ltr"><<a href="mailto:prohaska@zib.de" target="_blank" class="cremed">prohaska@zib.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sep 17, 2013, at 10:10 AM, Daniel Jasper <<a href="mailto:djasper@google.com" class="cremed">djasper@google.com</a>> wrote:<br>

<br>
> 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?<br>
<br>
</div>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.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> I think the capabilities to configure the plugin with global variables is obvious, but it seems unrelated to this being loaded as a module.<br>
<br>
</div>True, and maybe it's not worth breaking compatibility.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> + #     let g:clang_format_style = '{ BasedOnStyle: llvm, IndentWitdh: 4 }'<br>
> IndentWidth..<br>
<br>
</div>Thanks.  Fixed.<br>
<div class="im"><br>
<br>
> +  # Use g:clang_format_binary or default 'clang-format'.<br>
> +  binary = vim.eval(<br>
> +    'exists("g:clang_format_binary") ? g:clang_format_binary : "clang-format"')<br>
><br>
> 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.<br>

<br>
</div>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.<br>
</blockquote><div><br></div><div>Looks good to me. If nobody else has objections, I will experiment a bit with it (probably tomorrow) and the check it in.</div><div><br></div><div>Thanks for working on this!</div><div>Cheers,</div>
<div>Daniel</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Suggested commit message:<br>
<br>
'''<br>
clang-format (vim): Support configuration via vim vars and import as module<br>
<br>
'clang-format.py' can now be configured via vim variables<br>
'g:clang_format_binary' and 'b:clang_format_style' or<br>
'g:clang_format_style'.  Using vim variables is more flexible than<br>
<div class="im">hard-coded values in the Python script.  For example, the style can be<br>
changed from vim on-the-fly without modifying the Python script.<br>
<br>
</div>Furthermore, 'clang-format.py' can now alternatively be imported and<br>
used as a Python module.  The change is backward compatible.  When used<br>
as a module, the style can explicitly specified when calling the<br>
format() function.<br>
<div class="im"><br>
Note also that unnamed buffers are now properly handled.  Previously, a<br>
Python exception was raised for unnamed buffers by subprocess.Popen,<br>
because it was called with None for <a href="http://vim.current.buffer.name" target="_blank" class="cremed">vim.current.buffer.name</a>.<br>
<br>
The implementation should work with vim 7.1 and later (maybe even 7.0).<br>
It has been tested with 7.2.330 (Ubuntu 10.04), 7.3.429 (Ubuntu 12.04),<br>
and MacVim 7.4.<br>
</div>'''<br>
<span class="HOEnZb"><font color="#888888"><br>
        Steffen<br>
<br>
</font></span></blockquote></div><br></div></div>