Some of the commands in vim are given by first typing a colon (:) eg . :wq for saving a file and quitting . While some of the commands don't require a colon for example the Replace command (R). I want to know what is the difference between the two approaches ? Is there any specific rule as to which ones require a colon and which ones don't ?
You have to look into the history of vi, the predecessor of Vim, for an explanation. A long time ago, when text editing had to be done with a keyboard and attached printer (called a terminal), there was no mouse, no display other than the paper, and therefore, little interactivity. Editing consisted of short, mnemonic commands via an editor called ex. You issued a command addressing one or several lines (e.g. :substitute/foo/bar), and the editor obeyed. In case you were not sure about the command's effects, you could :print some lines.
Time passed, video terminals appeared, and the vi editor incorporated the ex commands (because they were useful and the programmers were used to them), but introduced more interactive commands like delete (x), insert (i), and so on. The ex commands are still available in command-line mode, which is started with :, and concluded with Enter.
Vi and Vim are special in this regard, because they have these different modes where the same keys mean different things depending on which mode one is in. To become proficient in Vim, you have to learn about the different modes, and how to best use them to achieve your editing goals.
:help vim-modes gives you a starting point into the excellent and comprehensive help facilities.
The commands that "don't require" a colon are called "normal (mode) commands".
The commands that "require" a colon are called "Ex commands".
Vim, being a modal editor, has many commands that are contextual to the mode you are in. The most obvious effect is that hitting the same key in different contexts may produce different results.
In insert mode, most keys on your keyboard are used to actually input characters into your document.
You have to switch to normal mode to yank, put, delete, move your cursor around… normal mode is where you do the laser-focused editing Vim is famous for and use commands like dcggsi/.* and so on.
You enter command-line mode by hitting : in normal/*visual* mode. It is typically used for two things:
perform administrative tasks (writing to disk, switching buffers, opening files…)
use cool editing commands like :m10 or :t1 or :g/foo/d…
The many commands that you can use in this mode are (very powerful) remnants of Vim's past and are called Ex commands.
In short, neither normal mode commands nor Ex commands start with a colon. The colon is simply used to change modes.
You are in different modes of vim. There are 6 basic modes in vim. They are
Normal mode
Visual mode
Select mode
Insert mode
cmdLine mode
Ex mode
In Normal mode you don't require to type :, this mode can be reached by pressing Esc.
The most important difference (IMHO) is that the colon commands are treated as words, not individual letters, and they aren't interpreted until you hit enter.
Commands in normal mode are treated as individual letters, each letter has a defined meaning, and they are executed as soon as vim knows what to do with them.
For instance, typing 'de' in normal mode, will delete everything up until the end of the word. But 'de' isn't really a command; it's two commands. "e" moves you to the end of a word, and "d" means "delete something; wait for the next key press to tell you how much to delete." When you type 'd', it waits for you to complete the instruction. As soon as you press 'e', the command executes (without waiting to see if you want to type anything more).
That means in normal mode, you can't have an instruction like "define" or "deliver" or "describe". You'd get as far as typing 'de', and vim would execute the 'de' instruction. By the time you got to the 'f' in define, you'd be starting a new instruction.
But in command line (colon) mode, the commands are treated as words. There could be a command called 'define' and another command called 'describe'. (There isn't, but there could be).
'w' could have been created as a normal mode command, if all it did was save the current file under the current filename. But ':w' does more than that. You can also do ":w new_filename", and you get a 'save as' function. That wouldn't work in normal mode. In normal mode "w new_filename" would save the file ('w'), do nothing (space), try to find the next search term ('n'), move to the next end-of-word position ('e')... and so on.
Related
I am looking for a way to use f followed by some character to jump to the next uppercase letter.
I ran across this question and want to use the accepted answer, since that did not appear to have any dependencies.
However, after I added the lines into my .vimrc, I cannot figure out how to actually jump to the next uppercase character.
I tried Ctrl-Right and Ctrl-o, and both orderings of them, but I could not jump to the next uppercase letter in the line. I also read the actual vim tip, but that also does not explain how to actually use the commands.
What is the correct sequence of commands, and in which mode, to actually jump to the next uppercase letter?
Does it have to be the find command? What about typing /[A-Z]? It'll find the next upper case character (even if it's on a different line), and it's fast to type. Pressing n will take you to the next one without retyping the command again.
What you found in the other answer was a macro command. VIM has a rich macro language that allows you to define functions. You can run a function by typing a colon and then its name.
Of course, typing :findNextCapitalCharacter is a bit long to type. You can use map to define a key macro that will basically type the letters for you to find the next command. I like prefixing my mapped macros with some character like %, so typing %c will find the next capital character.
Further Explanation
I'm currently just doing /\u, but I still want to know how to use the macro in that answer for my own learning. In the case of those macros, what is the actual means to invoke the macro command?
You're way ahead of me! I didn't know about \u being uppercase.
Looking at the answer, I see they're not defining a macro, but doing key mapping. Here's a quick intro:
In command mode (that's where you can't type in anything into your file, but where you can use commands), type in :map #$ iHello World and press return. Now, still in command mode, type #$. You'll see that VIM typed iHello World for you. The i put VIM into insert mode, so it could type in Hello World That's mapping!
In VIM, you have special map modes depending on the mode you're in. In the original VI, you had two modes: Command and Insert. In VIM, you have Command, Select, Visual, and Command-Pending modes. The different map command depend upon the mode. Type :help mapmode into VIM and press <RETURN> to see about the various map modes and their VIM commands. This will be VIM help manual sections 1.3 to 1.5. Read it thoroughly to understand what the different map command mean.
What the accepted answer is doing is entering the maps three different times, once for each mode. There are two different maps (one search to the previous and one search to the next), so six all together.
The accepted answer is mapping Cntrl-Left Arrow <C-left> and Cntrl-Right Arrow <C-Right> to each of these mappings. Much like I mapped #$ to Hello World.
Setting g:camelcase is setting a global variable called camelcase to a string. If the string is A-Z, it will be for just capital letters. If it's A-Z0-9, it's for capital letters and numbers. You should only define one instance of this variable.
I think you're problem is that you're typing in <C-Left> for the map. What you're suppose to type is ^V^-> where ^V is Ctrl-V and ^-> is Ctrl-Left Arrow. When you type that in, the map command will change those into <C-Left>.
Is there a way to make vim stuck in command mode with a : already typed in?
In that way, for instance:
I would type /fooEnter and the cursor would go to the beginning of the next line containing foo.
Next, I would be still on command line mode with a : already typed in for the next command.
Yes, start it in Ex mode, by invoking it either as ex or as vi -e.
You can also enter Ex mode from the normal visual mode by typing Q (must be upper case).
You can return from Ex mode to normal visual mode by using the vi command.
EDIT : This doesn't actually do what the OP is looking for. He wants to keep the visual display while keeping the cursor on the bottom command line. That may not be possible.
No, but you can map ; to : to put yourself "closer" to command mode.
I'll link to the Vim wiki instead of reposting identical information here.
http://vim.wikia.com/wiki/Map_semicolon_to_colon
You can build your own REPL, like this:
:while 1 | execute input(':') | redraw | endwhile
This is just a conceptual demo; you probably want to add a condition to quit this special mode. Also, commands like :append would need special handling to work properly.
As a last try, I could just initialize vim with -servername=FOO and then code a little script that would read from stdin and send remote-send to FOO whenever it detects(by parsing) a whole command was typed on stdin.
Then I would just use Vim and this other script side by side on different xterms/gnu screens.
EDIT
OK, I will use this one. This way I can even make :a command to enter vim's Insert mode and switch back to command mode when entering a line with a single .. This way I would also have syntax highlight on the fly when inserting text (you know, vim has a very pretty visual display of the text, I'm just too used with ed's interface). When I have so time I'll write this script and link it here.
Is there a command which shows what was the last command in normal mode?
Suppose I accidently hit random key and got some unexpected result.
Sure I can undo it, but could I reveal what key was pressed and how it was interpreted?
Hit the colon (:) and then use the up arrow to start going back through previous commands. You can use the up/down arrows too to move around the list.
q: will show you command history in Vim.
q/ will show you history of searches.
And must importantly, :q will quit the mode.
The text from the last command is stored in the . register. You can see all registers by :display. Unfortunately it doesn't say what the started the normal command.
To see commands from : (command mode) you can use :hist or q: which is limited to the last 20 (by default).
Another ability is to save the undo buffer :wundo undo.bin -- but the undo buffer is binary.
But none of these actually answer your question. I'm curious if it can be done.
Entering colon : then ctrl+p shows your previous command, i.e., moving backward through your vim command history. ctrl+n moves forward.
This is very convenient if you're used to using the command line and prefer not to change your keyboard hand positioning to use arrow keys.
It is difficult to know it. You can play with the variables:
v:operator
v:count (and v:prevcount)
v:register
But you cannot fully get the last normal mode command issued.
However if you want to systematically record everything you type while in Vim, you can launch vim -W ~/.vim-last-scriptout (a Windows version: vim -W "%HOMEPATH%\Vim\.last-scriptout) You can alias it in your shell on a UNIX machine. Every single key, or control-key, will be recorded into that file. Note that if you happen to use gvim or vim -g (the GUI) you might encounter this bug.
If you want to replay this file you can use :source! (with the exclamation mark) or the -s option from the command line.
On Windows I have set gvimportable.exe -W gvim_directory\last_scriptout as my default editor in my Commander program (FreeCommander). This way I can always remember what I have typed to do something and repeat a sequence of commands on another file. Of course I have another shortcut for opening Vim and playing the scriptout.
Note that the file might be written only when Vim exits, so you have to lose your session to know what you've done.
I've used vi for decades, and am now practicing using vim, expecting
eventually to switch to it entirely.
I have a number of questions, but I'll start with the one that
troubles me most. Something I have long done in vi is to type
a bottom-line command into the file I am editing, yank it to a named buffer
(e.g., using the keystrokes "ayy) and execute that buffer (using
:#a^M). This allows me to edit complicated commands till they
work right, and to keep commands that I will use many times as I
work in a file. (I have
in my .exrc file a mapping that reduces this yank-and-execute to a
single keystroke; but that isn't relevant to my question.)
I find that in vim, I need a lot more ^Vs than in vi. This
means, on the one hand, that when I have some command-line in a file
that I expect to use this way, I now need to keep it in two
versions, one for vi and one for vim. Also, the requirement of the
extra ^Vs seems inelegant: evidently various special characters
that are interpreted once when the named buffer is executed in vi
are interpreted twice when its is executed in vim -- but why?
As an example, a command of the form
map =f :w^V|e foo^M
(mapping the keystroke-sequence =f to write the current file
and go to the file foo) works this way in vi, but has to have the form
map =f :w^V^V|e foo^V^M
in vim. (Here in both commands, ^V is gotten by typing ^V^V,
and ^M is gotten by typing ^V^M; so typing the first version
involves typing three ^Vs, and the second, seven.) To be
exact: the first version does work in vim if one actually
types it into the bottom line (with the indicated extra ^Vs);
but the latter is required in an executed named buffer.
Any explanation? Anything I can set to fix this? ("compatible"
doesn't seem to do it.) Any hope that it will be fixed in a future
release? (The system I am on uses version 7.0.)
(I should confess that I'm not a programmer; just a user who has
become proficient in vi.)
Personally, I'd stop using ^V completely. In Vim (I've no idea about Vi), there are various key notations that get round the problems you're having. For your specific example, I'd recommend:
map =f :w<bar>e foo<CR>
where <bar> means 'insert the vertical bar here' and <CR> means 'insert a carriage return here'. See:
:help key-notation
for more information. I find the <CR> much easier to understand than ^V^M.
That's an interesting way of using :#, which I hadn't thought of before. I generally just use the command line history when I need to edit complicated commands, and I tend to save common or complicated commands as mappings or commands in my .vimrc (of course, I have a mapping that will pop open my .vimrc in a new tab). But there are certainly benefits to using vim's normal mode rather than command line mode for editing a complicated command.
As I understand it, you not only want to avoid so many <C-V> characters, you would also like to be able to use the same commands in vim and vi. Unfortunately, that would preclude you from using the (preferred in vim) key-notation. I think that you should be able to use the cmdline mode's Ctrl-R Ctrl-R register to help you out (:help c_<C-R>_<C-R>). E.g.
map <Leader>e mm^"ay$`m:<C-R><C-R>a<CR>
mm - mark cursor location so we can return later
^"ay$ - yank current line into register a (ignoring whitespace at beginning and newline at end)
``m` - return cursor to start position
: - enter command line mode
<C-R><C-R>a - place the literal contents of register a onto the command line, which seems to be where your problem with vim versus vi was coming to into play. I think that <C-R>a would give you the same behaviour you are seeing now with :#a.
- execute the whole thing
Using that mapping, I then typed your example of map =f :w^V|e foo^M into a file, placed my cursor on that line, ran my <Leader>e mapping, verified that your =f mapping had loaded correctly, and then ran it. Obviously you'll want to customize it to fit your needs, but I think that playing around with <C-R><C-R> will basically get you what you want.
All of that said, if you can, I'd strongly recommend taking the plunge and forgetting about compatibility with vi. Then you can use the much simpler key-notation and a host of other vim features. :-)
Let's see if I can explain myself.
I use vi-mode in bash, which is really great since I'm used to Vi.
When I'm inside vim and type : (to go to ex mode), since I'm used to the vi-mode from bash, I feel the slowliness of having to use this mode like the "regular" way of using bash.
Question is: is there a way of using vim's ex-mode like bash's (or readline) vi-mode?
Not sure if I understand what you're trying to do, but it might be something like hitting q: in normal mode?
For users that use Vim or vi bindings almost everywhere, including on their shell command line, it really hurts when you leave that environment. If you're used to the vi bindings hyperdrive, going back to chords for skipping words and other manoeuvres is painful and slow. Operating systems also differ on their default bindings so Mac, for instance, supports option-arrow instead of control-arrow, adding to the pain.
But there is one place where this also happens where it's really upsetting: in Vim itself. When working in Vim and entering command mode using : the default readline editing returns. Chords all over again. How to fix this?
Simple: When in "normal" mode, that is, when navigating around, type q:
Vim will drop you at the bottom of a full Vim full screen editing experience, go for your life
Additionally the command history is available on previous lines in the buffer
You can yank and paste lines and edit the commands as much as you wish
To execute a command in "command" or "ex" mode just hit ENTER on the line you want to execute
Hitting enter on an empty line closes the buffer and does nothing
But this is just another buffer so you can quit it as usual with :q as well
Although ESC leaves the "ex" command line, ESC in the buffer will not leave the buffer, because it's an actual buffer
The q prefix is used to introduce macro recording, so the q: variant is perfectly mnemonic for entering recording of an "ex" command line.
Note that q: to enter the buffer editing mode is very similar to :q ! You may have hit that by accident sometimes ;-) Now you know how to get out of it!
Zigdon had this answer a long time ago, of course, but it's pretty darn sparse, but then again, so is the question. If Zigdon adds this extra detail to his answer I'll be happy to delete this answer so that there can be one good answer.