I am a vi/vim person at heart but I use LaTeX a lot and I really like AUCTeX Preview so I have been using emacs with viper until recently, but I am now trying evil instead. I am however certainly no emacs expert.
Visual line mode in emacs is terrific with AUCTeX Preview because when the Preview images are activated, the line lengths are all mucked up, but if each paragraph is really only one long line, in visual line mode it all looks great whether the Preview images are activated or not.
One thing that has always annoyed me is that viper commands like 'j' and 'dd' only work on "logical lines", not screen lines. In vim one would instead use 'gj' instead of 'j', and indeed this is how evil works. However there is no equivalent for 'dd'.
I came across the answer to a SO question addressing this for vim and it seems to do the trick :nnoremap dd g0dg$. Indeed typing the "right-hand side" in evil (even with a numerical prefix) works exactly as it should.
However I cannot easily see in the evil documentation how one might achieve this remapping. I have seen a detailed answer to a general SO question about evil but all its suggestions and examples show how to map a key sequence to a single already-defined evil function. I can't see any examples where an existing evil key sequence is remapped to another (possibly longer) existing evil key sequence.
I guess I could replace the "right-hand side" of the mapping with a sequence of existing evil functions, but I'm not sure how one might do that. Or I could just use a basic emacs key remapping but I fear that this will interfere with evil's different modes/states, or simply just won't work.
Does anyone have any ideas?
Here's a basic function that does what I think you want (note that it doesn't do the other nice things like counts that Vim/Evil provide; use evil-define-command for that). You'll clobber some keybindings if you try to map it to gdd, so as a workaround, you could map it to gD (or whatever you like):
(defun evil-delete-visual-line ()
(interactive)
(let ((beg (progn (beginning-of-visual-line) (point)))
(end (progn (end-of-visual-line) (point))))
(evil-delete beg end)))
(define-key evil-normal-state-map "gD" 'evil-delete-visual-line)
Related
After attempting to use vim a number of times, I'm always been put off by its default key bindings. After some research, I decided to remap the default keys to more sane ones (at least for my tastes). I have a few questions about changing bindings that I could not find answers to through Google.
Is there a way to map a key to an action rather than another key. For example:
:noremap a h
will bind the a key to move the cursor left. Is there something along the lines of
:noremap a move-cursor-left
or
:noremap a :move-cursor-left<Enter>
so I can read my config file afterwards?
Is there a way to unbind all of the default key bindings? I've tried :mapclear but it doesn't seem to work, although it might just be clearing non-default bindings. Unmapping every key manually is not an option. If possible, I would like to export the defaults to a file so I can edit them as I need.
Is there another language I can use to write my own commands for vim other than vim-script? I haven't actually looked into this one so much though. If I can bind an external executable to a command, that would be good enough.
I haven't given up on vim although I would like to ask if there are any vim-like alternatives out there. My Google searches came up with nothing actively developed. If the above cannot be done, or reasonably hacked together, I would like to find a fully configurable, modal, command line text editor that can.
The command set of vi / Vim has 40 years of wisdom encoded into it; completely changing it is a bad idea. I can only repeat the reference to this answer from the comments; that should convince you (to accept this, or choose another editor).
Give the default commands another try. It'll take some time to get used to, but most Vim users swear by these. It's fine to make minor adjustments "for personal style": careful evolution, but not revolution. Also, some people with odd keyboard layouts (like Dvorak or Colemak) swap several keys for convenience.
The move-cursor-left is just h; aided by the excellent :help, you should be able to "read" your remappings just fine.
In general, even though it's possible to write extensions / plugins in integrated languages like Perl, Python, Ruby, etc. (based on support for them compiled into the Vim binary), you won't get around learning some key Vim internals and parts of Vimscript. If you don't feel comfortable at all about this, I'd suggest to use another editor. Unfortunately, with your requirements of full extensibility (and probably broad acceptance and platform support), there's only one serious alternative: Emacs (which cannot only be turned into everything but a kitchen sink, but also into a modal editor, too).
(i know this question is old)
you can reset the binds by just over-writing them
on vim you can use many <things> (idk the name)
e.g.
<Up> = Up-arrow-key
<C-f> = Ctrl, f
<A-Down> = Alt, Down-arrow-key
<Esc> = Escape-key
it's possible to remap the hjkl keys to wasd like this:
nmap w <Up>
nmap a <Left>
nmap s <Down>
nmap d <Right>
After attempting to use vim a number of times, I'm always been put off by its default key bindings. After some research, I decided to remap the default keys to more sane ones (at least for my tastes). I have a few questions about changing bindings that I could not find answers to through Google.
Is there a way to map a key to an action rather than another key. For example:
:noremap a h
will bind the a key to move the cursor left. Is there something along the lines of
:noremap a move-cursor-left
or
:noremap a :move-cursor-left<Enter>
so I can read my config file afterwards?
Is there a way to unbind all of the default key bindings? I've tried :mapclear but it doesn't seem to work, although it might just be clearing non-default bindings. Unmapping every key manually is not an option. If possible, I would like to export the defaults to a file so I can edit them as I need.
Is there another language I can use to write my own commands for vim other than vim-script? I haven't actually looked into this one so much though. If I can bind an external executable to a command, that would be good enough.
I haven't given up on vim although I would like to ask if there are any vim-like alternatives out there. My Google searches came up with nothing actively developed. If the above cannot be done, or reasonably hacked together, I would like to find a fully configurable, modal, command line text editor that can.
The command set of vi / Vim has 40 years of wisdom encoded into it; completely changing it is a bad idea. I can only repeat the reference to this answer from the comments; that should convince you (to accept this, or choose another editor).
Give the default commands another try. It'll take some time to get used to, but most Vim users swear by these. It's fine to make minor adjustments "for personal style": careful evolution, but not revolution. Also, some people with odd keyboard layouts (like Dvorak or Colemak) swap several keys for convenience.
The move-cursor-left is just h; aided by the excellent :help, you should be able to "read" your remappings just fine.
In general, even though it's possible to write extensions / plugins in integrated languages like Perl, Python, Ruby, etc. (based on support for them compiled into the Vim binary), you won't get around learning some key Vim internals and parts of Vimscript. If you don't feel comfortable at all about this, I'd suggest to use another editor. Unfortunately, with your requirements of full extensibility (and probably broad acceptance and platform support), there's only one serious alternative: Emacs (which cannot only be turned into everything but a kitchen sink, but also into a modal editor, too).
(i know this question is old)
you can reset the binds by just over-writing them
on vim you can use many <things> (idk the name)
e.g.
<Up> = Up-arrow-key
<C-f> = Ctrl, f
<A-Down> = Alt, Down-arrow-key
<Esc> = Escape-key
it's possible to remap the hjkl keys to wasd like this:
nmap w <Up>
nmap a <Left>
nmap s <Down>
nmap d <Right>
While vim's way of doing things is generally good, I feel like there are aspects that really get in the way as somebody who is not completely committed to vim for text-editing.
This means that I am hitting Esc+/ and typing slashes into files in Sublime Text, and hitting Ctrl+F in vim, scrolling down a page.
Similar things happen with Ctrl+S and :w and custom mapping ; to : still doesn't make it as convenient and fail-safe as Ctrl+S. Not to mention in PuTTY, Ctrl+S does something rather upsetting (it suspends output from the terminal till Ctrl+Q is pressed). Basically, IMHO some things (like switching to a "find mode" and saving the file) are good to attach to a global left-hand home-row shortcut chord rather than requiring the user to mess about in a modal command line. It simply is too often used to subject the user to these mode changes. I suppose this isnt a legitimate complaint because the entirety of vim is constructed around the modal concept, and these functionalities are a result of that.
In any case I'd like to make it a bit easier on my brain because I've tried for a while now to keep it all intact and it's simply too much (I have more or less internalized the switching between Ctrl on a windows machine on a desktop keyboard and the use of the thumb for the Cmd on my Macbook, but this modal text editor business seems to be too much). It did not take too much deliberation for me to decide that global homerow key chords are simply more intuitive.
Mapping Ctrl+S to :w is trivial, so the question here is about the find mode. I want to bind Ctrl+F to put me in find mode, but repeating it should not type slashes into the find command. Can this be done? Is there perhaps a colon-command that when executed simply drops me into the current find-command-buffer-thing?
In your .vimrc add:
inoremap <C-f> <Esc>/
noremap <C-f> <Esc>/
In whatever mode you are in, this will put you in "find" mode (it actually just types a slash in the command line which you can use to search). With these bindings it will work for all modes, even if you are in insert mode.
do you want this?
nnoremap <c-f> /
if you like you can also try
nnoremap <c-f> q/
the 2nd mapping brings you to a search history window. you could choose previous search keywords/patterns. also available to type new pattern (by pressing i)
btw, there is no find mode
Mappings can be defined separately for the different modes in Vim, see :help map-modes. This automatically takes care of your proposed <C-f> mapping: Initially, you're in normal mode, then the search pattern is entered in command-line mode.
If you so far only occasionally use Vim, and find it too "different", several things may make the switch easier:
easy Vim (evim or vim -y) defaults to insert mode
on Windows, :behave mswin and the $VIMRUNTIME/mswin.vim script create some common Windows shortcuts
graphical GVIM has menu items like Edit > Find... and toolbars.
Some things like the flow-control freeze on <C-s> in terminals are unfortunate, mostly historical accidents; you can't blame Vim for those.
You don't need to map anything. / is expressive enough and is definitely not slower than <C-f>. Same for <C-s> which, despite a certain familiarity, is not much better than :w<CR>. You are learning a new tool, remember?
What you should focus your efforts on is getting confortable with Vim's modality. The simple fact that, for you, doing a search involves hitting <Esc> is a sign that you didn't get that part. Your other comments on using Vim shortcuts in ST and ST shortcut in Vim are not good signs either and the part where you complain about having to adjust to your Mac's Cmd is the icing on the cake, IMO.
It may sound brutal but, from your question, it seems like you are doing too much at the same time, without organization and for, probably, no good reasons.
Switching from Windows to Mac OS X and switching from ST2 to Vim at the same time is sure to be confusing and I suggest you slow down a little and make a choice before you loose your mind and waste more of your time.
Which leads me to this: Why do you use a Mac and why are you using Vim?
Windows is a fine OS. Sublime is a fine editor. Even if you switch to the Mac, Sublime works very well there. So Why Vim?
If you are tired by some Sublime limitations and want the awesome power of Vim, fine. But you must wrap your head around its modality and awkwardness and accept to change your habit.
If you don't approach Vim with more flexibility, you'll never get full benefits.
If you decided to use Vim because it is trendy, I'll respectfully suggest you to stop there and go back to Sublime. Vim is weird, Vim is different, Vim is huge, Vim is a rabbit hole… if you are not ready to work with it and insist on not accepting its core design, you won't get far so why bother? You can pretty much live all your professional carreer without ever touching Vim. There's no shame in that.
Remapping / to <C-f>, on the other hand…
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.
I'm a long-time vim user trying to make the switch to emacs.
I'm using viper-mode in emacs and I keep typing ESC (to get out of insert mode) and then a key (say, j). I type fast and often hit them at the same time. Emacs then thinks I'm hitting META-j and runs a function which I do not intend.
I like using option as meta and don't care to have ESC ever be meta when I'm in viper.
Anyone have suggestions on how to completely disable ESC as meta in viper mode?
Here's a few related options that I've tried. None of these solve the issue.
(setq viper-no-multiple-ESC t)
(setq viper-translate-all-ESC-keysequences t)
(setq viper-fast-keyseq-timeout 0)
I was in the same boat, and this problem has been preventing me from trying emacs for quite a while. But I finally had some time to investigate, and think I've got a solution/workaround.
After looking at viper's source, I realised that contary to all the documentation I find, viper-translate-all-ESC-keysequences is a function. So setting a variable with the same name won't do anything.
So now I have (defun viper-translate-all-ESC-keysequences () nil) after my (require 'vimpulse) line in my .emacs file. And it seems I can spam my ESC key as much as I want now. Why the documentation was so misleading I don't know, but for now I at least get to try emacs with this workaround. Hope this helps!
The above answers didn't work for me. I looked up the viper documentation and found the two commands (viper-fast-keyseq-timeout) vs. (viper-ESC-keyseq-timeout). The former is to let Vi mode interpret any key combinations separated by the defined time to be Vi macro. The latter seems to be what we want, which is to ignore the special meaning of ESC in vi mode. Setting the latter to 0 solves the problem for me. (iterm2, mac os X lion)
[ref]
viper-ESC-keyseq-timeout 200 on tty, 0 on windowing display
Escape key sequences separated by this much delay (in milliseconds) are interpreted as command, ignoring the special meaning of ESC in VI. The default is suitable for most terminals. However, if your terminal is extremely slow, you might want to increase this slightly. You will know if your terminal is slow if the ESC key sequences emitted by the arrow keys are interpreted as separately typed characters (and thus the arrow keys won't work). Making this value too large will slow you down, so exercise restraint.
viper-fast-keyseq-timeout 200
Key sequences separated by this many milliseconds are treated as Vi-style keyboard macros. If the key sequence is defined as such a macro, it will be executed. Otherwise, it is processed as an ordinary sequence of typed keys.
Setting this variable too high may slow down your typing. Setting it too low may make it hard to type macros quickly enough.
viper-translate-all-ESC-keysequences t on tty, nil on windowing display
Normally, Viper lets Emacs translate only those ESC key sequences that are defined in the low-level key-translation-map or function-key-map, such as those emitted by the arrow and function keys. Other sequences, e.g., \e/, are treated as ESC command followed by a /. This is good for people who type fast and tend to hit other characters right after they hit ESC. Other people like Emacs to translate ESC sequences all the time. The default is to translate all sequences only when using a dumb terminal. This permits you to use ESC as a meta key in insert mode. For instance, hitting ESC x fast would have the effect of typing M-x. If your dumb terminal is not so dumb and understands the meta key, then you probably will be better off setting this variable to nil. Try and see which way suits you best.
This problem happened to me in console mode (i.e. when running emacs -nw).
Adding the following to my init.el seems to be the solution for me:
(set 'viper-fast-keyseq-timeout 0)
(set 'viper-no-multiple-ESC t)
(defun viper-translate-all-ESC-keysequences () t)
I also needed to add:
maptimeout 0
to my .screenrc file for running emacs inside of a GNU Screen session, or the problem would re-appear.
Also:
(defun viper-translate-all-ESC-keysequences () nil)
seemed to "work", but had the unintended effect of disabling M- style commands, so (for example) I couldn't use M-/ to run dabbrev-expand when in insert mode.
The (defun viper-translate-all-ESC-keysequences () nil) solution didn't work for me with terminal emacs running in iTerm2 -> ssh to Slackware 11 -> screen -> emacs 22.3.1
All I had to do was:
(custom-set-variables
'(viper-translate-all-ESC-keysequences t))
Note that the setting is "t", not "nil".
However, the solution for my OSX iTerm2 -> emacs 23.2.1, this was the fix:
(setq viper-fast-keyseq-timeout 0)