I resisted Vim, but have now given in. It works large files like a hot knife through butter.
Situation: I have a large text file, I want to put a pipe character at the beginning and ending of each line.
Problem: These Vims and other variations didn't work:
:%s/$/|\$|
:%s/\r/|\r|
:%s/$/|\r|
I suspect it's something simple to fix this, but searching Google and Stack didn't help.
You nearly had it:
:%s/^\|$/|/g
^\|$ means beginning or end of line. In a Vim regex, the | "or" pipe gets escaped. That is followed by /|/g -- replace with | globally.
Personally, I'd prefer the expressiveness of 'surround each line with pipe chars':
:%s/.*/|&|
This, in my brain, is more intuitive than 'replace a non-existing, imaginary character at the start or end of a line'.
It also depends on fewer magic chars (^,$, quoted \| which are all clumsy to type and error prone. (I mean, do you remember to quote the regex |? Do you know the difference between $ and \_$? Did you know some, if not all, of these depend on the 'magic configuration' of vim?)).
The above suffers from none of those.
Related
I mainly use curly brackets { } to move around in vim when I'm working on something. However, sometimes it will skip too many lines. I assume this is because there is no paragraph break, because if I go put new lines in, I can skip to those. This is mainly an issue when working on HTML that I didn't type or after pasting in some lines. It is very annoying when it skips too many lines for me to see what's between where I started and where I ended.
I hope I've described this well enough for some of you to know what I'm talking about.
Is there a remedy for this other than going through using j and adding line breaks? It's a huge hassle and blow to productivity when having to do this.
EDIT: I wanted to mention I only use the curly brackets to get close to pieces I need to work on. After I am close, I use other means.
That sounds like an issue where some lines contain only whitespace, and so don't get counted as paragraph breaks, even though they look like they should. Since it's only an issue in a few situations, I'd suggest just running a substitution to clean up those lines whenever you notice that it's a problem. For example:
%s/^\s*$//g
To translate what the regex means:
^ match the start of a line
\s* match any number of whitespace characters
$ match the end of the line
So it matches anything that contains only whitespace between the start and end of the line, and replaces it with nothing (note that replacing $ does not overwrite the newline character).
I am trying to run this command in vi
:s/href="\//href="http:\/\/website.com\/folder\/subfolder\//g
but got this error E486: Pattern not found: href="\/
What am i doing wrong?
That error means pretty much what it says. vi didn't find any pattern href="/ (ignoring escapes) in your file.
Sometimes it's easier to use something besides / for the search delimiter if your search has a lot of slashes, so you don't need to escape them all. Try replacing the / delimiter with # instead, like this:
s#href="/#href="http://website.com/folder/subfolder/#g
Then maybe you can more easily see what's wrong with your pattern:
becouse there are many '/' chars, try use another delimiter, ex ',':
:s,some/pattern/with/slashes,new/string,g
On another note. That substition worked for me. Just copied and pasted. Are you on the same line that you are trying to perform the substitution on? the 'g' is meant globally on the line you are on. If you need to perform the search and replace on the file the use :%s/
Is there any way using either Vim scripting or search/replace to remove ghost newlines? I have come across times when I have to edit files that other developers using crappy software have left double newlines in like the attached picture.
I would love to find a way in Vim to remove all those stupid double spacing junk so it actually looks like it should.
Running the search-and-replace
%s/\n\n/\r/g
will replace every pair of two newlines with a single one. This will inevitably screw up files that aren't already double-spaced, though, so don't use it blindly.
Shorter solution:
:v:.:d
It those lines are really empty. If there might be white spaces:
:v:^\S*$:d
So oftentimes, while editing with Vim, I'll get into a variety of situations where whitespace gives me hassle. For example, say I have a comment like this:
#This program was featured on the Today show, it is an algorithm for promoting world peace in third-world countries
#given the name of that country and the name of a celebrity to endorse its cause
If I want to, for example, trim the lines so they go to X characters, I end up putting a newline somewhere in the middle of the top line to get this (after hitting the newline and auto-indenting):
#This program was featured on the Today show, it is an algorithm for promoting
world peace in third-world countries
#given the name of that country and the name of a celebrity to endorse its cause
I then add a # to the beginning of the line, and that's all well and good, but then I want that line to line up, too. To do so, I have to delete the newline, all the whitespace for the indent on the next line, and then the commenting # mark. It doesn't take an awfully long amount of time to do that, but this and similar situations all add up over a day's worth of coding.
Now the example above is pretty specific, but my question isn't. What's a good way in Vim to delete all whitespace INCLUDING NEWLINES up until the next non-whitespace character? If Vim already has movements that do that, that would be awesome, but if not, does anyone have a favorite Vim function they use to do the above that could be mapped to a key? At the very least, am I missing some Vim usage idiom that prevents me from even having to worry about this case?
EDIT: Formatting to width, while useful and applicable to the case above, isn't the focus of this question. I'm concerned more with whitespace removal that doesn't stop at the end of a line, but instead carries on to the first non-whitespace character of the next line.
You really just want to reformat that comment to fit the current 'textwidth'. If the comment is a paragraph (i.e., separated by a line of whitespace above and below), then you can just use gqip (gq is the reformat command, ip is the "inner-paragraph" text object) to reformat it. If it's not a standalone paragraph, you can visually select those lines and then use gq.
This likely also relies on having 'formatoptions' set correctly to make sure the comment characters are handled properly, but in many cases the ftplugin has already done that.
This is a while later, but I found that there is a command that does what I need to in 90% of circumstances:
J -- join line below to the current one
This command seems to work:
:.s/\W*$\n\W*//g
it uses a replace to remove whitespace up to end of line and the new line at the end.
In this example:
testting aad $
asdjkasdjsdaksddjk$
(to see meta characters in vim use the command :set list)
if you place the cursor on the first line and use the first command it will delete everything from aad to $ (not including aad but including $ and a newline.)
Also, note for what you are doing it is far more efficient to use an external program to format comments for you. In particular, par is a great small C program that edits text and wraps it to desired lengths.
If you have par in your path, to do what you are trying to do is as easy as selecting the block of comment with Shift+v and running the command
:!par 40pgr
where 40 is the desired width in columns.
If you are feeling hackish, write your own program in C/perl/C++/python that edits comments however you like, then put it in path and use the external filter command :! to process blocks of text through it.
Vims errorformat (for parsing compile/build errors) uses an arcane format from c for parsing errors.
Trying to set up an errorformat for nant seems almost impossible, I've tried for many hours and can't get it. I also see from my searches that alot of people seem to be having the same problem. A regex to solve this would take minutesto write.
So why does vim still use this format? It's quite possible that the C parser is faster but that hardly seems relevant for something that happens once every few minutes at most. Is there a good reason or is it just an historical artifact?
It's not that Vim uses an arcane format from C. Rather it uses the ideas from scanf, which is a C function. This means that the string that matches the error message is made up of 3 parts:
whitespace
characters
conversion specifications
Whitespace is your tabs and spaces. Characters are the letters, numbers and other normal stuff. Conversion specifications are sequences that start with a '%' (percent) character. In scanf you would typically match an input string against %d or %f to convert to integers or floats. With Vim's error format, you are searching the input string (error message) for files, lines and other compiler specific information.
If you were using scanf to extract an integer from the string "99 bottles of beer", then you would use:
int i;
scanf("%d bottles of beer", &i); // i would be 99, string read from stdin
Now with Vim's error format it gets a bit trickier but it does try to match more complex patterns easily. Things like multiline error messages, file names, changing directory, etc, etc. One of the examples in the help for errorformat is useful:
1 Error 275
2 line 42
3 column 3
4 ' ' expected after '--'
The appropriate error format string has to look like this:
:set efm=%EError\ %n,%Cline\ %l,%Ccolumn\ %c,%Z%m
Here %E tells Vim that it is the start of a multi-line error message. %n is an error number. %C is the continuation of a multi-line message, with %l being the line number, and %c the column number. %Z marks the end of the multiline message and %m matches the error message that would be shown in the status line. You need to escape spaces with backslashes, which adds a bit of extra weirdness.
While it might initially seem easier with a regex, this mini-language is specifically designed to help with matching compiler errors. It has a lot of shortcuts in there. I mean you don't have to think about things like matching multiple lines, multiple digits, matching path names (just use %f).
Another thought: How would you map numbers to mean line numbers, or strings to mean files or error messages if you were to use just a normal regexp? By group position? That might work, but it wouldn't be very flexible. Another way would be named capture groups, but then this syntax looks a lot like a short hand for that anyway. You can actually use regexp wildcards such as .* - in this language it is written %.%#.
OK, so it is not perfect. But it's not impossible either and makes sense in its own way. Get stuck in, read the help and stop complaining! :-)
I would recommend writing a post-processing filter for your compiler, that uses regular expressions or whatever, and outputs messages in a simple format that is easy to write an errorformat for it. Why learn some new, baroque, single-purpose language unless you have to?
According to :help quickfix,
it is also possible to specify (nearly) any Vim supported regular
expression in format strings.
However, the documentation is confusing and I didn't put much time into verifying how well it works and how useful it is. You would still need to use the scanf-like codes to pull out file names, etc.
They are a pain to work with, but to be clear: you can use regular expressions (mostly).
From the docs:
Pattern matching
The scanf()-like "%*[]" notation is supported for backward-compatibility
with previous versions of Vim. However, it is also possible to specify
(nearly) any Vim supported regular expression in format strings.
Since meta characters of the regular expression language can be part of
ordinary matching strings or file names (and therefore internally have to
be escaped), meta symbols have to be written with leading '%':
%\ The single '\' character. Note that this has to be
escaped ("%\\") in ":set errorformat=" definitions.
%. The single '.' character.
%# The single '*'(!) character.
%^ The single '^' character. Note that this is not
useful, the pattern already matches start of line.
%$ The single '$' character. Note that this is not
useful, the pattern already matches end of line.
%[ The single '[' character for a [] character range.
%~ The single '~' character.
When using character classes in expressions (see |/\i| for an overview),
terms containing the "\+" quantifier can be written in the scanf() "%*"
notation. Example: "%\\d%\\+" ("\d\+", "any number") is equivalent to "%*\\d".
Important note: The \(...\) grouping of sub-matches can not be used in format
specifications because it is reserved for internal conversions.
lol try looking at the actual vim source code sometime. It's a nest of C code so old and obscure you'll think you're on an archaeological dig.
As for why vim uses the C parser, there are plenty of good reasons starting with that it's pretty universal. But the real reason is that sometime in the past 20 years someone wrote it to use the C parser and it works. No one changes what works.
If it doesn't work for you the vim community will tell you to write your own. Stupid open source bastards.