vim-jp / vim-cpp Goto Github PK

反対意見無ければ数日後にリネームします。

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.

https://groups.google.com/forum/#!topic/vim_dev/CSVKWlZvNEc

The last commit marked "sync master" has removed the previously added support for c++11 features. Is that on purpose?

https://groups.google.com/d/topic/vim_dev/i37dKWLiqj0/discussion

cppType bool, wchar_t, nullptr_t should be separated as cppType bool, wchar_t and cppTypeEx nulptr_t.

#include <stdio.h>
int main()
{
	// Different Colorings bewteen 'E' and 'e'
	double d1 = 19.3E10;
	double d2 = 19.3e10;
	double d3 = 19E10;
	double d4 = 19e10;
	return 0;
}

'e' to '[eE] in 'syntax/cpp.vim'

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

• eda6bcb

vim/vim#623

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;
}

With plugin:

Without:

• 関連：https://twitter.com/Linda_pp/status/444140782639804416

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;

the sample code:
http://ideone.com/LN4U4W

It's broken. Please support the case.

vim/vim#1005

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.