I just recently set up my Vim environment from Textmate, after becoming addicted to its modal input.
However, syntax highlighting seems to be not so beautiful in Vim. I code in C++ and since the function call and class names can't be highlighted, the code is more difficult to read. I played with color scheme for a bit, but couldn't find any field that corresponded to "class name" or "function name".
In the picture below, notice how DroughtLayer:: and *.size() is not highlighted on the right in MacVim.
(source: ivzhao.com)
Any ideas how to solve this? It really annoys me as I am so much a visual-sensitive guy.
I had this very same problem when I started using vim. The solution is simple, you just have to edit the c syntax file used by vim, here's how to do it:
When you start editing a C or C++ file, vim reads the default c syntax file located in
$VIMRUNTIME/syntax/c.vim
(Where $VIMRUNTIME is where you have vim installed. You can find out it's default value by opening vim and using the command ":echo $VIMRUNTIME").
You can simply overwrite that file, or you can create your custom C syntax file (which will be loaded by vim instead of the default one) in this location:
$HOME/.vim/syntax/c.vim (for UNIX)
$HOME/vimfiles/syntax/c.vim (for PC or OS/2)
(I have never used a Mac so I don't know which one will work for you. You can find out more in the vim help, ":help vimfiles")
Now the fun part. Copy the default "$VIMRUNTIME/syntax/c.vim" file to your vimfiles directory ("$HOME/.vim/syntax/c.vim" for UNIX), and edit it by adding these lines:
" Highlight Class and Function names
syn match cCustomParen "(" contains=cParen,cCppParen
syn match cCustomFunc "\w\+\s*(" contains=cCustomParen
syn match cCustomScope "::"
syn match cCustomClass "\w\+\s*::" contains=cCustomScope
hi def link cCustomFunc Function
hi def link cCustomClass Function
That's it! Now functions and class names will be highlighted with the color defined in the "Function" highlight (":hi Function"). If you want to customize colors, you can change the last two lines above to something like this:
hi def cCustomFunc gui=bold guifg=yellowgreen
hi def cCustomClass gui=reverse guifg=#00FF00
or you can leave the C syntax file alone and define colors in your vimrc file (":help vimrc"):
hi cCustomFunc gui=bold guifg=yellowgreen
hi cCustomClass gui=reverse guifg=#00FF00
(Note the absence of the "def" keyword, go to ":help highlight-default" for details). For the available parameters to the ":hi" command see ":help :highlight".
You can find the complete c.vim file for Vim 7.2 on this link (Note: only use this if you have a non-modified Vim, version 7.2):
http://pastebin.com/f33aeab77
And the obligatory screenshot:
this is my first post here and i didn't know how to make an observation, the answer of Eduardo makes "(" and "{" look unmached and bugs syntax foldind, I changed it a little to fix this.
syn match cCustomParen "?=(" contains=cParen,cCppParen
syn match cCustomFunc "\w\+\s*(\#=" contains=cCustomParen
syn match cCustomScope "::"
syn match cCustomClass "\w\+\s*::" contains=cCustomScope
hi def cCustomFunc gui=bold guifg=yellowgreen
hi def link cCustomClass Function
Interestingly, the syntax highlighters in VIM don't support applying a syntax to identifiers or function names - at least not the syntax highlighters for C and C++. So, even if you do:
:hi Function guifg=red
or
:hi Identifier guifg=red
it doesn't give these a color. I just seems to be not much more than keywords and constants for these languages.
Here, someone has started extending the cpp syntax file to support method names. It's a start I guess.
http://vim.wikia.com/wiki/Highlighting_of_method_names_in_the_definition
The one solution is to use built ctags database. So create one with the ctags utility. Then set the 'tags' variable and put the following to the
~/.vim/after/syntax/c.vim
function! s:highlight()
let list = taglist('.*')
for item in list
let kind = item.kind
if kind == 'f' || kind == 'c'
let name = item.name
exec 'syntax keyword Identifier '.name
endif
endfor
endfunction
call s:highlight()
I must warn you that this can work very slow on the very big ctags database.
Also there is one solution on the vim.org but I didn't try this one. Let me know if it works for you.
EDIT: color_coded may be too heavy for you. try octol/vim-cpp-enhanced-highlight. It supports C++11/14 and integrates what #Eduardo answers.
Semantic based highlighter:
I would recommend jeaye/color_coded,
A vim plugin for libclang-based highlighting
So sorry that i'm new to stackoverflow which means I've not enough reputation to post images. Go see its effects if you wanna give it a shot. :)
Pros:
Easy installation
Semantic highlighting
Clighter mentioned as above, need vim compiled with python2.7.
However, color_coded is written in C++ and provides lua binding ->
C++.
Cons:
It delays unless you make some vim events to acitve it.
Customization is bit harder; you need to edit syntax/color_coded.vim
yourself. But customization has been placed on its roadmap.
Although it's still under development, it's increasingly gaining attention.
Sergey, changing the first line from
syn match cCustomParen "(" contains=cParen,cCppParen
to
syn match cCustomParen "(" contains=cParen contains=cCppParen
seems to fix it for me.
Try using this plugin http://www.vim.org/scripts/script.php?script_id=2646
Its does all ctags highlighting very efficiently for you
Use a plug-in for vim like Taglist or set up ctags or cscope integration with vim (here's a tutorial for the vim/cscope.)
I really recommend you the taghighlight plugin, click here for it's website.
The Clighter plugin can also be considered, which is a
plugin for c-family semantic source code highlighting, based on Clang
However, requires fairly recent versions and software: vim 7.4.330 +python2 and libclang.
To match C functions definitions only, this works for me:
syn match cCustomFuncDef display /\(\w\+\(\s\|*\)\+\)\#<=\w\+\s*(\#=/
hi def cCustomFuncDef ctermfg=lightblue
Related
Just as title says, I want matchpairs option to work with with the signs '¿' and '?'. It works with other signs, for example after setting:
I'm able to jump between spanish exclamation marks ('¡' and '!') with just pressing '%'. The problem comes when doing the same with questions marks by:'
I will obtain a error message explaining some kind of function failing dealing with regex:
At first sight, the function would seem to come from one of my plugins so I tried to find which by replacing my .vimrc with a blank file but vim continued showing the same error so my personal plugins are not the problem.
As far as I know, when using nocompatible mode in vim several integrated plugins are charged. I think some of those plugins is the guilty, because when I call vim without any config fail by "vim -u NONE" the problem disappears. However, anyone here would be with me in that using no config file would be a little unpleasant.
Then my questions are:
What is the easiest way to solve this problem?
What is causing it? Is really something related with regular expressions (I have tried placing a '\' before the '?' without results)'?
You could use matchit plugin (which most likely is already installed in your computer as the function causing the error, Match_wrapper(), is defined on matchit.vim. To check if matchit.vim is loaded, use the command :scriptnames in Vim). Then add this auto command to .vimrc:
autocmd! BufWinEnter,BufEnter * if exists("b:match_words") |
\ let b:match_words=b:match_words.',¿:?' |
\ endif
To keep .vimrc clean you may want to follow the advice on help :matchit:
... you can add autocommands to the script or to your vimrc file, but the recommended method is to add a line such as
let b:match_words = '\<foo\>:\<bar\>'
to the filetype-plugin for your language.
Background
This relates to an older stackoverflow question. I was hoping to ask for more details but haven't got the Reputation to write comments yet.
Circumstances are the same: I'm adding codecheck warnings that I want to ignore, by editing the "IgnoredCodeIssues" section of Omnisharp's config.json file.
The question
What wildcard/regexp characters work here and how? Is it perhaps a known standard with its own docs somewhere that I can read?
Example
If I enter an issue warning verbatim it works, but it would be way more efficient to use wildcards. For example this warning:
Method 'Update' has the same with 'Start'
is a warning I don't care about and it's going to pop up a lot. A good solution would be to configure it to work for all instances of this issue, i.e. to use wildcards at the 'Update' and 'Start' parts.
Using a typical regexp it would look like this:
/(Method)\s'\w+'\shas the same with\s'\w+'/g
but that's obviously not the syntax here and would just break the config file. So I'm hoping to understand the particular syntax of wildcards in this particular file.
More details
I use Omnisharp-sublime and Sublime Text 3.
I've read the docs and rummaged around the GitHub page (no links as my reputation is too low for 2+ links) but the only relevant information is an example config file with a couple of ignored issues:
"IgnoredCodeIssues": [
"^Keyword 'private' is redundant. This is the default modifier.$",
".* should not separate words with an underscore.*"
],
EDIT:
Using
"Method '.*.' has the same with.*",
(note the .*.) makes the warnings go away but I have no idea if there are side-effects or other consequences like hiding warnings that I might do want to be notified of. Is there anyone who has seen wildcard expansions like that before? Would be great to be able to look it up and study it before adding more to my config.json
Based on the examples in the config file, you should just use standard regex inside double quotes. Don't use the Perl style of /regex/replace/options. config.json is read by the OmniSharp server, which is written in C#, so if you're looking to do anything fancy with your regexes, make sure they're C#-compatible.
So, for instance, your example regex would look like this:
"(Method)\s'\w+'\shas the same with\s'\w+'"
Background
I use JScript (Microsoft's ECMAScript implementation) for a lot of Windows system administration needs. This means I use a lot of ActiveX (Automated COM) objects. The methods of these objects often expect Number or Boolean arguments. For example:
var fso = new ActiveXObject("Scripting.FileSystemObject");
var a = fso.CreateTextFile("c:\\testfile.txt", true);
a.WriteLine("This is a test.");
a.Close();
(CreateTextFile Method on MSDN)
On the second line you see that the second argument is one that I'm talking about. A Boolean of "true" doesn't really describe how the method's behavior will change. This isn't a problem for me, but my automation-shy coworkers are easily spooked. Not knowing what an argument does spooks them. Unfortunately a long list of constants (not real constants, of course, since current JScript versions don't support them) will also spook them. So I've taken to documenting some of these basic function calls with inline block comments. The second line in the above example would be written as such:
var a = fso.CreateTextFile("c:\\testfile.txt", /*overwrite*/ true, /*unicode*/ false);
That ends up with a small syntax highlighting dilemma for me, though. I like my comments highlighted vibrantly; both block and line comments. These tiny inline block comments mean little to me, personally, however. I'd like to highlight those particular comments in a more muted fashion (light gray on white, for example). Which brings me to my dilemma.
Dilemma
I'd like to override the default syntax highlighting for block comments when both the beginning and end marks are on the same line. Ideally this is done solely in my vimrc file, and not in a superseding personal copy of the javascript.vim syntax. My initial attempt is pathetic:
hi inlineComment guifg=#bbbbbb
match inlineComment "\/\*.*\*\/"
Straight away you can see the first problem with this regular expression pattern is that it's a greedy search. It's going to match from the first "/*" to the last "*/" on the line, meaning everything between two inline block comments will get this highlight style as well. I can fix that, but I'm really not sure how to deal with my second concern.
Comments can't be defined inside of String literals in ECMAScript. So this syntax highlighting will override String highlighting as well. I've never had a problem with this in system administration scripts, but it does often bite me when I'm examining the source of many javascript libraries intended for browsers (less.js for example).
What regex pattern, syntax definition, or other solution would the amazing StackOverflow community recommend to restore my vimrc zen?
I'm not sure, but from your description it sounds like you don't need a new syntax definition. Vim syntax files usually let you override a particular syntax item with your own choice of highlighting. In this case, the item you want is called javaScriptComment, so a command like this will set its highlighting:-
hi javaScriptComment guifg=#bbbbbb
but you have to do this in your .vimrc file (or somewhere that's sourced from there), so it's evaluated before the syntax file. The syntax file uses the highlight default command, so the syntax file's choice of highlighting only affects syntax items with no highlighting set. See :help :hi-default for more details on that. BTW, it only works on Vim 5.8 and later.
The above command will change all inline /* */ comments, and leave // line comments with their default setting, because line comments are a different syntax item (javaScriptLineComment). You can find the names of all these groups by looking at the javascript.vim file. (The easiest way to do this is :e $VIMRUNTIME/syntax/javascript.vim .)
If you only want to change some inline comments, it's a little more complicated, but still easy to see what to do by looking at javascript.vim . If you do that, you can see that block comments are defined like this:-
syn region javaScriptComment start="/\*" end="\*/" contains=#Spell,javaScriptCommentTodo
See that you can use separate regexes for begin and end markers: you don't need to worry about matching the stuff in between with non-greedy quantifiers, or anything like that. To have a syntax item that works similarly but only on one line, try adding the oneline option (:h :syn-oneline for more details):-
syn region myOnelineComment start="/\*" end="\*/" oneline
I've removed the two contains groups because (1) if you're only using it for parameter names, you probably don't want spell-checking turned on inside these comments, and (2) contained sections that aren't oneline override the oneline in the container region, so you would still match all TODO comments with this region.
You can define this new kind of comment region in your .vimrc, and set the highlighting how you like: it looks like you already know how to do that, so I won't go into more details on that. I haven't tried out this particular example, so you may still need a bit of fiddling to make it work. Give it a try and let me know how it goes.
Why don't you simply add a comment line above the call?
I think that
// fso.CreateTextFile(filename:String, overwrite:Boolean, unicode:Boolean)
var a = fso.CreateTextFile("c:\\testfile.txt", true, false);
is a lot more readable and informative than
var a = fso.CreateTextFile("c:\\testfile.txt", /*overwrite*/ true, /*unicode*/ false);
When I compile my code I get a bunch of errors which I span through the screen and I can see where does the error start. How can I save the output of gcc to a file?
I tried tricks like
gcc > log.txt
or grepping the result but it didn't work. Searching google yields mostly result on explaining how to print to file with c++
GCC outputs errors to the standard error stream not to the standard output stream. You need to redirect standard error, instead of standard output. In bash:
gcc 2> log.txt
I personally found out that merely outputing the error to a file would not help. In fact the easiest thing that could help me was to avoid wrapping the error lines which are usually super long. So, I decided to use vim highlighting to see the errors better.
Without the highlighter (View Larger Image)
With the highlighter (View Larger Image)
.
And fortunately, there was a very easy way to set up a new syntax highlighting in VIM.
Follow these steps and you will be more productive working on heavily templated C++ codes:
Create a new VIM custom syntax highlighting rule set
you have to define the syntax highlighting rules. Put the following in a file called cerr.vim and keep it for example in $HOME/vim_syntax/cerr.vim
"Set line wrapping to off to see more error lines in one page
set nowrap
set showmatch
"I use stl and boost alot so it is good to remove the namespaces from the error file :)
silent! %s/st![enter image description here][2]d:://g
silent! %s/boost::fusion:://g
silent! %s/boost:://g
"Usually I am not interested in the file paths until I can locate the error so I tried to
"hide them
silent! %s/\/[^\.]*\// /g
"By default syntax highlighting for each line is limited to 3000 characters
"However, 3000 characters is not sufficient for lengthy C++ errors, so I change it to 20000
set synmaxcol=20000
"Now I define the keywords that I would like them to be highlighted
syn keyword cerrInfo instantiated
syn keyword cerrError error Error ERROR
syn keyword cerrWarning warning Warning WARNING
"-------------------------------------
"In this step I would like to distinguish the prefix in each line (which shows the file name) from the rest of the line
syn region cerrLine start=/^/ end=/\:/
syn region cerrSeparator start=/^\.+/ end=/\./ fold oneline
"I want to make templated type information less visible while debugging
"You have to remember that a type can have nested types. So I define three regions
syn region cerrTemplate1 matchgroup=xBracket1 start=/</ end=/>/ contains=cerrTemplate2 fold oneline
syn region cerrTemplate2 matchgroup=xBracket2 start=/</ end=/>/ contains=cerrTemplate3 fold contained oneline
syn region cerrTemplate3 start=/</ end=/>/ contains=cerrTemplate3 contained oneline fold oneline
"Now I would like to highlight whatever is in parenthesis with a different color so I make
"another region in here. This makes sure that function arguments can have different color
syn region cerrPar matchgroup=xBracket start=/(/ end=/)/ contains=cerrTemplate1 oneline fold
"GCC puts the real type information in brackets, let's group them separately
syn region cerrBracket start=/\[/ end=/\]/ contains=cerrTemplate1,cerrPar oneline
"Again GCC puts the error in these weird characters :) So I define a separate region here
syn region cerrCode start=/‘/ end=/’/ contains=cerrPar,cerrBracket,cerrTemplate1 oneline
"And finally I would like to color the line numbers differently
syn match cerrNum "[0-9]\+[:|,]"
"--------------------------------------------------------------------------
"Now the fun part is here, change the colors to match your terminal colors.
"I Use the following colors for my white background terminal.
"In the following we assign a color for each group that we defined earlier
"Comment is a default VIM color group
highlight link cerrInfo Comment
"We use custom coloring for the rest
highlight default cerrWarning ctermfg=red ctermbg=yellow
highlight default cerrError ctermfg=white ctermbg=red
highlight default cerrLine ctermfg=grey term=bold
highlight default cerrSeparator ctermfg=darkgrey
highlight default cerrTemplate1 ctermfg=grey term=bold
highlight default cerrTemplate2 ctermfg=grey term=bold
highlight default cerrTemplate3 ctermfg=grey
highlight default cerrCode cterm=bold ctermfg=darkgrey
highlight default cerrBracket ctermfg=darkgreen
highlight default xBracket1 ctermfg=darkgrey term=bold
highlight default xBracket2 ctermfg=darkgrey
highlight default cerrPar ctermfg=yellow
highlight default cerrNum ctermfg=red
Change your .vimrc file
Now, you have to tell vim to use your new highlighting for files with specific extension. In my case I would like to output my error files to error.ccerr, put the following in your .vimrc in your home folder:
au BufRead,BufNewFile *.cerr set filetype=myerror
au Syntax myerror source $HOME/vim_syntax/cerr.vim
What I say in the above is that when files with the extension .cerr are opened using VIM, they will be considered of type myerror. In the second line I am saying that VIM should use my syntax highlighting rule set which I defined in the previous step for all myerror files.
Send your error output to a .cerr file and open it with VIM
This step is the easiest, we send all errors and warning to error.cerr and if there is any error in the file we immediately open the .cerr file using VIM.
g++ failing.cc &> error.cerr || vim error.cerr
I am using vim 7.x
I am using alternate file.
I have a mapping of *.hpp <--> *.cpp
Suppose I'm in
class Foo {
void some_me#mber_func(); // # = my cursor
}
in Foo.hpp
is there a way to tell vim to do the following:
Grab word under # (easy, expand("")
Look up the class I'm inside of ("Foo") <-- I have no idea how to do this
Append `1 & 2 (easy: using ".") --> "Foo::some_member_func"
4: Switch files (easy, :A)
Do a / on 4
So basically, I can script all of this together, except the "find the name of the enclosing class I'm in part (especially if classes are nested).
I know about ctags. I know about cscope. I'm choosing to not use them -- I prefer solutions where I understand where they break.
This is relatively easy to do crudely and very difficult to do well. C and C++ are rather complex languages to parse reliably. At the risk of being downvoted, I'd personally recommend parsing the tags file generated by ctags, but if you really want to do it in Vim, there are a few of options for the "crude" method.
Make some assumptions. The assumptions you make depend on how complicated you want it to be. At the simplest level: assume you're in a class definition and there are no other nearby braces. Based on your coding style, assume that the opening brace of the class definition is on the same line as "class".
let classlineRE = '^class\s\+\(\k\+\)\s\+{.*'
let match = search(classlineRE, 'bnW')
if match != 0
let classline = getline(match)
let classname = substitute(classline, classlineRE, '\1', '')
" Now do something with classname
endif
The assumptions model can obviously be extended/generalised as much as you see fit. You can just search back for the brace and then search back for class and take what's in between (to handle braces on a separate line to "class"). You can filter out comments. If you want to be really clever, you can start looking at what level of braces you're in and make sure it's a top level one (go to the start of the file, add 1 every time you see '{' and subtract one every time you see '}' etc). Your vim script will get very very very complicated.
Another one risking the downvote, you could use one of the various C parsers written in python and use the vim-python interface to make it act like a vim script. To be honest, if you're thinking of doing this, I'd stick with ctags/cscope.
Use rainbow.vim. This does highlighting based on depth of indentation, so you could be a little clever and search back (using search('{', 'bW') or similar) for opening braces, then interrogate the syntax highlighting of those braces (using synIDattr(synID(line("."), col("."),1), "name")) and if it's hlLevel0, you know it's a top-level brace. You can then search back for class and parse as per item 1.
I hope that all of the above gives you some food for thought...