I was thinking of mapping ,u to uncomment a block of code in visual mode, but first I wanted to make sure that ,u wasn't already doing something else important.
I selected three lines visually and typed ,u and I got the message at the bottom of the screen (where : commands are entered): "3 lines changed".
The lines didn't change, but maybe they would have under some circumstances. Obviously, vim is claiming to have executed some command, but what?
I typed :map and ,u was not listed as having been remapped. So I typed, :help ,u and it told me "No help for ,u" (read: No help for you!).
There's no ,u or <leader>u in my .vimrc. I haven't redefined comma as my leader.
If it were the unix command line, I'd type which ,u, but I don't know any equivalent in vim.
How do I figure out what, if anything, a given command is doing in any particular running instance of vim?
In visual mode, the comma does nothing but u lowercases the selected text.
This means that you can safely use ,u for a visual mode mapping: you will still be able to use u but , followed immediately by u will do what you want.
The :map command only lists mappings. Since built-in operators are not mappings you won't be able to see them there.
When a "shortcut" doesn't appear in :map, try vim's awesome documentation:
:help v_u " shows help for u in visual mode (note the v_)
If you get nothing, either from :map or from :help, using the those keys for your mapping may not be completely trouble-free. A bit of trial and error may be necessary.
Suggested reading:
Learn Vimscript the Hard Way: Chapter 3, 4 and 5.
Related
Apparently <c-space> doing something by default in vim but I can't figure out a way to check what it's doing.
:imap <c-space>
> No mapping found
:h <c-space>
> Sorry, no help for <c-space>
It's a little hard to give a fully generic answer here and sometimes your specific platform or terminal emulator might have an effect on how specific keys are seen by Vim.
One way to try to figure out which key code is seen by Vim is to go into Insert mode and then press Ctrl+V followed by your specific key. (See :help i_CTRL-V, which will tell you Vim will insert the next symbol literally.)
In my case, typing Ctrl+V followed by Ctrl+Space in Insert mode shows me ^#, which symbolizes the Ctrl+# sequence, which shows me that's how Vim is seeing this key sequence.
(I believe this is mostly universal, and Ctrl+Space will always generate Ctrl+# everywhere, but as I mentioned there are platform differences, so I can't guarantee it works that way everywhere, but you should be able to use the same Ctrl+V trick to find out if it's the same or not in your case.)
Following that finding, you can then look at :help i_CTRL-# to see that the Ctrl+# sequence (which should be equivalent to Ctrl+Space) will "insert previously inserted text and stop insert."
I feel like this is a very stupid question, but I can't seem to find the answer to this anywhere. I'm relatively new to vim. After a fresh install I installed the vim-LaTeX plugin, or the LaTeX-suite for vim. It works correctly apart for the fact that there are some commands I don't understand. It gives the following instruction:
To do this, visually select a portion of the text and press \ll while in visual mode. The visually selected portion will be saved to a temporary file with the preamble from the current document prepended. Latex-Suite will then switch focus to this temporary file and compile it
But if I press '\' it does nothing and double l moves the cursor to the right. I don't understand what I'm supposed to be doing, and I feel incredibly stupid. Sorry if off-topic.
The \ is the default value for the :help <Leader> key. Plugins are encouraged to start all default mappings with <Leader>. If you've redefined it, you need to use that key instead.
Otherwise, you need to press V \ L L (without Shift) in quick succession (by default within one second).
If you want to find out whether the plugin has been successfully installed and there's actually an action behind those keys, you can use either:
:verbose vmap <Leader>ll
:verbose vmap \ll
If Vim says No mapping found, or just lists other mappings starting with some of the keys, the plugin isn't installed properly, or you're not using it right.
Press v to go into visual mode. Then you can use your arrow keys to select text. After you've selected the text you want, type \ll.
That should be it.
I noticed that iTerm2 offers the very convenient feature of using "Option key as +ESC" (or as meta, but apparently that's obsolete).
I tried them both and the option key works as expected in Bash (set -o emacs mode) and Emacs, but not in Vim. Thus, I can't make use of any "M-" bindings.
What I've found is that:
if I set option to "+ESC", vim just understands ESC+key, and has no idea I actually meant Meta-key.
if I set option to "meta", keys modified with "option" behave just as without a modifier (don't know how to formally test what vim understands from a key combination that I'm typing).
"M-" mappings work perfectly in MacVim (7.3.53), but that's outside of a console and not in the scope of this question.
I'm interested in how to make those mappings work in Vim, under iTerm2 or Terminal.
My specs:
MAC OS X Lion 10.7.2
iTerm2 1.0.0.20111020
vim #7.3.107_0+python26 [though MacPorts]
I've downloaded the latest iTerm2 and tried to see what it sent to/what was printed by Vim (i<C-v><M-a>) with the following settings:
Option as Option:
Vim prints æ which is normal and expected on my french keyboard
Option as Meta:
Vim stays there, waiting for something to happen. Nothing is printed. If I press Option and a in sequence I just obtain a. Pressing Option and a in some random order may print á, which is weird and totally unexpected.
Option as +ESC:
Vim prints ^[a which means "Escape character followed by the character a".
From these tests it appears that Vim will never ever receive <M-> without some hypothetical black magic.
If you stick with "Option as +ESC", it seems that you will have to change all your custom <M-something> mappings to <Esc>something. This may work but it will make writing any kind of prose in any non-english language a pain.
What I do: I leave the Option key as it is so that I can type characters like œ…«» easily and I use <Leader> (mapped to ,, see :help mapleader) for all my custom mappings.
Some people here like to reserve it for plugins and advocate a somewhat simpler and potentially safer approach.
inoremap <leader>, <C-x><C-o> "my way (copied elsewhere)
inoremap ,, <C-x><C-o> "another way
I left my option key to act as Normal and discovered that Vim saw them as <T- bindings. So, for example, I have this mapping setup in my .vimrc to move to the end of a word when in Insert mode:
noremap! <T-Right> <C-o><Right>;
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. :-)
So I'm basically a beginner when it comes to Vim, nonetheless I do know the basic things (open files, edit, move around, basic grep, .vimrc, etc)
I would submit this link first
http://weblog.jamisbuck.org/2008/11/17/vim-follow-up
If you scroll down to where it says "NERD___tree", it explains what it is and gives a link to the home page. I have already gotten NERD_tree installed, so far so good.
Only thing is, this guy (JamisBuck) adds a line to the .vimrc file to streamline it's usage (I'm guessing to toggle between NERD_tree and the actual file, because as far as I can tell, there is no quick way to do it other than typing in:
:NERDTree
Every time which is less than desirable. The follwing is the code he adds to the .vimrc file:
map <leader>d :execute 'NERDTreeToggle ' . getcwd()<CR>
He doesn't explain exactly what is is and/or how to use it, so If someone could give me a short explanation and/or point me towards a resource to learn more about this, that would be appreciated.
I'd say :help leader will give you what you need, is an anti-slash by default.
Thus, map <leader>d will be launched when you do \d.
According to the vim documentation, the
<Leader>
Is a special variable that is replaced with the value of "mapleader" at the time the mapping is defined. So:
map <leader>d :execute 'NERDTreeToggle ' . getcwd()<CR>
Is mapping the mapleader and "d" to the toggle. If you look at the page you linked, earlier in the page he says:
I’ve got my <Leader> character (:h mapleader) mapped to the comma
(since it’s easier to reach than the backspace character).
let mapleader = ","
So the toggle should be ",d" as far as I can tell.
In addition to what others have said (d mapped to the command), the command, itself:
:execute 'NERDTreeToggle ' . getcwd()<CR>
Is simply executing the NERDTreeToggle command with the first argument as the current working directory. The at the end is a carriage return, and is just simulating a press of the enter key.
This means that when NERD tree opens, it will be in the current working directory.