vim-jp / vim-cpp Goto Github PK
View Code? Open in Web Editor NEWc or cpp syntax files
c or cpp syntax files
反対意見無ければ数日後にリネームします。
Both in VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Apr 26 2017 07:49:10)
and NVIM 0.2.0
--which both rely on the 2016 Oct 28
version of this project for syntax highlighting of cpp files -- seem to color floats wrong.
Example:
In my color scheme I'm using:
hi Float guifg=#eb2121 guibg=NONE guisp=NONE gui=NONE
hi Number guifg=#f0ad6d guibg=NONE guisp=NONE gui=NONE
see https://github.com/originalsouth/nvimrc/blob/master/colors/inkpot.vim
This produces wrong coloring of statement like printf("%g\n",1.0+1.0);
colors the 1
as defined by hi Number
and the .0
as defined by hi Float
both in VIM as NVIM.
See image for example: c
left, cpp
right (the 1
is yellowish where the .0
is reddish):
This seems to be a regression from the 2015 Nov 10
version.
Where the coloring is still ok. See image:
See also this issue in the neovim repository.
The last commit marked "sync master" has removed the previously added support for c++11 features. Is that on purpose?
cppType bool
, wchar_t
, nullptr_t
should be separated as cppType bool
, wchar_t
and cppTypeEx nulptr_t
.
Clang 3.4 supports both:
http://clang.llvm.org/cxx_status.html#cxx14
#include <iostream>
int main()
{
int n = 1'000'000;
std::cout << n << std::endl;
unsigned char c = 0b0100'0000;
std::cout << c << std::endl;
return 0;
}
I'm new to Vim syntax files, but the following seems to work for binary literals:
syn match cNumber display contained "0b[01]\+\(\'[01]\+\)*"
In some C/C++ sources it is customary to indent lines containing directives like so:
#ifdef POSIX /* A comment. */
# ifdef LINUX
# define FOO(a, b) \
# do { bar(a), baz(a##b); } while (0);
# endif
#endif
It seems like the rule being used involves highlighting everything past "#" and then applying the rules for detecting comments. Also related is #41.
My apologies for not including this in #44, I only remembered it now and that already has a proposed fix.
vim-jp/issues#667 より移管します。
魔窟 c.vim
で発見されました。
Date: Thu Oct 2 01:41:41 2014 +0200
Update runtime files.
の際の変更で入ったようです。
#define TEST_0 "foobar"
のような、#define
以降に 0 が現れる構文で 0 以降がコメントアウト色となります。
c.vim 64 行目
syn region cCppOut2 contained start="0" end="^\s*\(%:\|#\)\s*\(endif\>\|else\>\|elif\>\)" contains=cSpaceError,cCppSkip
で start が 0 になっているからのようですが、どのように修正するのが適切か分かりません。
#if 0
構文に絡むようなので if\s\+0
とかしてしまってもいいものでしょうか。
C++ identifiers with special meaning (final, override, import and module). are incorrectly highlighted out-of-context. These keywords should be considered as regular identifiers when used out of their special meaning context (c.f. C++20 standard, section 5.10, paragraph 2).
Reproduction:
int final, override, import, module;
Actual: these variables names are incorrectly highlighted as keywords.
Expected: no specific highlighting.
Refers to vim/vim#8745.
I often edit code with filetype set to 'cpp.doxygen', which gives C++ syntax highlighting for the code and doxygen highlighting on the comments. However, the lines
if exists("c_no_curly_error")
if &filetype ==# 'cpp' && !exists("cpp_no_cpp11")
do not match a filetype of cpp.doxygen, so lambda functions still have the {} marked as errors. If I change the filetype to cpp then they are no longer marked as errors.
Unfortunately I don't know enough about the vim scripting language to be able to suggest a fix.
一応、オフィシャルの一部になるので、変更前には必ずレビューしましょう。
vim indenting is very poor for c++ lambdas, if someone has an indent file to share that resolves that, that would be great!
https://gist.github.com/minamiyama1994/2c1ba9b69bc9b9838e21
上記の例で、error.cppだとエラーが発生してOK.cppだとエラーが発生しません、ここを弄ったら治ったりするっぽいのでとりあえずN3337か何かを参照して正規表現を修正するのがいいのかなとか邪推してみます
Per the FreeType library's documentation, it is to be included as follows:
#include <ft2build.h>
#include FT_FREETYPE_H
However Vim's syntax files for C/C++ (and likely other languages) only highlight the #include
when a matching pair of delimiters is provided.
The last "merge master" was to fix a previous sync, that erased the previous raw string literals support. It has fixed that but has erased other c++11 keywords and constants that were added previously. Any reason for that?
On start vim folds all code starting from the first function into one big fold and only then fold functions right.
I found that problem is in the following code in c.vim starting from 138 line:
if &filetype ==# 'cpp' && !exists("cpp_no_cpp11")
syntax region cBadBlock start="{" end="}" transparent fold
else
syntax region cBadBlock keepend start="{" end="}" contained containedin=cParen,cBracket,cBadBlock transparent fold
endif
if replace
syntax region cBadBlock start="{" end="}" transparent fold
with
syntax region cBadBlock start="{" end="}" contained containedin=cParen,cBracket,cBadBlock transparent fold
folding works well.
G'day,
I just noticed that raw string literal highlighting is broken.
Single line raw strings are highlighted as cppString and multiline raw string highlighting is broken. It would appear that the cppRawString syntax group needs to have higher priority than the cppString group.
foo = R"--( ... )--";
bar = R"--(
...
)--";
Thanks,
Doug
I have for the time being implemented this in my own local copy (in ~/.vim/syntax). I am not an expert at vim syntax files, so I have one minor problem which is that if you have [noreturn]
, the noreturn
will be highlighted (and some other weird edge cases), but I'm not able to fix this myself, so I've simply attached attached my diff so far:
diff --git a/usr/local/share/nvim/runtime/syntax/cpp.vim b/home/cactus/.vim/syntax/cpp.vim
index ed38913..92fd735 100644
--- a/usr/local/share/nvim/runtime/syntax/cpp.vim
+++ b/home/cactus/.vim/syntax/cpp.vim
@@ -47,6 +47,8 @@ if !exists("cpp_no_cpp11")
syn region cppRawString matchgroup=cppRawStringDelimiter start=+\%(u8\|[uLU]\)\=R"\z([[:alnum:]_{}[\]#<>%:;.?*\+\-/\^&|~!=,"']\{,16}\)(+ end=+)\z1"+ contains=@Spell
syn match cppCast "\<\(const\|static\|dynamic\)_pointer_cast\s*<"me=e-1
syn match cppCast "\<\(const\|static\|dynamic\)_pointer_cast\s*$"
+ syn region cppAttrSpec matchgroup=cppAttributeDelimiter start=+\[\[+ end=+\]\]+ contains=TOP
+ syn keyword cppAttribute noreturn carries_dependency contained containedin=cppAttrSpec
endif
" C++ 14 extensions
@@ -56,6 +58,7 @@ if !exists("cpp_no_cpp14")
syn match cppNumber display "\<[1-9]\('\=\d\+\)*\(u\=l\{0,2}\|ll\=u\)\>" contains=cFloat
syn match cppNumber display "\<0x\x\('\=\x\+\)*\(u\=l\{0,2}\|ll\=u\)\>"
syn case match
+ syn keyword cppAttribute deprecated contained containedin=cppAttrSpec
endif
" C++ 20 extensions
@@ -65,12 +68,14 @@ if !exists("cpp_no_cpp20")
syn keyword cppStructure concept
syn keyword cppType char8_t
syn keyword cppModule import module export
+ syn keyword cppAttribute likely unlikely no_unique_address contained containedin=cppAttrSpec
endif
" C++ 17 extensions
if !exists("cpp_no_cpp17")
syn match cppCast "\<reinterpret_pointer_cast\s*<"me=e-1
syn match cppCast "\<reinterpret_pointer_cast\s*$"
+ syn keyword cppAttribute fallthrough nodiscard maybe_unused contained containedin=cppAttrSpec
endif
" The minimum and maximum operators in GNU C++
@@ -90,6 +95,8 @@ hi def link cppBoolean Boolean
hi def link cppConstant Constant
hi def link cppRawStringDelimiter Delimiter
hi def link cppRawString String
+hi def link cppAttributeDelimiter StorageClass
+hi def link cppAttribute StorageClass
hi def link cppNumber Number
hi def link cppModule Include
I have made an effort to not highlight attributes outside of valid contexts (e.g. likely
is not highlighted unless it's inside an attribute specifier), but it seems to have some unfortunate side effects. At the moment, this is the resulting highlighting in a few cases:
Source this code:
fun! Collect(word)
call ccomplete#Complete(1, '')
return ccomplete#Complete(0, a:word)
endf
fun! MyComplete(word, col)
" let l:wv = winsaveview()
let l:suggestions = Collect(a:word)
" call winrestview(l:wv)
if !empty(l:suggestions)
call complete(col('.') - len(a:word), l:suggestions)
endif
return ''
endf
Then create a new cpp
buffer, and type the following text:
for for1
for1
With the cursor at the end of the buffer (after the second for1
), type <c-r>=MyComplete('for1',0)
. The pop-up menu will open below the first line. If the window view is saved and restored (see the commented lines above), the bug does not occur.
According to :h E839
:
The function is allowed to move the cursor, it is restored afterwards.
but it seems that the cursor is not restored.
When writing a raw string literal, the autoindent still tries to indent labels (whenever you type a colon) or directives (whenever you type # at the start of a line). For example, suppose you intend to type the following:
const char* s = R"(
test {
bar {
# comment
field: 123
}
}
)";
Vim will move the #comment
and field:
to the leftmost column because it thinks they are preprocessor directives and labels, respectively.
This code have a broken highlighting, without a plugin all good:
#include <stdio.h>
struct element {
bool type;
int polygon = 0;
int polygon_size = 0;
};
int main(void) {
int n, a, b;
scanf("%i%i%i", &n, &a, &b);
element **cartrige;
cartrige = new element*[a];
for(int j = 0; j<a;j++) {
cartrige[j] = new element[b];
for(int i = 0; i<b;i++) {
char n;
scanf("%c", &n);
if(n == '.') {
cartrige[j][n].type = true;
} else {
cartrige[j][n].type = false;
}
}
}
for(int j = 0; j<a;j++) {
for(int i = 0; i<b;i++) {
}
}
return 0;
}
Twitter でそういう話がでていたので立てておきます。
以下のように C++11 で追加されたユーザ定義リテラルもリテラルとして一緒に
ハイライトを行いたい。
// _user_defined_literal をリテラルとしてハイライトしたい
1234_user_defined_literal
"homu"_user_defined_literal
syn match cNumber display contained "\d\+\(\w*\)\>"
syn match cNumber display contained "0x\x\+\(\w*\)\>"
syn match cOctal display contained "0\o\+\(\w*\)\>" contains=cOctalZero
syn match cFloat display contained "\d\+\.\d*\(\w*\)"
syn region cCppString start=+L\="+ skip=+\\\\\|\\"\|\\$+ excludenl end=+"\w*+ end='$' contains=cSpecial,cFormat,@Spell
いまは『数値+リテラル』を1つのシンタックスとして定義する事を考えています。
上記のコードを https://github.com/vim-jp/cpp-vim/blob/master/syntax/cpp.vim#L38 あたりに追加すればよさそう?
Vim のシンタックスに詳しい人誰か。
This code is valid C++11, but the braces are shown in red as invalid syntax
std::map<std::pair<int, int>, int> m;
m[{1, 2}] = 3;
Hello, I think that nullptr_t has the same rights as the [u]int[XY]_t types to live in the C++11 part of cpp.vim. Thank you for considering.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.