Lately I have been encountering a problem in VIM.
I use the shortcut >> (hold shift, press the period key twice) to indent a line. Sometimes I must be hitting something wrong because this shortcut stops working until I restart VIM.
Every time I try to indent with the shortcut it says "1 line >ed 1 time" instead of indenting. Or, if I have 3 lines selected and try to indent them all it will say: "3 lines >ed 1 time".
How do I fix this and restore the shortcut?
Thanks!
I have no idea, why your shortcut is not working, or what's the wrong key that you have pressed.
Regarding your 1 line >ed 1 time message: What you're doing is to shift a number of lines to the right. Vim is just notifying you about what was done, which is: One line is right-shifted one time. The > here is the right shift operator and >ed is just short for "shifted". If you do the opposite it says <ed, which is shifted to the left.
You can find more details in vim's help with: :help >
When a section is marked (visually marked) one > is sufficiant. The 2nd > should start another indentation, but since now nothing is marked it waits for another >.
More than this, I couldn't reproduce any error. (As it was mentioned by frosch03, the msg is just the normal response)
ed was an (well, probably still is) old editor, but I doubt that is what Vim is telling you. I cannot reproduce the message you're getting, nor find anything in the documentation regarding it.
Does this happen also when you're using a clean Vim (when you start it without vimrc with vim/gvim -u none)? If so, could you paste your vimrc if it's not too big somewhere (one of those paste sites should do nicely), so we can take a look to see is there any weird combo inside causing that behaviour.
Apart from that, not much advice I can offer regarding the given data :/
Related
I was going through Lesson 5 in vimtutor, and I had selected a part of lesson 5.3 in visual mode, and then done :w TEST as instructed in lesson 5.3.
In Lesson 5.4 however, I was told to do :r TEST, and so I did do that.
The text from the file TEST was indeed pasted right in to where I had the cursor.
However, when I tried to press the j key to move down further, something weird happened. The line after which I had my cursor on came up to the line I was working on (both these lines were from the pasted text from TEST file), the apparent line break gone.
Eg.
line before I press j
another line
became
line before I press janother line
for some reason.
What I've tried:
pressing Esc. This results in literally nothing happening
looking up Lesson 5.4 and read function of vimtutor and vim in Google and see if others had had this error. Nothing relevant came up.
Anyway, thanks for the help in advance!
Sounds like you hit J which does a « join » on the two lines.
Check your shift key/caps lock.
Say that in the following paragraph my cursor lies on the first are in the first sentence (wish I could highlight it, but I can't so ...). Upon pressing ff twice that will get me to fools in the first sentence, and then to of. Further pressing it will get me nowhere.
Some people are confident because they are fools. Leonard had the look of
someone who was confident because, so far, he'd never found reason not to be. He
would step off a high building in the happy state of mind of someone who
intended to deal with the problem of the ground when it presented itself.
What would I need to modify so I can "move" across lines, so that further pressing ff will make Vim jump into the next lines?
Nothing to modify except Vim's source code. fFtT are linewise and there's nothing you can do about it. See :h left-right-motions
You could use /f, which is not limited to the current line, instead but it's not as fast as it requires another keypress.
Or a plugin like easymotion.
Did you know that you can hit ; to redo the previous fFtT?
There are a couple of solutions, but none do exactly what you want. Usually in this situation I would do ff followed by a series of ; characters to repeat f. When I reach the end of the line I hit + and then continue with ;. Similarly, you can use , to go backwards and 0<BS> to go back a line.
Another option is to write lines with set wrap and no hard breaks, but for various reasons users may not find that ideal.
Despite this seeming like nonsense it can actually be useful in some situations. For example, the :norm command will skip a line if ff doesn't find anything. You can use this for complex :norm commands over multiple lines to check for a particular character before you proceed with the command.
Edit:
There's a plugin that accomplishes this: https://github.com/dahu/vim-fanfingtastic
I love NANO. It's always there, it can slice and dice, and its NOT VIM!
But I am constantly hitting Command / - inadvertently - as I go along, out of habit.. Most IDE's use this convention to "comment out" a line.
NANO has great syntax highlighting.. so it knows the context of my documents.. but I haven't been able to figure out a way to get it to perform this basic, yet relatively important function.. Hand-commenting is for the birds.
I suppose this is sorta a super-user question, but in my experience, this would get a bunch of blank stares and then a few people asking who Nano was, so... here it is...
Oh and PS, brownie points for anyone that knows how to get DashCode to be able to do this as well... It would be the finest Javascript IDE EVER if it could perform this trick... and I'm convinced Apple omitted the feature for just that reason, lol.
The simplest workaround I've found:
Comment-out:
set the cursor at the first row that should be commented-out
hit twice 'M-R' (or 'Alt-r'; in order to Replace a RegExp)
Search for: '^'
Replace with: '# '
Replace this instance?: 'y'
press 'y' for each row to be commented-out
Comment-in:
The same procedure, replacing '# ' by ''
New in nano 2.6
(2016 June 17)
comment/uncomment lines with default binding M-3 (Meta-3)
(http://git.savannah.gnu.org/cgit/nano.git/tree/NEWS)
Customization
If you do not like the default mapping, note following:
Using Ctrl-/ by rebinding it in ~.nanorc with bind ^/ comment main is not possible. On a linux console this is equivalent to a backspace (https://savannah.gnu.org/bugs/?53248).
Some possible alternatives could be:
Meta-; (emacs)
Alt-/ (micro)
While accepted answer is de jure correct, it doesn't really help if you're not proficient in Nano already.
Indeed since Nano 2.6 this functionality is available as M-3 (Meta-3). But what it actually means (see doc) is that comment\uncomment can be done via these hotkeys:
<Alt> + 3 // <Alt> is default <Meta> command
<Esc> + 3 // Single <Esc> should also work
And since usually you need to comment out several lines, you can use Alt + a (or Meta + a / Esc + a) to switch to selection mode which will allow to select several lines. Then comment command will be applied on all selected lines at once.
Related question: How to comment multiple lines in nano at once?
I have a file where I store snippets of vim commands. When I need a snippet, I yank it and then execute it with #". The snippets are stored as a script, one line per command, like this:
:s/foo/bar/g
:echo "hello"
:s/1/2/g
Edit: I removed normal mode commands from the example, as they were not part of the problem.
Now this procedure doesn't work anymore: when executing the snippet, it just stops at the first line as if waiting for a newline.
Is there an option somewhere affecting how # is executed? I'm pretty sure it was working some time ago...
Substituting the newline with a ^M character works but makes the file more difficult to handle.
Additional information:
Here's another symptom: when I yank a snippet, if I execute it with #" it stops at the first line as I just explained. But if I execute it with :# it works. But the help file doesn't seem to imply any difference in how the two commands treat the register's content...
I don't think the problem is ^M vs. ^J. Vim macros will treat either one as a valid end-of-line character for recorded macros. I think the problem is extra newlines.
In your example, there's at least one spurious newline after 2j, and unless you're particularly careful when copying the snippet, there's probably another one after 10k as well. These extra newlines are like pressing <Enter> in Normal mode -- they move the cursor down one line.
Here's what I think you want the snippet to look like:
:s/foo/bar/g
2j:s/1/2/g
10k
(Even that's a little misleading -- you'd still have to be careful not to copy the newline after the 10k.)
Why do these extra newlines make such a big difference? Well, for one thing, they cause you to be at least one line away from where you expect to be, which throws off anything you want to do on a particular line (like execute the :s// command).
More importantly, however -- and this is what I think is happening in your example -- is that Vim stops macro playback if the macro attempts to use <Enter> on the last line of a buffer. (I'm guessing Vim considers it an error, and any error causes a macro to stop running.)
Here's an example. Suppose you've got this snippet stored in register x:
4j
:echo "Done"
(Notice the newline after 4j.)
Furthermore, suppose you have the following five lines (and only these five lines) in a buffer:
line 1
line 2
line 3
line 4
line 5
If you now press #x on line 1, the :echo "Done" never executes. Vim moves the cursor down 4 lines to line 5, then attempts to move down one more line because of the extra newline, but it can't. The macro stops executing at that point, before the :echo command gets a chance to run.
However, it works if you change the x register to this:
4j:echo "Done"
So to return to your original example, I'll bet what's happening is that the extra newline after 2j is attempting to move your cursor somewhere it can't go, and that causes the macro to stop. The bottom line of the screen contains the last command executed (:s/foo/bar/g), which makes it look like Vim is waiting for you to press Return.
Finally, I'd strongly recommend using another method to store and execute Vim command sequences. The technique you're using is tolerable for simple cases, but it's fragile and doesn't scale well. Vim has a full scripting language that includes functions and custom commands, and it can be used to do all the things you're doing now, but in a much more robust fashion. Vim scripting is a big topic, but I'd start here:
:help script
Be sure to read about the :normal command, which lets you execute Normal-mode commands (like 2j and 10k) within scripts.
Good luck!
I finally found the culprit. Somehow I had a command mapping on <C-J> in my .vimrc file. When read with the default cpoptions, this turned into a mapping on <NL>.
How I found out: I noticed that when starting vim with -u ~/.vimrc, it would indeed execute yanked snippets. I generated a session file with and without that commandline option and compared them. This way I found out that a different set of cpoptions where used to read the same .vimrc file, so that in one case the mapping was indeed on <C-J>, in the other it was converted into a mapping on <NL>!
If someone has a similar problem, I suggest to look carefully at the currently set command mappings, with :cmap.
Smething just happened in the last 20 minutes or so to my vim. I must have hit something, but I can't figure it out, and nothing will get it back to the 'real' behaviour.
I've always used : to jump to a line number. Now, when I hit : then a number - (1-9), vim instead goes in to "insert" mode and inserts a letter. (1=q, 2=r, 3=s, 4=t, 5=w, etc.)
Trying to search around for this is worse than looking for a needle in a haystack!
Any ideas as to what sort of secret "mode" I've enabled? And better yet, how I might get back to normality?
Thanks!
Not sure what you've done there but you can also jump to a specific line number by entering the line number and then hitting G (Shift+g).
Shift+g on its own will take you to the last line of the file.
It could be your shell and not VIM. If restarting VIM doesn't fix your problem, try opening a new shell and using VIM there. If nothing works, move your .vimrc file and any shell start ups out of the way (by renaming, not deleting, of course), open a new shell, and VIM. If that doesn't work, try a new keyboard. :-(
Closing and opening vim should reset whatever you funky mode you've discovered. If not, you've got something profoundly weird going on -- vim doesn't store settings that are turned on while in the file.
BTW, you're totally ruining my "vim doesn't break" meme.
Well, I've no idea what it was, but rebooting the computer - Macbook running leopard - seemed to work.
I'd tried new shells to no effect. I just didn't want to have to reboot.
See - macs have problems too! :(
Thanks for all the quick responses from all y'all. Hopefully I won't have to figure that one out again.