I installed SpaceVim to test it out and ; (semicolon) is not working. :nmap ; says "No mapping found". The thing is I could not find where it is unmapped in the source. Are there different ways to re/un-map a key in vim and how should I go about finding those in general?
There seems to be some confusion here about the difference between the « standard » vim functionality and the effects of a mapping.
Note: One of the reasons I prefer a customized regular vim is that it forced me to learn real vim and its philosophy, then to build tools on top of that. This may be the purist in me, but distros like SpaceVim make it remarkably hard to see what’s going on under the hood when you need them to do something different, whereas vim is ready-made for that. I write this because I suspect those who start with SpaceVim do not read :help and therefore lack a complete grasp of the fundamentals.
Standard vim keys are not mappings. n to jump to next search match, J to join, q to record a macro, ; to repeat the last fFtT—all are implemented in the source. Changing their default behavior would require an edit and recompile. This is why :normal! ; works no matter what—it ignores mappings and uses the source definition.
So, to answer your question, :map ; says there is no mapping because there is no mapping.
Note: I assume SpaceVim does not map ; because I could not find documentation that it did.
Of course, one can always create mappings shadowing this behavior, but it’s considered an anti-pattern to do so (esp. without at least having another sequence to do the old behavior). The reasoning goes that the original is actually considered useful, so why override it?
Note: from my glance at SpaceVim’s keybindings, SV does this a lot. They remapped q, which created macros, requiring me to type 2 extra characters to access one of my favorite—and one of the most awesome—features!
Related
I recently did a new install of VIM 8.2.2825 on Windows. The behavior of <operator>%, such as d% or c% appears to have changed, compared to how I have used those commands for many years. These operations are now "exclusive", meaning they do not include the final paren or brace in the text that you want to delete or change.
The documentation still claims that the <op>% operation is inclusive. (see the beginning of section 9 (various motions) in :help motion.txt). But that's not happening. If the cursor is on the left paren and I type d%, it now deletes everything before the right paren, but not the right paren. It should include deleting the right paren.
I searched quite a while looking for anything related to the inclusivity / exclusivity of the d% operation, with no luck. Apologies if I missed something.
I'm wondering if this really is a change in VIM behavior (in which case the documentation seems to be wrong), or if perhaps there is some .vimrc setting that I now need, that wasn't needed before.
TIA.
You're probably using :h matchit standard plugin that re-maps %. In fact, it does not necessarily make the motion exclusive, it just uses Visual mode that depends on your :h 'selection' setting.
Just don't load it if you don't like it.
I installed Latex-Suite for Vim, and I like it very much, but I'd like to be able to customize the environment mappings that came by default, and add new ones. For example I want to edit the equation environment that appears typing EEQ and move around some elements, like the \label{} command. How can I do this? I've been scanning everything inside my /usr/share/vim/vimfiles/ftplugin but I can't find a way to do it (or I just don't understand what those files are).
You want to check out the documentation on Macro Customisation, specifically the Tex_Env_{name} bit.
In short, if you want your theorem snippet to look like
\begin{theorem}
<++>
\end{theorem}<++>
then you want a line like
let g:Tex_Env_theorem = "\\begin{theorem}\<CR><++>\<CR>\\end{theorem}"
in your vimrc.
Note the backslashes to escape carriage-return, and double-backslash for normal backslashes.
The <F5> functionality (press F5 after typing an environment name, i.e. figure<F5>) should work out of the box, but you may need to refresh the three-letter code. This is more hassle than it needs to be, but something like
autocmd BufNewFile,BufRead *.tex call IMAP('EFI', g:Tex_Env_figure,'tex')
will do the job.
The answer to the question you asked comes with a caveat, which is that Latex-Suite is an enormous amount of code that is very hard and annoying to modify, and which does not play nicely with other plugins. This falls into Latex-Suite's philosophy that it's the only plugin you need for editing latex within vim.
That said, you want to look in /path/to/ftplugin/latex-suite/envmacros.vim. Searching for EEQ will lead you on the path to understanding the set of calls that latex-suite performs. I would like to reiterate that many functions are deeply intertwined.
On the other hand, there is a very easy way to have very easily customizable environments, which are snippets. See the UltiSnips page for a good example of how this works. These are designed for customization and extremely easy to write.
I do my coding in Vim and recently have been getting more annoyed by its pair completion features. I don't really see the need for pair completion in general as I tend to naturally try to close pairs myself (by pair here I mean type the closing ')' of a set of parentheses, for example). What really annoys me is when I have text already written and to surround it by quotes for example I'll be at the beginning of the word, type ' and then two will pop up right over there rather than just 1 and then me pivoting to the end of the word and typing the other exclamation point. Anyways, that's it for my rant, so any help on stopping my vim from doing this would be appreciated. I use spfvim-13 (https://github.com/spf13/spf13-vim) and have only modified the .vimrc slightly. I wasn't able to pinpoint exactly from where this specific issue arises.
This is not a native vim behavior, it's definitely some plugin causing it. I can't pin-point a particular plugin that spf13 might be having for this, I looked for popular ones I know, like simple_pairs, delimitMate etc.
Best way to investigate what's causing is to just see the output of :verbose imap ' and you'll come to know where it's being set and then remove that plugin / setting.
Many plugins make their public mapping interface accessible through <Plug> maps. Users can then use these maps as hooks for their own mappings, e.g. :nmap <Leader>fu <Plug>fooPluginUnlinkRootDir.
Recently I have come across some plugins which put their map names in brackets, e.g.
<Plug>(textobj-indent-a) in the textobj-indent plugin,
<Plug>(LineJugglerBlankUp) in the LineJuggler plugin.
This syntax is not documented anywhere in the help files nor do any of the bundled Vim runtime files use it. Nevertheless, these plugins do their job just fine.
What is the motivation for the brackets? Is there any advantage in using them? Should plugin authors be encouraged to follow this practice (as a best practice)?
Thanks ZyX; your answer already covers the fundamentals, so let me just add why I've adopted the <Plug>(PluginNameAndMore) notation. (I think I saw it first in Kana Natsuno's plugins.)
Two reasons:
When wrapping a mapping with other stuff, it's easier to visually parse the individual mapping targets, like here:
imap <C-x><C-c> <Plug>(CompleteStart)<Plug>(CamelCaseComplete)<SID>(CamelCaseCompleteModifyUndo)<Plug>(CamelCasePostComplete)<Plug>(CompleteoptLongestSelect)
When defining multiple mappings for a plugin, one must be careful that the LHS of one is not contained in another mapping. Otherwise, there will be a delay when the mapping is triggered, as Vim needs to wait for additional keystrokes before the ambiguity can be resolved. The closing parenthesis prevents any such ambiguity.
BAD GOOD
<Plug>MyFunc <Plug>MyFuncNext, <Plug>(MyFunc)
<Plug>MyFuncReverse <Plug>MyFuncPrev, <Plug>(MyFuncReverse)
Both of {lhs} and {rhs} in the mappings command are byte sequences which can contain arbitrary data (except for NUL byte) as long as it has natural number of bytes (for {rhs} having zero number of bytes is also allowed). From this point of view (…) practice has no advantages over another one.
Specifically for (textobj-…) there is one minor advantage: you can select the whole {lhs} without <Plug> part with a) motion and have more readable dashes between words. I have no idea though why would one want to do so as the whole {lhs} can be selected with aW (with <Plug> part).
I do not see any reason for the LineJuggler version.
You should better ask authors about this. #IngoKarkat is here, on stackoverflow and will probably read the question soon. I have no idea how to contact Kana Natsuno.
Parens make it clearer (to humans) when there are other keystrokes in a mapping following the <Plug> invocation. For instance I have this mapping:
nmap ]c <Plug>GitGutterNextHunkzv
That makes ]c jump to the next Git hunk and then do zv to open any folds there. But since <Plug> names are arbitrary, the command could have been called GitGutterNextHunkzv. In general there's no way for somebody reading a file using a <Plug> mapping to know if the whole thing is a name or there are other characters following.
If the GitGutter plug-in had used brackets for in the <Plug> name, it would be far clearer to see what's going on:
nmap ]c <Plug>(GitGutterNextHunk)zv
I've been using Vim exclusively for a few weeks now, and a few things are keeping me from being very excited about my experience so far. For one, I am having trouble mapping a few key sequences to commands.
I'd like to map Ctrl+Shift+Z to :redo<CR> or alternately <C-R>, but apparently Vim is not able to recognize the difference between shifted and un-shifted control-key sequences:
Ctrl-b and Ctrl-B are synonymous, they both mean 0x02. This cannot be
changed, it goes back to ASCII, which dates back to 7-hole paper tape
(not counting parity).
This just seems silly to me. We've come a long way since 7-hole paper tape, and in my experience MANY programs recognize the difference between <C-S-Z> and <C-Z>. Indeed, MacVim even recognizes the difference! But no joy in GVim or in the GNOME Terminal. Is there a way around this? Maybe a plugin or even some compile-time option?
The other key combo that I'm having trouble with is Ctrl+, (control+comma). I'm not sure if I've got something configured wrong in my .vimrc, or if it's a real issue with Vim, but I cannot get <C-,> to respond after mapping it (for example: map <C-,> :TComment<CR>). FWIW, I have my leader key remapped to ;. Am I doing it wrong? Or is there some other reason why Vim won't recognize the <C-,> key combo?
I've spent way too much time googling and fiddling with key mappings, and I'm on the verge of declaring that Vim is not as flexible as I've been led to believe... I can't even get it configured with the key mappings I'm used to, some of which I am reluctant to re/unlearn since they work in other programs that I use daily.
It looks like the link you posted already answers your question regarding <C-b> vs. <C-B>. According to the FAQ it looks like you're out of luck with <C-,> as well, since this key combination is not in the list of Ctrl-printable-key chords that Vim can detect (possibly because it's not even a printable ASCII chord?).
Key combinations such as <C-S-w> are very un-Vim-like in that they undermine the efficiency of a modal editor. Of course there are times when <CTRL>-escaped combinations are necessary (for example in insert-mode mappings such as <C-x>-<C-o> for omnicompletion), but that's not the case for operations such as undo and redo.
I'm sorry that this reply won't satisfy you, but in the long run there is much to be gained from "doing it the Vim way", rather than trying to bend Vim to your will.
Try adding set nocompatable to your vimrc. without this you are basically running vi wich is much more limited than vim. This should allow you to map <C-S-r> or <F11> or whatever else you want.
Tjameson is completely right. it is much better to use the default mappings where they exist.