I have XML entries that span two or more lines sometimes, and so I can look for something like this:
something on one line
But if I try the vim command /something on one line and the line is like this:
something on one
line
then it doesn't find it, because the second text block is actually seen as
something on one^J line
Which might have something to do with the fact that I'm using a DOS formatted file.
How can I get vim search to ignore whitespace and newlines?
In vim search, _s means a new line, a space or a tab. So you can try something such as:
/something on one\_s*line
to match the example string you used as example.
Replacing the spaces with \_s\+ manually is cumbersome. The Search for visually selected text topic on the Vim Tips Wiki has a mapping that does this for you for the current visual selection. You can use it like the built-in * mapping, to search (ignoring spaces) for the current selection. Very handy!
While I like the existing answers, I was looking for a way to do the substitution of spaces to \_s* "automagically" for every search that I type.
Luckily, such a solution is possible, as explained in this reddit post. I ended up using the following command:
cnoremap <expr><space> '/?' =~ getcmdtype() ? '\_s*' : ' '
This makes it so that whenever you type a space in a search command (either / or ?), all spaces that you type are automatically replaced by \_s*.
In fact, I only wanted this behavior for LaTeX files, so I added the following to my .vimrc:
autocmd FileType tex cnoremap <expr><space> '/?' =~ getcmdtype() ? '\_s*' : ' '
Related
I'm writing an errorformat string, and it works for the most part. My problem is that I have lines like this as the makeprg output:
Some text I want to show in the QuickFix window^M
Yes, the line ends with an spurious ^M character I want to remove. So, what I want in my QuickFix window is this, without the ^M character:
|| Some text I want to show in the QuickFix window
but I have this instead:
|| Some text I want to show in the QuickFix window^M
So far, this is the relevant part of my errorformat:
set errorformat=%+GSome text%m
I've tested, without success, something like this:
set errorformat=%+GSome text%m%-G^M%.%#
but it throws an error (not from the ^M which is a literal control-M char, not a caret followed by an M).
Obviously the solution is not using %G but I am at a loss here.
How can I remove the line ending character from the line here? And also, removing the initial || would be a plus, but I think it's impossible to do in Vim.
Thanks in advance!
Edited to make clearer how the input text looks
Well, turns out I found a solution, probably not very good but it works, using trial and error.
set errorformat=%\\(Some Text%*[^.]).%\\)%\\#=%m
That is, the solution is using the Vim pattern (regex) expressions within errorformat, which has a quite arcane look but works, together with %* to match unknown text on the rest of the line
The solution uses \#=, a zero-width match, and requires some kind of terminator for the line, which appears before the ^M character I want to ignore, and some kind of text appearing somewhere on the line to match that line and not others.
Probably there is a much better solution but this is the best I could do myself.
This has been bugging me for a while: I'm writing code that uses verilog-auto which means I'm editing in a verilog file with perl snippets injected into comment sections. One very useful thing that I like to do in Vim is to search for the whole word under the cursor with * and #. However, with perl syntax that contains variable names such as ${w} and $w, these shortcuts don't work.
I don't want to add $, { and } to my "keywords" list as there are many instances where I don't want these to count as part of a whole word. For instance, in verilog concatenation: {sig1,sig2[1:0]}, I wouldn't want {sig1 to be searched for as a whole word.
Is there a way to get "whole word" to recognize sequences via a regex or something? So only ${[a-z]+} or $[a-z]+ gets recognized as "keywords".
Either that or a separate keyboard shortcut that can let me search for the pattern under the cursor.
Here's a really ugly hack, but it works:
nnoremap * viW:s/\%V\$*{*\a*}*/\=setreg('a', submatch(0))/n<cr>/<C-r>a<cr>n
nnoremap # viW:s/\%V\$*{*\a*}*/\=setreg('a', submatch(0))/n<cr>/<C-r>a<cr>N
The only downside is that this will overwrite your last visual selection, so if you use gv a lot, this isn't the best solution. It also overwrites the a register, although you could pick a different one if you want.
I'm reviewing some logs with Java exception spam. The spam is getting is making it hard to see the other errors.
Is is possible in vim to select a block of text, using visual mode. Delete that block every place it occurs in the file.
If vim can't do it, I know silly question, vim can do everything. What other Unix tools might do it?
Sounds like you are looking for the :global command
:g/pattern/d
The :global command takes the form :g/{pat}/{cmd}. Read it as: run command, {cmd}, on every line matching pattern, {pat}.
You can even supply a range to the :delete (:d for short) command. examples:
:,+3d
:,/end_pattern/d
Put this togehter with the :global command and you can accomplish a bunch. e.g. :g/pat/,/end_pat/d
For more help see:
:h :g
:h :d
:h :range
Vim
To delete all matching lines:
:g/regex/d
To only delete the matches themselves:
:%s/regex//g
In either case, you can copy the visual selection to the command line by yanking it and then inserting it with <C-r>". For example, if your cursor (|) is positioned as follows:
hello wo|rld
Then you can select world with viw, yank the selection with y, and then :g/<C-r>"/d.
sed
To delete all matching lines:
$ sed '/regex/d' file
To only delete the matches themselves:
$ sed 's/regex//g' file
grep
To delete all matching lines:
$ grep -v 'regex' file
grep only operates line-wise, so it's not possible to only delete matches within lines.
you can try this in vim
:g/yourText/ d
Based on our discussion in the comments, I guess a "block" means several complete lines. If the first and last lines are distinctive, then the method you gave in the comments should work. (By "distinctive" I mean that there is no danger that these lines occur anywhere else in your log file.)
For simplifications, I would use "ay$ to yank the first line into register a and "by$ to yank the last line into register b instead of using Visual mode. (I was going to suggest "ayy and "byy, but that wold capture the newlines)
To be on the safe side, I would anchor the patterns: /^{text}$/ just in case the log file contains a line like "Note that {text} marks the start of the Java exception." On the command line, I would use <C-R>a and <C-R>b to paste in the contents of the two registers, as you suggested.
:g/^<C-R>a$/,/^<C-R>b$/d
What if the yanked text includes characters with special meaning for search patterns? To be on the really safe side, I would use the \V (very non-magic) modifier and escape any slashes and backslashes:
:g/\V\^<C-R>=escape(#a, '/\')<CR>\$/,/\V\^<C-R>=escape(#b, '/\')<CR>\$/d
Note that <C-R>= puts you on a fresh command line, and you return to the main one with <CR>.
It is too bad that \V was not available when matchit was written. It has to deal with text from the buffer in a search pattern, much like this.
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\|$\)/'
I am a new user of vim (gvim in windows), and have found abbreviations a nice time saver - however they would be even better if i could stop the trailing whitespace at times.
I have some directories that i use a lot, and so i added some abbreviation/path pairs to my _vimrc:
:ab diR1 C:/dirA/dira/dir1/
:ab diR2 C:/dirA/dirb/dir2/
etc ...
Now when i type diR1 <space> i get C:/dirA/dira/dir1/[]| where the whitespace is represented by [] and the cursor is the | character. I would like to get rid of the [] == whitespace.
This is a minor complaint: however you seem to be able to customise everthing else in Vim so i figured i'd ask -- is it possible to avoid the trailing whitespace when one uses abbreviations in vim?
An alternate tool used within Vim is a good answer - my objective is to save re-typing frequently used directory structures, but to have the cursor handy as i would almost always add something to the end, such as myFile.txt.
The trailing white space (doubtless due to the fact that the space triggered the abbreviation) which i backspace over before adding myFile.txt to the end is less annoying than typing the whole thing over and over, but it would be ideal if i could avoid doing so ...
pb2q answer is exactly what you want in your current scenario, but does not fully answer the question presented in the title. This exact problem is addressed in the vim help file. See :helpgrep Eatchar. The example it gives is this:
You can even do more complicated things. For example, to consume the space
typed after an abbreviation: >
func Eatchar(pat)
let c = nr2char(getchar(0))
return (c =~ a:pat) ? '' : c
endfunc
iabbr <silent> if if ()<Left><C-R>=Eatchar('\s')<CR>
You would put the Eatchar function in your ~/.vimrc file and then use like so in your abbreviations:
iabbr <silent> diR1 C:/dirA/dira/dir1/<c-r>=Eatchar('\m\s\<bar>/')<cr>
This would "eat" any trailing white space character or a slash. Note that I used iabbr instead of just abbr, because it is rare to actually want abbreviations to expand in command line mode. You must be careful with abbreviations in command line mode as they will expand in unexpected places such as searches and input() commands.
For more information see:
:h abbreviations
:helpgrep Eatchar
:h :helpgrep
This is possible, without more customization than just abbrev.
The abbreviation is being triggered by the space character, as you know. The space is a non-keyword character, and remains after the abbreviation is expanded.
But there are other ways to trigger the expansion, such as other non-keyword characters, including /. So if you instead define your abbreviations like this:
:ab diR1 C:/dirA/dira/dir1
That is, without the trailing path separator, then you can type diR1/, have the abbreviation expand for you because of the slash /, and continue typing, appending to your path with a file name.
Alternately, you can force abbreviation expansion using Ctrl-]. That is, type the abbreviation: diR1, with no following space or other non-keyword character, and then type Ctrl-]. The abbreviation will be expanded and you'll remain in insert mode, and can append your file name to the expanded path.
Check out :help abbreviations, there may be something else useful for you there, including more complicated constructions for always consuming e.g. the space character that triggered the abbreviation.
Instead of abbreviations, you could use mappings. They're expanded as soon as you have typed the last character of the mapping, so there won't be a trailing space:
:inoremap diR1 c:/dirA/dira/dir1
The downside for this approach is that the letters you type while a mapping could be expanded are not displayed until the mapping is finished. This takes some using used to.