But full vi has been available from the cl with readline for a long time. Not quite as nice as athame, but very easy and serviceable.
If you are in vi mode (set -o vi, or your .inputrc is so configured), then on the command line press esc to get out of insert mode and into normal mode, then type v. A full vim editor will open in the terminal, with whatever you've typed so far.
Edit, :wq to execute the command. Delete the whole buffer and :wq if you don't want to execute anything.
This won't work anywhere but the cl I don't think, so the bit about python in athame is nice.
Interestingly, the readline command "edit-and-execute-command" does what it says on the tin (by recourse to fc) even if you're in a context where the line wouldn't usually be executed. If you try prompting for filenames with the read builtin, and turn on readline (-e) to get completions, and hit v (or, in emacs mode, C-x C-e) to open your editor, when you leave your editor it will execute whatever you typed as a line of bash. Unexpected.
Ooh, thank you! That's exactly what I've been looking for.
Basically the only time I feel the need for vi editing powers in bash is when one (or more) long complicated commands need edited and this fills that gap nicely.
Yes and no. readline's vi support is missing a bunch of random stuff. The thing that tends to irk me the most is the lack of the normal mode:
ge
This goes to the end of the previous word. There are other things, but I use this quite a bit and when it's not there, I become temporarily jarred trying to figure out if I'm mistyping.
You're talking about command line editing, on the command line. And you're right, ge doesn't work there. vi mode at the command line is a small subset of vi.
The next time you want to use ge or any other full vim feature, try this instead:
- esc, to get into normal mode.
- the single character 'v' (no quotes), to open a full vi (or vim, or $EDITOR).
- the vim session will have your command line so far.
- edit with the full power of vim or whatever opened.
- :wq to execute the command.
- or empty the buffer and then :wq to not execute anything.
To get deadline support on command-line programs that don't, one can use rlwrap. Ex: rlwrap openssl s_client -connect IMAP.google.com:993 rlwrap telnet google.com 443
I guessed that rlwrap used an LD_PRELOAD trick but a cursory glance at the source shows that it's much more complex. Can anyone explain? This might be worthy of its own HN post.
Now that vim is on github, I think it'd be cool if eventually the vim logic/model could be abstracted into a library that could then be used by any text editor to instantly provide the basic vim experience without all the edge cases that current reproductions tend to have.
It'd be cool to see native vim commands for browsing / email clients etc, not sure of the point behind adding it to a text editor. Seems like a good way to lose users to the real thing in a slow hurry.
I see this is using the +clientserver functionality of Vim. Is there any chance that this could be reimplemented using neovim's "vim as a library" functionality? Is that part of neovim ready yet?
I ask because I've had +clientserver give me hassle in the past. Sometimes it seems to just not work for no apparent reason.
Yes, seems like an excellent candidate application for that. By the way, what hassles did you experience with +clientserver? I use +clientserver by default for various reasons and it works flawlessly.
I used to have an alias for `vim --remote` so that I could easily open files from the commandline in a permanently running gvim session. Usually it would work, but sometimes it would just do nothing and not print any sort of error. I guess I was probably doing something wrong, but I didn't really dig into it that much. After a while I just decided I liked vim in the terminal more anyway.
Looks cool, but I doubt I'll use it: switching between modes when using shell isn't very comfy. Actually, every time when I see "vim-mode in <something>" (like shell, IPython Notebook) I wish for the opposite: <something> in vim. But stuff like Emacs or even Atom seems to be more flexible for that purpose, usually all these "<something> in vim" don't really work (or even couldn't be implemented due to inability to show graphics inside the vim (gvim) window). It's a shame.
I found that I just couldn't get used to `set -o vi`, despite using vim exclusively for editing. I think my muscle memory for bash was too well-developed by the time I found out about `set -o vi`.
I agree. Neovim brings promises to improve this situation drastically by separating the presentation logic from the editor core functionality, more easily allowing for embedding Vim functionality in 3rd party applications.
I find switching modes in the shell quite comfy, for whatever that's worth. I keep getting bit by little incompatibilities, though - lack of support for W, most recently.
Unfortunately nothing changed (neither in bash nor python repl) after i installed it. I followed the installation steps 1-3 on Ubuntu 14.04. Does anyone know what i'm missing?
I use cVim on Chrome for all of my work computers, and DWB[0] on my personal (Linux) computer. DWB is the best in-browser Vim experience I've had, and quite light on resources in my experience.
Vimperator for Firefox[1] and Vrome for Chrome[2] try to fulfill this ideal without changing the current browsing experience too much. You should give them a try. They are very refreshing and may be what you're looking for beyond "It's all text" 'vim-in-textareas-only' functionality.
But full vi has been available from the cl with readline for a long time. Not quite as nice as athame, but very easy and serviceable.
If you are in vi mode (set -o vi, or your .inputrc is so configured), then on the command line press esc to get out of insert mode and into normal mode, then type v. A full vim editor will open in the terminal, with whatever you've typed so far.
Edit, :wq to execute the command. Delete the whole buffer and :wq if you don't want to execute anything.
This won't work anywhere but the cl I don't think, so the bit about python in athame is nice.