The entries in vim.current.buffer appear to be decoded strings, which
means that python3 won't allow invoking 'decode' on them. Keep the old
behavior when running under python2, but skip the error-inducing decode
step with python3..
llvm-svn: 289308
clang-format.py currently seems to treat vim.current.buf as ascii-encoded data,
which leads to an UnicodeDecodeError when trying to format any text containing
non-ascii characters:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File ".../tools/clang/tools/clang-format/clang-format.py", line 110, in <module>
main()
File ".../tools/clang/tools/clang-format/clang-format.py", line 87, in main
stdout, stderr = p.communicate(input=text.encode(encoding))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 3996: ordinal not in range(128)
llvm-svn: 284988
clang-format.py previously only worked in vim compiled against python2.
This patch adds the necessary syntax changes to make this work with vim
linked against python3, which is now shipped by default for at least Ubuntu16 and Arch.
Differential Revision: https://reviews.llvm.org/D23319
Subscribers: cfe-commits
llvm-svn: 280240
This has seen quite some usage and I am not aware of any issues. Also
add a style option to enable/disable include sorting. The existing
command line flag can from now on be used to override whatever is set
in the style.
llvm-svn: 253202
To implement this nicely, add a function that merges two sets of
replacements that are meant to be done in sequence. This functionality
will also be useful for other applications, e.g. formatting the result
of clang-tidy fixes.
llvm-svn: 248367
When clang-format encounters a syntax error, it will not format that
line; we're now using the same mechanism we're already using in emacs to
show a helpful error message to the user.
llvm-svn: 238823
With this patch, clang-format.py will search and use existing .clang-format
file if there is one and fallback to the specific format style if
not. It should cover the projects which don't have .clang-format
files in their source. As the option fallback-style is available in
clang 3.5 or later, it is safe to use.
Patch by "Chilledheart" (http://reviews.llvm.org/D8489).
llvm-svn: 235080
If g:clang_format_path is set in the vimrc, that path will take precedence over
the hard coded path (which is reliant on the PATH environment variable). This
provides an easy mechanism for switching the selected clang-format binary during
development.
llvm-svn: 221108
Improve the documentation for vim integration of clang-format. Prefer the use
of <c-o> to do the normal mode command execution to avoid side-effects of the
escape and re-insertion (cursor movement). Tweak the macros to use a double
return to avoid having to manually return control to the editor from the
subprocess.
llvm-svn: 220685
With -style=file, clang-format now starts to search for a .clang-format
file starting at the file given with -assume-filename if it reads from
stdin. Otherwise, it would start searching from the current directory,
which is not helpful for editor integrations.
Also changed vim, emacs and sublime integrations to actually make use of
this flag.
This fixes llvm.org/PR17072.
llvm-svn: 190691
Dotfiles are impractical on Windows. This makes clang-format search
for the style configuration file as '_clang-format' in addition to
the usual '.clang-format'. This is similar to how VIM searches for
'_vimrc' on Windows.
Differential Revision: http://llvm-reviews.chandlerc.com/D1629
llvm-svn: 190413
fallback syntax used when we fail to find a '.clang-format' file. Adjust
variable names appropriately.
Update the editor integration pieces that specify a '-style' option to
specify it as '-style=file'. I left the functionality in place because
even if the preferred method is to use '.clang-format' files, this way
if someone needs to clobber the style in their editor we show how to do
so in these examples.
Also check in a '.clang-format' file for Clang to ensure that separate
checkouts and builds of Clang from LLVM can still get the nice
formatting. =] This unfortunately required nuking the test for the
absence of a '.clang-format' file as now the directory happening to be
under your clang source tree will cause there to always be a file. ;]
llvm-svn: 189741
After the first operation, the buffer contents has changed and thus all
other operations would be invalid. Executing the operations in reversed
order should fix this.
llvm-svn: 186840
With this fix, only changed regions will be replaced in vim's buffer.
Thereby, marks should mostly be left intact. Furthermore, this is a
better fix for the performance problem in conjunction with
'foldmethod=syntax' (see r186660).
llvm-svn: 186789
The previous line-by-line replacement causes vim to take a long time if
the foldmethod is set to 'syntax'. This should significantly improve
performance in that case.
llvm-svn: 186660
With this patch, clang-format will try to keep the cursor at the
original code position in editor integrations (implemented for emacs and
vim). This means, after formatting, clang-format will try to keep the
cursor on the same character of the same token.
llvm-svn: 182373
This adds an emacs editor integration (thanks to Ami Fischman). Also
pulls out the style into a variable for the vi integration and just
uses clang-formats defaults style in clang-format-diff.py.
llvm-svn: 179098
Vedant Kumar