For fun I decided to compile vim from source. Long story short the build seemed to go fine, but when I enter insert mode I cannot use the <BACKSPACE> key to delete existing characters or newlines created using the <ENTER> key in insert mode. The distro's pre-built package does this just fine. I also know there's no problem with the backspace key itself because I can backspace over characters I've just typed, just not existing characters.
It almost makes sense, as vim operates on a per-line basis most of the time. Is there a flag I need to set in order to support this behavior? Or is it faster by design to enter normal mode to delete existing characters/newlines?
Wow, second time I've figured out the answer minutes after posting the question.
set backspace=indent,eol,start
Must have been set automatically by the distro's package vimrc. Hope this answer helps someone else! For more info:
:help i_backspacing
Related
I installed a vim 8.1 on the cluster I am using in my home folder. I also installed a number of plugins including YouCompleteMe. I then made an alias so that I can open the vim easier.
However, I found that my vim cannot delete letters very well. When I am writing I can delete what I just typed. But if I move the cursor to other places, then it cannot delete letters at all, unless I type in something at first.
I am using a Scientific Linux system developed by the Fermi Lab.
How can I solve this problem?
Thanks
This sounds like the default configuration of the :help 'backspace' option. If this doesn't contain start, you cannot remove characters over the start of insertion by pressing Backspace, only what got inserted before. Removal of characters via the x or d commands (:help deleting) should always work - anywhere. Else, you have a serious misconfiguration should inspect your ~/.vimrc and re-add plugins one by one.
If you're new to Vim (and using backspace for deletion in insert mode is a typical approach of people used to other, modeless editors), you should spend 30 minutes on the vimtutor that comes with it (see :help vimtutor). Then, there are several good resources, cheatsheets, and vi / Vim tutorials out there on the net. http://vimcasts.org/ has several short entertaining episodes that go beyond the basics.
Your problem could be fixed by putting
set backspace=indent,eol,start
into your ~/.vimrc. Also have a look at :help defaults.vim; by including that instead, you'll get other goodies and recommended settings as well! (The reason for the odd defaults is backwards compatibility.)
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'm posting this question largely to provide the answer I've arrived at (because I found nothing elsewhere online and see no questions asking how to do this), to hopefully save future LightTable vim users a bit of time. But I'd also like to hear about any other solutions people have found to this problem, or vim LightTable problems in general.
I've fallen in love with LightTable, but at least minimal vim support is a must before I even consider an IDE. LightTable has that. Currently, though, you're largely stuck with the default vim options and little ability to alter configuration. I would be very interested in hearing about what the future plans are in this area (you out there Chris?). Exposing a .vimrc in a local config directory, even if highly limited in functionality, would be simply awesome, but I realize its very early yet in development and largely depends on what CodeMirror can provide.
One thing I can't tolerate is having to send my pinky way up and to the left to hit the ESC key to exit insert mode. That is way too slow and requires your left fingers to leave the home row, which is never good. The way I normally handle this in vim is to map ii to exit insert mode in .vimrc. Another alternative that is there by default is to hit CTRL-[. That's better, but to me that's entering emacs chording territory and for some reason my right pinky finger almost always flubs hitting either of the bracket keys.
This is a bit of hack, but it's a tolerable work-around until better vim support comes along in LightTable/CodeMirror. I've only tested it on the latest LightTable (0.4.9), so I'm not sure how applicable it is to earlier versions (which you probably shouldn't be on anyways), or, for that matter, later versions that will come along.
There is a command option called "Vim: toggle vim mode". This turns vim on and off in an editor (or instarepl). You can bind this command to a hot-key combination via the "Settings: Change key bindings/shortcuts" command. This will open up a new tab where you can enter new key bindings on the left. The current key bindings are shown on the right.
I use SHIFT-i, within a context of :editor.keys.normal. (This means I can't use capital "I" directly in the text, but in actual practice with program editing - especially clojure - this almost never causes a problem, and if it does you can just use lower-case i and then back up and do a replace char.) This effectively makes "II" (SHIFT-i SHIFT-i) the means of exiting insert mode. The first SHIFT-i exits vim and puts you in the normal, WYSIWYG editor. The next SHIFT-i puts you back in vim, but in command mode. Voila! You've went from vim insert mode to vim command mode.
Hope this helps other LightTable vim users.
Update: I think the latest LightTable release supports this. Someone please comment if adding the following to their user.behaviors file works (user behaviors is accessible via the command pane (ctrl-space)):
[:editor :lt.plugins.vim/set-options {"enableInsertModeEscKeys" true,
"insertModeEscKeys" "jk",
"insertModeEscKeysTimeout" 200}]
Old answer:
The latest LT plugin source supports this, but has not been released yet.
To easily install it do the following:
Open your LT plugins folder, e.g. on OSX ~/Library/Application Support/LightTable/plugins/Vim/
(Optional) Save a backup of the Vim (plugin) folder somewhere else
Delete the Vim folder
Download https://github.com/LightTable/Vim/archive/master.zip
Unzip it, rename the unzipped folder to just Vim, and move/copy it to your LT Plugins folder (i.e. it is replacing the official Vim plugin that you just deleted)
Add the following options in the :editor section of your user.behaviors file:
(:lt.plugins.vim/set-options {"enableInsertModeEscKeys" true,
"insertModeEscKeys" "jk"
"insertModeEscKeysTimeout" 200})
Restart LT and you should be able to use jk (or whatever keys you set in insertModeEscKeys) to exit insert mode
CodeMirror's API is designed in such a way that it's not very complicated to add key bindings but adding support for a configuration file and extending the default key bindings to cover a larger part of Vim's feature set doesn't exactly sound like a trivial task to me. And, considering the fact that LT doesn't even have search/replace, probably something that is near the bottom of their TODO list.
That, and CodeMirror is a third party "library" on which the LT team probably doesn't have much leverage.
I installed NerdCommenter like how it should be installed. And I read the help files. So, for commenting a line I need to do <leader>c$.
I also read that the leader key is \ by default. But it didn't work for me. I never used the leader key so I think I am doing something wrong.
Can anybody help me for using the basic commenting and uncommenting selected lines using nerdcommenter?
Problem
On many non-English keyboards, the backslash \ is only accessible through a AltGr key combination. This makes the default setting of the <Leader> character rather impractical for these users. Moreover, <Leader> key combinations are subject to a default 1000ms time-out. This can be observed by the disappearance of the <Leader> key at the right edge of the command line.
So, non-English keyboard users need to be real quick typists for \cc to work. Failure to do so, results in an undesired cc line change.
Here is an example of a German keyboard layout with the backslash-bearing key on the top row, third from right:
Solution
Non-English keyboard users are advised to change the <Leader> key from the \ character to the more accessible , key. Vim beginners should also consider a slightly longer 1500ms time-out. Here is what needs to be added to ~/.vimrc
let mapleader=","
set timeout timeoutlen=1500
One final caveat; these changes only take effect after completely exiting Vim. Resourcing with :source $MYVIMRC will not work!
Now, one can use ,cc for commenting with NERD Commenter.
I had the same problem, and I was noticing that it wouldn't flat out deny the command, but would say "No Error" and just not do anything. I read the install instructions for NERDCommenter very carefully and noticed this bit:
After the 'Classic' or 'Pathogen' install, make sure that you have
filetype plugins enabled, as the script makes use of |'commentstring'|
where possible (which is usually set in a filetype plugin). See
|filetype-plugin-on| for details, but basically, stick this in your
vimrc:
filetype plugin on
Even though I'd used NeoBundle rather than Pathogen, I tried that, and after a restart, voila. Hope it helps.
I am using a bépo keymap (http://bepo.fr) and seeking the perfect vim mapping.
So far I used a long list of noremap, but for many binding (for exemple, the motion aw or Ctrl+r), the first keystroke is well remaped but not the others, I reckon it's the expected behaviour, but then this is not what I need.
Ideally I would have my keyboard totally remaped in a higher level (before the map commands) except when typing text (in insertion mode and when typing a substitution for exemple). What I'm looking for seems to be langmap, but I have problems using it.
I added this langmap to my .vimrc, It seems perfect but it broke some of my plugins. SuperTab now insert <Plug>SuperTabForward when pressing Tab in insertion mode, I have t<SNR>24_SelectCompletion(1) when pressing enter.
Does someone know how to fix this langmap issue or a better way to remap my keyboard?
This is a known bug, that has been discussed before. I have made a patch (see the thread starting here) and hopefully Bram will include this change soon.
Update 11/05/2014
This has been fixed by patch 7.4.502. Use the langnoremap option to fix this.