When I open the command-line window for editing a complex command-line in vim, I expect to be able to go back and forth in and out of insert / normal mode to edit as I would in any other buffer. (That's the point of the command-line window, right? So that I can do that?) But instead, when I hit ESC to go back to normal mode, I get this:
Error detected while processing function <SNR>15_CloseStackPop:
line 3:
E11: Invalid in command-line window; <CR> executes, CTRL-C quits: pclose
I'm game to try to figure this out, but I don't have a lot to go on. vim --noplugin doesn't seem to have this problem, so it's clearly one of the plugins I have loaded, but which one? I have quite a few. "line 3" of what file? What does "E11" mean?
It turns out that this was a bug in the 'autoclose' plugin. I removed the reference to pclose from the <SID>CloseStackPop function, and now Escape in command-line mode works fine.
In case anyone else has this problem: functions in plugins can be defined with <SID>, which (in the source code) just looks like <SID>Foo, but to Vim look like <SNR>4321_Foo. I was looking for 15_CloseStackPop, assuming that the <SNR> was something special, but when I just did a grep CloseStackPop -r ~/.vim/plugins the offending plugin came up right away.
Try Ctrl+C as a synonym for Escape. Also check .vimrc for the plugins. This isn't standard behavior for vi. If I were you I wouldn't use any plugins unless I was absolutely sure what they did. Perhaps start from scratch and reinstall the ones you feel completely sure of.
Related
The question is self explanatory, but I haven't found a single resource that explains what the difference is after an hour of searching. After poking around a little bit in both, it appears that gVim and gVim easy are identical.
Gvim easy is started and locked in insert-mode (every character you type is printed like a simple notepad).
Standard gvim starts in normal mode and you have to toggle between normal/insert like all other vim.
From help:
Easy mode. Implied for |evim| and |eview|. Starts with
'insertmode' set and behaves like a click-and-type editor.
This sources the script $VIMRUNTIME/evim.vim. Mappings are
set up to work like most click-and-type editors, see
|evim-keys|. The GUI is started when available.
{not in Vi}
gVim-Easy, which is installed with gVim, has all the functionality of
normal gVim but lacks modes. This is especially useful for begginers
and people who do not want to, or do not have the time to, learn how
to use gVim. Users can benefit from gVim's superior syntax
highlighting and auto-indentation while not having to have to learn
the, often deemed complex, command set of gVim in order to edit a
simple document. It is recommended that readers of this tutorial at
least try to learn how to use gVim in normal mode, the learning curve
is steep, but, the benefits in speed and usability this confers is
worth the investment.
Read here
gVim Easy: gvim.exe -y (pass a parameter y)
gVim: gvim.exe
It seems that Insert and Replace are available modes, and command mode is missing. And at first glance it appears to have lost the ability to save a document using keystrokes - the File menu shows only ":w" for Save and without command mode, the command simply isn't there. What isn't shown however is Alt-F followed by S - this works, although also missing is the status line confirmation of the file being written.
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'm using vim and im doing a lot of
:make
within vim. The only thing that is really annoying is that I have to press ENTER twice to jump back to the editor. I just want to go directly back if everything worked out fine. And I want to see the error once and press a key to jump directly to the error line.
Any ideas?
This is known as the hit-enter prompt:
If you accidentally hit or and you want to see the displayed
text then use |g<|. This only works when 'more' is set.
To reduce the number of hit-enter prompts:
Set 'cmdheight' to 2 or higher.
Add flags to 'shortmess'.
Reset 'showcmd' and/or 'ruler'.
Also, I'm sure you are aware of the quickfix window (:copen) to navigate errors/messages?
This can happen when the 'cmdheight' varible is < 2.
I had the same problem. This is a simple solution that seems to work:
map <F2> :silent make^M
Now I just hit the F2 key to compile and the annoying prompt is not so annoying.
Not sure if it would help you, but if you're on Windows you could try:
:set makeprg=start\ make
I think this will break the errorfile setting though.
See:
:help make
:help !start
I've come to a vim completion behavior that is very annoying for me and I cannot figure out how to configure vim to behave differently.Maybe it is not possible at all.
Suppose I'm editing file with following content:
MyCompany2
MyCompanies
MyCompany3
Now I want to add another entry (say MyCompanyABC) so I type My and hit Ctrl-N, so now I have
MyCompany2
Now I hit backspace, then A so I'm at
MyCompanyA
No I decide to try completion again so I hit Ctrl-N and vim takes me back to
My
So is there a way to make it so that the last step keeps what I already have?
UPDATE:
I gave the completion sequence wrong. The problem I describe appears if one first hits Ctrl-P. Then in the above scenario you get and the rest as above.
MyCompany3
This doesn't behave like this on my machine (Ubuntu 10.10, vim 7.2.330 here). If I do this:
Open vim by typing vi
Type the text you gave above
MyCompany2
MyCompanies
MyCompany3
Open a new line below
Type "My"
Press Ctrl-N
Choose MyCompany2
Backspace (get "MyCompany" after that)
Type A (get "MyCompanyA")
Ctrl-N does nothing - as expected, status bar says: -- Keyword completition (^N^P) Pattern not found.
Is it possible you have some plugin that is changing the default behavior? You can also try vi -u NONE to check whether you have something in your .vimrc that is changing this behavior. Best if you have some other system to check it out.
Are you sure that you want to use Ctrl-N directly without hitting Ctrl-X beforehand? Ctrl-N will also search in all opened buffers.
Maybe hitting CTRL-X CTRL-N or CTRL-X CTRL-P will result in a more stable completion.
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.