Comments (12)
What I did to work this around is to copy my .clang-format
fallback at the root of my system. Whether I edit a file in /tmp
, /etc
, /whatever
, it will always end up using /.clang-format
. This is dirty af but it works...
If you have a .clang-format
further down the tree it will be used instead.
from coc-clangd.
There are two issues here, mostly inherited from clang-format itself:
- FallbackStyle cannot be a custom style definition, it has to be a predefined style.
- If FallbackStyle doesn't correspond to a predefined style, style detection fails, even in the presence of a .clang-format file.
The first issue limits users ability to define a custom "global" fallback for format style to clangd. We can extend FallbackStyle handling in clang-format to accept custom ones. That's not the case currently probably because they don't want to parse the fallback configuration string at every call(but they are happy to read it from file and parse it again ?!?). But we can overcome this by parsing it once on the caller side and taking a pre-built FallbackStyle, rather than a string one. In addition to that, we might want to have a section in Config for FallbackStyle. WDYT @sam-mccall ?
For the second issue, it seems like a straight forward fix, but it implies a change in behaviour. Maybe they've a good reason for bailing out early whenever the FallbackStyle is malformed. I'll put together a patch and try to find some clang-format reviewers to see if they got any concerns.
As for a workaround until we take some action, similar to what @ErikReider did, you can put a .clang-format
file at a top level like $HOME/.clang-format (assuming source files you edit are living under $HOME/...). Then clangd will read style from that file, if it fails to find any config closer to file being edited instead.
from coc-clangd.
it is not customizable because it is a kind of presets
I'm not sure about this: -fallback-style
accepts the same options as clang-format -style
which is used by vim-clang-format
. It can be a string like LLVM
for a preset, or a YAML document within {}
- this is the same format used in .clang-format
files and can customize any settings.
e.g. `clangd -fallback-style="{BasedOnStyle: LLVM, IndentWidth: 4}'"
I think someone is working on making it possible to include a separate file in BasedOnStyle too, bu that hasn't landed yet.
That said, using a .clang-format
file is the recommended solution and we're not likely to add more options to avoid doing that. The reason is that it's important that the style for a given project is consistent even if there are multiple contributors or if one contributor works on several projects with different styles.
If this is just for personal projects that you don't share with anyone else, you can put .clang-format
in your home directory etc.
from coc-clangd.
Sent out https://reviews.llvm.org/D95538 for the latter issue.
from coc-clangd.
I tried like clangd -fallback-style={...}
but it didn't work.
As you said, duplicating.clang-format
per project is the easiest solution.
But, in my case, I use a single convention that is not yet consistent so duplicating .clang-format
wasn't an optimal solution :(
That's why I wanted a "global" option.
I thought clangd doesn't have arguments for this purpose (I tried clangd --help and as far as I know there was nothing like clang-format -style=...
) but some plugins --- vim-clang-format and so on --- supports it so I was wondering about overriding some features in coc-clangd
.
Plus, the reason why I did not use vim-clang-format is I'm a coc.nvim user and it provides an interface :Format
for formatting codes, so I just wanted to keep the interface.
from coc-clangd.
-fallback-style accepts the same options as clang-format -style
That seems not to be the case, or it's bugged, or I'm setting it incorrectly in coc-settings.json
.
I tried "clangd.arguments": [ "-fallback-style='{BasedOnStyle: LLVM, IndentWidth: 8}'" ]
, but clangd reports: I[04:00:15.843] getStyle() failed for file /home/ave/clang-format-repro/main.cc: Invalid fallback style "'{BasedOnStyle: LLVM, IndentWidth: 8}'. Fallback is LLVM style.
(also notice an unclosed "
). :Format
formats as default LLVM. If .clang-format
is present with contents {BasedOnStyle: LLVM, IndentWidth: 8}
, it still formats as default LLVM (definitely a bug?). If I use "clangd.arguments": [ "-fallback-style=WebKit" ]
it formats correctly as WebKit. If .clang-format
is present with contents {BasedOnStyle: LLVM, IndentWidth: 8}
, it formats as LLVM with 8 spaces. This is all reproducible on:
vim version: NVIM v0.4.4
node version: v14.12.0
coc.nvim version: 0.0.79-6cb5c6cd2d
term: xterm-kitty
platform: linux
I[04:09:38.270] clangd version 10.0.1
with corresponding LLVM tooling being version 10 (same as clangd).
So I'm either not setting it correctly, or there are 2 issues:
- fallback style not correctly interpreted from
{}
- when 1) fails the default style is set, and when that happens
.clang-format
in current folder is ignored
Third issue is cosmetic -- unmatched "
in log report.
from coc-clangd.
I'm experiencing the same issue as @avemilia
from coc-clangd.
Fixed this issue by using a .clang-format file instead. It works but it's not optimal
from coc-clangd.
FallbackStyle cannot be a custom style definition, it has to be a predefined style.
Right - I was mistaken about the -fallback-style behavior, sorry.
This could be fixed in clang-format, it seems a little cumbersome to use but not terrible.
There was also a proposal to let -style be a file, which would interact nicely here. Seems to have stalled though.
If FallbackStyle doesn't correspond to a predefined style, style detection fails, even in the presence of a .clang-format file.
This doesn't seem like a problem. If FallbackStyle is effectively an enum, then what's the purpose of allowing an invalid value so long as you never use the feature? No other flags work that way.
from coc-clangd.
This doesn't seem like a problem. If FallbackStyle is effectively an enum, then what's the purpose of allowing an invalid value so long as you never use the feature? No other flags work that way.
Fair point if you treat this as a "flag", and if we are going down that path, I would suggest literally checking for that and shutting down if need be at the startup (same with other flags) rather than just logging some errors.
I was treating this more like a function parameter, hence the different interpretation.
from coc-clangd.
Is this fixed? I switched to this extension from https://github.com/microsoft/vscode-cpptools this one, it provides an option C_Cpp.clang_format_fallbackStyle
"C_Cpp.clang_format_fallbackStyle": "{ BasedOnStyle: LLVM, UseTab: Never, IndentWidth: 4, TabWidth: 4, BreakBeforeBraces: Attach, AllowShortIfStatementsOnASingleLine: true, IndentCaseLabels: false, ColumnLimit: 0, AccessModifierOffset: -4, AllowShortLoopsOnASingleLine: true}",
Can we have this option for clangd extension.
from coc-clangd.
clangd's issue.
from coc-clangd.
Related Issues (20)
- stdint.h Library error HOT 1
- Question: navigate to conflicting item/item causing error? HOT 4
- clangd don't start on windows HOT 1
- Unable to locate C/C++ header files (stdio.h, etc.) HOT 1
- coc-clangd still use c++03 to diagnose HOT 1
- some error flag but the code can running HOT 1
- How do I remove the automatically added parameter label in parentheses? HOT 1
- An issue of including libraries HOT 9
- Duplicate references HOT 2
- Command CocCommand clangd.install fails with error 'Failed to install clangd language server' HOT 5
- 这个插件如何在补全头文件比如#include<iostream>时,光标在>的右边,否则每次都多跳过这个符号一次 HOT 1
- [coc.nvim] Connection to server got closed. Server will not be restarted. HOT 4
- 'iostream' file not found (clang pp_file_not_found) HOT 1
- Connection to server got closed HOT 1
- coc-clangd没有输入头文件的情况下也能补全 HOT 4
- Header file not found, even though autocompletion works and include path is added correctly HOT 5
- MinGW issue HOT 1
- MinGW issue
- It can support like [c-mantic] feature? HOT 1
- Env include path not working in header files HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from coc-clangd.