I'm new to vim. I use predefined .vimrc and have some small problems with it. Whenever I type the $ sign in insert mode, the insertion stops for a moment, and if I would type, for example, 1 afterwards two brackets () will be inserted. I don't know which of the plugins causes this behavior but I would like to disable it.
Can someone help me?
The documentation for this framework spells out this mapping on its main page:
inoremap $1 ()<esc>I
This mapping and related ones are specified in the extended vimrc file starting on line 82: https://github.com/amix/vimrc/blob/master/vimrcs/extended.vim
So, just delete those mappings in your copy of that file.
Note: I don't know anything about this project, nor have I tested this out. I'm just assuming this will work after quickly reviewing the project with the link you provided.
Related
For some reason my vim is weird when editing tex files, and I am not sure how to solve this problem. Here is an example, where I use | as the location of my cursor.
\begin{document}
| \title{Seminar report}
I then press fS to go to the beginning of the word Seminar (this works without problems). I then want to change the word to Evaluation, so I hit cw and the word is deleted and leaves me in insert mode. I type the E in insert mode and it looks like the following (I also added the v for visual effect):
\begin{document}
\title{ repEv|ort}
I am sure this is a problem in my .vimrc, but I don't even know where to start with it.
It seems there is some problems with plugins. In this case it is caused by YouCompleteMe.
The way I found out was to follow the link given by #mMontu
Vim-FAQ 2.5. helps.
Basically try to reproduce the problem with no vimrc loaded and gradually adding more until the problems reappeares. For me this happened, when I run vim with plugins, and after some time, specifically it was LaTeX-Box and YouCompleteMe.
A solution for the problem is not found, and I do not look for one anymore, as I will more to vim-latex in the near future (same authos as LaTeX-Box.
Recently when I tried to use the ctrl+n or ctrl+p to auto-complete, when there are multiple alternatives, tapping the enter button will insert a new line instead choose the alternative I want.
This did not happen before, maybe because I installed too many plugins and caused the conflicts. It would be horrible to check all these plugins' shot cuts and find out the source. So mapping the built-in auto-complete to some other keys could be a solution, but I don't know how to do that.
This is not a big problem but really made coding not "smooth". Anybody has met this situation before and how did you deal with it.
Short answer: You don't need to use <cr> to accept a match.
Snippet from the vim help :h popupmenu-keys
The behavior of the <Enter> key depends on the state you are in:
first state: Use the text as it is and insert a line break.
second state: Insert the currently selected match.
third state: Use the text as it is and insert a line break.
In other words: If you used the cursor keys to select another entry in the
list of matches then the <Enter> key inserts that match. If you typed
something else then <Enter> inserts a line break.
I would suggest you use <c-n> and <c-p> to switch to the correct mapping and then continue on with your typing. Typically this means I type a space or some other punctuation key and the menu closes. I never use <cr> to select a menu item. If however you really want to accept a match use <c-y>. Think "yes" to the selected menu item.
I just fixed a very similar problem caused by the vim-autoclose plugin by replacing it with the Auto-Pairs plugin. I doubt that yours is exactly the same culprit but it's actually not too bad hunting down the guilty party if you use pathogen for your plugins - just move half of your plugins from ~/.vim/bundle (or wherever they are) into a different folder, restart vim and test the autocompletion. If it works as expected, you know that one of the plugins you have moved out is responsible, so you can do the same again until you have narrowed it down.
Before that, you can also try running vim -u NONE which ignores your .vimrc file - it may be that you've snuck something in yourself and this is the fastest way to rule it out.
Good luck anyway. This took me about ten minutes and after probably a year of occasional annoyance I wish I had taken the time earlier.
I have a problem that's been bugging me for quite a while and that I can't find the solution to.
I want to use the feature where I can press <C-j> and the cursor moves to the next placeholder.
This works for regular files, but when I edit .tex files (i.e. latex-suite is enabled), this inserts:
\right=IMAP_Jumpfunc('', 0)
instead of actually jumping (which I presume is done by the above mapping somehow).
There's no problem with regular mappings (that I've made myself like so: map rhs lhs), but it doesn't work for any latex-suite macros. Other example: if I insert figure (via menu), it just inserts the following inside the text:
\right=Tex_DoEnvironment(``figure'')
Sorry I can't solve this problem myself, which is probably trivial for an experienced user. But I have no-one around to ask.
Looks like you forgot the <c-r>= before the call to the function.
EDIT: I think I understand. Whem IMAPS is installed, it quickly parasites all our mappings. You will have to use IMAP() to define you own mappings. I had to do it in my bracketing-system in order to be robust to IMAP/LaTeX-suite presence.
Gah, I found the error!
I had defined a key mapping like so:
:imap <C-r> \right
(for adding to brackets in latex). This was then called by the pre-defined mappings ...
What a quagmire
Lesson taken: always comment-out entire or parts of the settings files, and then see if things start working.
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.