when I do the single slash (/) when typing some arithmetic expression (like val1 / val2), my vim treats it as a comment for multiple lines (/*). The result looks like:
I now I can escape it by typing ;/ at the end of that line (which closes the comment), but it is still annoying and I'd like for my vim to behave properly :).
I've tried using another vim syntax highlighting package for groovy, I've tried :filetype plugin off in my .vimrc, I've tried purging vim with my settings and reinstalling it and the problem is still there.
SOLUTION:
As pointed out by #cfrick, vim (my version: 7.4) treats '/' as beginning of regular expression in groovy. The solution is to edit
/usr/share/vim/vim74/syntax/groovy.vim
And around line 260-261 there is
syn region groovyString start='/[^/]' end='/' contains=groovySpecialChar,groovyRegexChar,groovyELExpr
Just change the start to
start='/[^*/]'
Edit: changed space in regexp to * as #calid suggested in comment below
start='/[^ /]'
(that is add the space there.)
And now it looks much better. On the other hand it will now not highlight regexps starting with space, but for me it's okay. At least it's much better than what it was.
This helped mi a lot with finding my solution:
Groovy syntax highlighting in Vim 7.4
Related
I am trying to use Vim for some Groovy code at work. It doesn't seem to handle autoindents well when semicolons are not used. I've found a few questions related to Ruby and JavaScript with the same issues, but none of the fixes I find work for me. I do have filetype plugin indent on in my .vimrc, and do not set cindent, autoindent, or smartindent. I've tried running setlocal nocindent nosmartindent in a Groovy buffer and reindenting the file with ggVG= just in case there's a plugin setting those behind the scenes, and it still always gets it wrong.
For example, I get this on a small sample (from a personal libGDX sandbox app I'm writing in Groovy)
#Override
void render () {
Gdx.gl.glClearColor(0.75f, 0.75f, 0.75f, 1)
Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT)
batch.begin()
batch.draw(img, 0, 0)
font.draw(batch, "Testing", 300, 400)
batch.end()
}
Notice the extra indents after the annotation, the opening brace, and the first line of the function. My .vimrc is fairly complex, but I can post a link to my dotfiles if anyone thinks that will help.
Vim doesn't come with a indent script for groovy. So it tries to use the standard indentation rules which are based on C. These rules use semicolons to determine if a line is ended which is why you get line continuation indents on the second line of the function.
Since vim doesn't include the indent script you can use the groovyindent plugin. Placed in ~/.vim/indent. You also need to run dos2unix on groovy.vim since it contains the wrong line endings.
Since groovy looks very much like simplified perl, for my little groovy (actually nextflow DSL) coding, setting filetype=perl followed by gg=G worked quite nicely.
When I issue an ex command in the vim command line, e.g. :% s/^I/ /g (replacing all tabs in file with spaces -- the ^I is not carat-capital-i, it's the tab character entered by typing Tab or Ctrl+i), I end up with only the replacement operation affecting the first match within the lines specified.
Then on a hunch what I tried the command without the g flag, :% s/^I/ /
This worked and did the job on all the tabs.
This is backwards!
Why?
I have a ludicrously huge .vimrc, it is 1199 lines as of today, so it's pretty certain that something in it or in the plugins I use is causing this behavior. However, especially now that I have found the way to get the global flag working again, I am certainly not looking to sacrifice any of the plugins or even really attempt to do some kind of manual binary search hunting to blindly narrow down the cause of this, as that would take too long.
If the 'gdefault' option is on, this flag is on by default and the [g]
argument switches it off.
Update:
The 'Feng shui' way to get to this line in the docs is :h :s, then CTRL-] on ":s_flags"
I've just recently started to use the folding functionality of vim and it's very helpful for the languages that it works really well for.
My issue lies in the way vim comments out the fold markers in scilab code. It defaults to
/*{{{*/ and /*}}}*/
which works great in languages like C, but is not actually a comment in scilab. I get a multiplication error when i try to run the code.
I've tried adding
autocmd FileType scilab set fmr=//{{{,//}}}
to my .vimrc file which doesn't quite do what I'd like. It results in
/*//{{{*/ and /*//}}}*/
which are still not comments. The code "folds" fine but becomes unusable. I could set up a macro to replace every instance of "/*" with "//", but that could have unintended consequences when applied globally to a file.
So the question is: how can i setup vim fold markers comments for scilab files such that it will not render the file unusable?
You do not add the comments to 'foldmarker' itself, there's the 'commentstring' option that influences how Vim surrounds the fold markers (when creating folds with zf). Try setting
:setlocal commentstring=//%s
for your scilab filetype. (Put the command in ~/.vim/after/ftplugin/scilab.vim to make it permanent.)
It sounds to me like vim doesn't understand how SciLab comments work. I'm not sure if vim comes with SciLab syntax logic these days, is syntax highlighted correctly in your SciLab files? If not, you can get the syntax file from here.
Is there a particular reason you want to use marks? They aren't actually needed. If you don't want vim to auto-fold by syntax or indentation level, you can still manually define folds with
:set foldmethod=manual
That lets you select a chunk of text in visual mode and make it into a fold with 'zf'. No marks required.
More info on various vim folding techniques here.
Sometimes vim highlights brackets or semicolon with red color. What plugin highlights it? Does it mean error in this place? Look on a picture please.
Yes, for the default syntax highlighter, it means that vim has flagged something wrong with that location. Check out :help syntax for more options. As #romainl stated, other plugins may be affecting what you see.
I have a vanilla Cygwin version running and it flags a few brackets in your css snippet as being invalid either due to missing opening/closing brackets or bad syntax as vim defines it.
When I browse code in Vim, I need to see opening and closing parenthesis/
brackets, and pressing % seems unproductive.
I tried :set showmatch, but it makes the cursor jump back and forth
when you type in a bracket. But what to do if I am browsing already written code?
DoMatchParen
in your .vimrc file
or
:DoMatchParen
within vim itself.
Edit: This comes from the pi_paren plugin (which is a standard plugin).
set showmatch is your best bet. you can also use the % command to jump between matching parenthesis, braces, brackets, quotes, etc.
An upgrade of vim from version 6.3 to 8.0 might swap/upgrade the code file that manages this MatchParen functionality under /usr/share/vim/vim80/plugin/matchparen.vim
The function to begin investigating a vim failure for highlighting matching brackets is called: Highlight_Matching_Pair(). Do an echo and a sleep and step through the code until matchaddpos(...) runs.
Maybe what you want is this plugin:
http://www.vim.org/scripts/script.php?script_id=350