I found a bug in the vim language syntax of <vim.vim> file. If there are multiple quotation marks in a comment, it will not be treated as normal comment. For example:
the line 1 and line 3 will not be commented as I expected.
How can I fix the bug ? I try to understand the syntax setting in the of vimComment setting and do some modification, but failed.
Add more details about my question:
I wrote a vim script as below:
let a = b " b range:0~255
Note: there are some spaces at the beginning of the statement.
I want to comment this statement, so add quotation at the beginning of the statement.
" let a = b " b range:0~255
I find the statement will NOT be recognized as vimComment as I expected, it will be treated as vimString (when cursor under let) and vimIsCommand (when cursor under range).
Here, I used the following method to check syntax name and definition under cursor.
nnoremap <f8> :echo synIDattr(synID(line('.'), col('.'), 0), 'name')<cr>
I think this is a bug in the vim.vim file which version is '8.0-28'.
For received feedbacks that there were no the same issue found in the others' VIM enviroment, I had to check my settings and did some trials. In the end I found this issue was caused by the Plugin 'thaerkh/vim-indentguides'. If I did not use this plugin, the comment state was correct as I expected. I guess the plugin has some errors in using of VIM conceal feature. So I changed to use the Plugin 'Yggdroot/indentLine' instead and solved the issue. Thank #all.
Related
we all know what ci" ci' ci( ci[ ... does. Very handy in everyday's editing. I found something strange, and checked the help, didn't find out why.
say, I have a file:
foo "target"
foo 'target'
foo (target)
foo {target}
foo [target]
foo <target>
if my cursor at the beginning of each line, (on the 'f'), then I type ci", ci', ci(...
the cix works only with quotes (single or double), doesn't work for brackets. why do they behave differently?
(dix, vix the same)
tested with --noplugin, vim 7.3
thank you.
Update
thanks #romainl for the answer. I still have doubt regarding the "pair processing in vim"
check this example:
foo "targ\"eti\" some\"thing else "
if I have a line like above, I type ci", no matter cursor is at beginning or between quotes, it works perfectly, it seems that vim does have the idea of "pair"?
and this maybe what you meant about the pairing ?
foo "target x some"thing else "
foo (target x some(thing else )
I have above two lines, if (cursor at x) I type ci" and ci(, nothing happened to 2nd line, but first line changed into:
foo "I"thing else " (I is cursor)
ci( is consistent with ci[, ci{ and cit and all the other <action>i<something>. Only ci' and ci" work like they do. The outliers are the quotes, here, not the brackets.
Vim doesn't consider that quotes come in pairs while brackets do. It has an internal logic for matching pairs that works with actual pairs but not with quotes hence the difference in behavior.
You are not the first to complain about that discrepancy: this is one solution, maybe you can find others.
edit
I don't have a deep knowledge of Vim's internals, unfortunately, so I can only make assumptions, here.
If you ask Vim to do ci" it does its best to find a pair of double quotes but double quotes don't go by pairs: there's no way to tell if a " is the closing one or the opening one contrary to brackets. Because of that, Vim must make some choices. IMO, the choice that would make the most sense considering how the other members of the family work, would be to assume that the cursor is between the quotes and select from the first one to the right to the first one to the left. I can only assume that this method proved wrong in some way or didn't work for some reason and that the other method (the current one) prevailed.
Another explanation could be that the i<something> mechanism is somehow tied to a specific subsystem (maybe the same as showmatch?) that is unable to deal correctly with quotes.
Anyway, just like you, I find this discrepancy weird and I've somehow internalized it and aligned my usage of <action>i" to how the others work. To the point of actually doing 2t"ci" or some variant instead of ci"!! Inefficient, I know.
Did you read :h a'? I completely forgot where I got my "limited understanding" of the issue but it was there! It says:
"Only works within one line. When the cursor starts on a quote, Vim will figure out which quote pairs form a string by searching from the start of the line."
What I get from that is this: for some reasons unknown to us, Vim uses another mechanism for matching quotes than for the other pairs and that is why ci" is different from ciband friends. The underlying cause is not clear at all but I'm fairly certain that the big picture looks a lot like what I imagine.
To me, it looks a lot like a bug or a limitation disguised as a feature.
If you are still curious, I'd suggest you ask any further question on vim-dev.
make use of %
" nnoremap cb cib
nnoremap cb %cib
" nnoremap vb vib
nnoremap vb %vib
nnoremap yb %yib
nnoremap db %dab
to enhance %:
https://github.com/andymass/vim-matchup#tocbar-dopjfd
b can match ( [ {,
Want to use ' to match both ' and "?
nnoremap c' :call DoubleAsSingleC()<CR>
func! DoubleAsSingleC()
" When [!] is added, error messages will also be skipped,
" and commands and mappings will not be aborted
" when an error is detected. |v:errmsg| is still set.
let v:errmsg = ""
silent! :s#\"\([^"]*\)\"#'\1'#g
if (v:errmsg == "")
echo "双变单"
endif
exec "normal ci'"
endfunc
Similar for:
d'
y'
v'
Does anyone know a way to color highlight function calls in Vim?
I know that some plugins could do something like that by keeping record of tags, but with what I've found online, I could not figure out how to make it work.
I've tried using easy tags (which, by the way, doesn't seem to be maintained anymore) and gutentags, but to be quite honest, I haven't come much close to make any of them to work.
On the other hand, I imagine that it would be quite simple to implement a script to highlight anything that lies between a dot and a left parentheses or a blank space and a left parentheses (as in .anyCodeAtAll(), anotherCode()), but I have no idea how to do it. It would be a incomplete solution of course, but it would be good enough for my purposes at the moment.
Does anyone know how to make that work?
I have something like that in my configuration, but it's quite language specific. For example for Golang, I have a ~/.vim/after/go.vim which contains:
syntax match goCustomParen "(" contains=cParen
syntax match goCustomFuncDef "func\s\+\w\+\s*(" contains=goDeclaration,goCustomParen
" Exclude import as function name, for multi-line imports
syntax match goCustomFunc "import\s\+(\|\(\w\+\s*\)(" contains=goCustomParen,goImport
syntax match goCustomScope "\."
syntax match goCustomAttribute "\.\w\+" contains=goCustomScope
syntax match goCustomMethod "\.\w\+\s*(" contains=goCustomScope,goCustomParen
highlight def link goCustomMethod Function
highlight def link goCustomAttribute Identifier
highlight goCustomFuncDef ctermfg=13
highlight goCustomFunc ctermfg=43
highlight goCustomAttribute ctermfg=247
highlight goCustomMethod ctermfg=33
And for Python, I have a ~/.vim/after/python.vim:
syntax match pyCustomParen "(" contains=cParen
syntax match pyCustomFunc "\w\+\s*(" contains=pyCustomParen
syntax match pyCustomScope "\."
syntax match pyCustomAttribute "\.\w\+" contains=pyCustomScope
syntax match pyCustomMethod "\.\w\+\s*(" contains=pyCustomScope,pyCustomParen
highlight def link pyCustomFunc Function
highlight def link pyCustomMethod Function
highlight def link pyCustomAttribute Identifier
highlight pyCustomFunc ctermfg=43
highlight pyCustomAttribute ctermfg=247
highlight pyCustomMethod ctermfg=33
In each case, the first block defines what is a function, a method, an attribute, and so on, the second block link these custom definition to the generic classes "Function, Identifier..." and the 3rd block defines the colors.
The files need to be in the after directory to be executed after the colorscheme and highlights definitions.
Here's a side by side comparison of with and without these settings (look on the last 3 lines):
Unless someone has a better solution, you could adapt the above for the language you need it.
It might be that you have not installed your plug-in correctly.
Try following these steps (or retrace your steps) and see if it works / missed any steps out:
cd ~ Go to home directory.
vim .vimrc open .vimrc
Insert:
call plug#begin()
Plug 'xolox/vim-easytags'
call plug#end()
easytags#Options states easytags should work out of the box, but you could add option here in the
.vimrc file now or later,
e.g. put:
let g:easytags_syntax_keyword = 'always'
afer the call plug block.
Anyway.
:wq write quit the .vimrc
source ~/.vimrc unsure if required as will do later
vim test.js open vim with test.whatever language you know.
:PlugInstall in vim
Here might take a bit of time.
Then :q out of that window.
:source ~/.vimrc this is needed
Then test out to see if you have syntax highlighting.
I'm pretty sure this is along the right lines. Might be misspelled plugin name.
I checked following things, tags file path is set properly.
the macro tag i am looking for exist in the tags file. task/function/parameters etc works without hiccups. i have problem only with regex.
the expression present in ctags file are
1. --regex-SystemVerilog=/^\s*`define\b\s*(\w+)/`\1/d,define/
2. --regex-systemverilog=/^[ \t]*`define[ \t]*([a-zA-Z_0-9]+)/`\1/d,define/
both the options does not work.
When :tag `altuvm_test_arg works, but the corresponding CTRL-] key doesn't, this often is caused by incompatible 'iskeyword' definitions, so that actually gets passed to :tag is altuvm_test_arg (without the leading backtick).
You can check the scope of keyword matching (when on such a tag) with the * command, which highlights the same keyword under the cursor. If backticks are excluded, try adding the backtick to the range of keyword characters:
:setlocal iskeyword+=`
If this helps (and doesn't break things like syntax highlighting, or annoys you with the changed navigation of commands like w and e), you can make that setting permanent for verilog filetypes put putting it in ~/.vim/after/ftplugin/verilog.vim.
we all know what ci" ci' ci( ci[ ... does. Very handy in everyday's editing. I found something strange, and checked the help, didn't find out why.
say, I have a file:
foo "target"
foo 'target'
foo (target)
foo {target}
foo [target]
foo <target>
if my cursor at the beginning of each line, (on the 'f'), then I type ci", ci', ci(...
the cix works only with quotes (single or double), doesn't work for brackets. why do they behave differently?
(dix, vix the same)
tested with --noplugin, vim 7.3
thank you.
Update
thanks #romainl for the answer. I still have doubt regarding the "pair processing in vim"
check this example:
foo "targ\"eti\" some\"thing else "
if I have a line like above, I type ci", no matter cursor is at beginning or between quotes, it works perfectly, it seems that vim does have the idea of "pair"?
and this maybe what you meant about the pairing ?
foo "target x some"thing else "
foo (target x some(thing else )
I have above two lines, if (cursor at x) I type ci" and ci(, nothing happened to 2nd line, but first line changed into:
foo "I"thing else " (I is cursor)
ci( is consistent with ci[, ci{ and cit and all the other <action>i<something>. Only ci' and ci" work like they do. The outliers are the quotes, here, not the brackets.
Vim doesn't consider that quotes come in pairs while brackets do. It has an internal logic for matching pairs that works with actual pairs but not with quotes hence the difference in behavior.
You are not the first to complain about that discrepancy: this is one solution, maybe you can find others.
edit
I don't have a deep knowledge of Vim's internals, unfortunately, so I can only make assumptions, here.
If you ask Vim to do ci" it does its best to find a pair of double quotes but double quotes don't go by pairs: there's no way to tell if a " is the closing one or the opening one contrary to brackets. Because of that, Vim must make some choices. IMO, the choice that would make the most sense considering how the other members of the family work, would be to assume that the cursor is between the quotes and select from the first one to the right to the first one to the left. I can only assume that this method proved wrong in some way or didn't work for some reason and that the other method (the current one) prevailed.
Another explanation could be that the i<something> mechanism is somehow tied to a specific subsystem (maybe the same as showmatch?) that is unable to deal correctly with quotes.
Anyway, just like you, I find this discrepancy weird and I've somehow internalized it and aligned my usage of <action>i" to how the others work. To the point of actually doing 2t"ci" or some variant instead of ci"!! Inefficient, I know.
Did you read :h a'? I completely forgot where I got my "limited understanding" of the issue but it was there! It says:
"Only works within one line. When the cursor starts on a quote, Vim will figure out which quote pairs form a string by searching from the start of the line."
What I get from that is this: for some reasons unknown to us, Vim uses another mechanism for matching quotes than for the other pairs and that is why ci" is different from ciband friends. The underlying cause is not clear at all but I'm fairly certain that the big picture looks a lot like what I imagine.
To me, it looks a lot like a bug or a limitation disguised as a feature.
If you are still curious, I'd suggest you ask any further question on vim-dev.
make use of %
" nnoremap cb cib
nnoremap cb %cib
" nnoremap vb vib
nnoremap vb %vib
nnoremap yb %yib
nnoremap db %dab
to enhance %:
https://github.com/andymass/vim-matchup#tocbar-dopjfd
b can match ( [ {,
Want to use ' to match both ' and "?
nnoremap c' :call DoubleAsSingleC()<CR>
func! DoubleAsSingleC()
" When [!] is added, error messages will also be skipped,
" and commands and mappings will not be aborted
" when an error is detected. |v:errmsg| is still set.
let v:errmsg = ""
silent! :s#\"\([^"]*\)\"#'\1'#g
if (v:errmsg == "")
echo "双变单"
endif
exec "normal ci'"
endfunc
Similar for:
d'
y'
v'
I'm using Vim 7.3 on Ubuntu linux.
When I'm editing a YAML file
This:
fnordy fnord: fnord
fnords: super fnord
"fnords" would be colorized, but "fnordy fnords" would not be.
How can I fix this? I'm looking at my /usr/share/vim/vim73/syntax/yaml.vim file, but I don't understand it enough to fix this.
UPDATE
:color
slate
:echo &ft
yaml
On fnord: fnordy (at the beginning of the line): yamlBlockMappingKey
On fnordy fnord: fnord (at the beginning of the line): yamlPlainScalar
As a result of steffen's help, I compared both of the parsing commands.
The current script looks like this:
execute 'syn match yamlBlockMappingKey /^\s*\zs'.s:ns_plain_out.'\ze\s*:\%(\s\|$\)/ '.
\'nextgroup=yamlKeyValueDelimiter'
The problem, specifically, is the s:ns_plain_out, which is a non-space pattern
So I changed the pattern to simply match on any character:
execute 'syn match yamlBlockMappingKey /^\s*\zs.*\ze\s*:\%(\s\|$\)/ '.
Which fixes this particular issue.
According to the YAML specification, spaces are valid characters in keys of mappings. Have a look at 3.2.1.1 in the specification and at this example.
I'd say that the highlighting is correct. You have an unmeant linebreak in your first value using quotes (like in this example).
Building on the accepted answer, here's what I put in my .vimrc to get this fix without editing any core vim files:
autocmd FileType yaml execute
\'syn match yamlBlockMappingKey /^\s*\zs.*\ze\s*:\%(\s\|$\)/'