My experience using tramp with eshell is that it is painfully slow. However, most of what I would accomplish doing that can be accomplished using tramp with dired instead.
bcvi will also let you use your editor of choice - it just happens to use gvim "out of the box".
If you're already logged into the box with SSH then being able to type 'vi file' on the server and have the editor window pop up on your workstation actually turns out to be really handy. IMHO it's easier to set up than sshfs too.
I never run gvim, are there any real advantages that I am missing?
On the server I just install vim and scp -r .vim* to the server on the desktop I spend most of the time using emacs and only vim when I don't have emacs open and need to do a quick edit.
Tramp mode as stated is painfully slow and emacs doesn't really work for me in terminals as well as vim.
I never run gvim, are there any real advantages that I am missing?
Probably only if you have a mouse connected to your computer. It is much easier for cutting/pasting between documents in different windows in a gui. I understand there are plugins for vi that work (I use vi most of the time), but it's easier for me to just use vim. Seems like to a first-order approximation gvim = vi + gui plugin
The X11 clipboard support in vim works in the terminal, but it only works when X11 support is built in. You just have to use the keyboard shortcuts ("+y = copy / "+gP = paste).
vim has to be built with X11 (gvim) support though b/c vim and gvim are really the same binary, IIRC (gvim = vim -g).
when you compile vim this way, do you get the menus also, or is that only gvim? About the only thing I do by menu is change the color scheme, because I never remember the commands (nor the scheme names, for that matter). Different schemes can be useful for different lighting conditions and different monitors.
The menus are only drawn in gvim. It doesn't draw them in the terminal like Emacs. The colorscheme command is ":colorscheme <scheme>" or ":colors <scheme>". It tab-completes to the scheme names that it has accessible to it, so you don't really need the menu. This is useful even in the terminal due to 256-color support (":set t_Co=256" if it doesn't auto-detect this for you). There are also a couple of plugins that will auto-convert gvim-only (aka fullcolor) colorschemes into 256-color schemes when you are in a 256-color terminal.
"I never run gvim, are there any real advantages that I am missing?"
If you're an Emacs user, probably no particular advantage. I use GVim because as a GUI app it allows me to use my mouse for stuff like selecting areas and copy/pasting. I also like the workflow of having my file open for editing in a separate window and getting my shell prompt back straight away.
There are some terminals which support tabbed windows, and copy and paste. If you have access to those terminals, the reasons you gave for using gVim don't apply. Though I'm not really sure that being able to use the mouse for copy and paste in vim is an advantage. I thought that one of the big productivity boosts when using vim was being able to ditch the mouse. Aren't you suppose to use v[movement]"+y to get something to your clipboard?
If you do want to use the mouse for selection for copy/paste, then selecting across the terminal text doesn't really work. Things like line numbers, folds, line-wrap characters and ':set list' characters end up in the selection when you don't let vim intelligently filter these things out for you.
If you are running vim in a terminal, then try ":set mouse=a" and it will use the XTerm mouse extensions. Most terminals support this (gnome-terminal, xfce4-terminal, rxvt-unicode, xterm). I don't know about the level of support in Putty, Terminal.app or iTerm.app though.
Works pretty well in PuTTY, but you lose your local mouse support since clicks/drags are now passed straight to the server rather than selecting/copying/pasting text from PuTTY to the Windows clipboard. It's a tradeoff between easier text manipulation in vim, vs easier text transfer between the PuTTY window and other local windows (and vice versa).
However, PuTTY only switches on XTerm mouse reporting when an app needs it, so it should be easy enough to bind ":set mouse=a"/":set mouse-=a" to a hot key, and toggle mouse support on and off depending on the required operation.
... "and emacs doesn't really work for me in terminals as well as vim."
What kind of problems are you facing running emacs in terminal? I always run emacs in terminal (wrapped inside a screen session) and I have found no problem so far.
I run emacs-trunk/rxvt with 256 colors/bash. But have also used gnome-terminal.
This is really cool. However, one of the advantages of using vi is that you use it on any machine without really needing your configuration files, the defaults are comfortable enough.
If you use GVim on your mac then it should work fine.
If you use a different editor then it should be pretty easy to hack up a plugin that launches your preferred editor instead. The plugin API docs give an example of launching GNOME gedit: http://search.cpan.org/perldoc?App::BCVI::Plugins
GNU Emacs users have tramp-mode for this. http://www.emacswiki.org/emacs/TrampMode
And it works with EShell:
Pretty cool!
My experience using tramp with eshell is that it is painfully slow. However, most of what I would accomplish doing that can be accomplished using tramp with dired instead.
s/with eshell// and I agree. I prefer sshfs, but sometimes you are on Windows and tramp is the only way.
Have you enabled SSH connection sharing? If you have a connection open already, it could leverage that (ssh does it, not tramp).
I've been doing this with sshfs (Linux/Mac) or ExpanDrive (Windows) for years, with whatever my editor of choice is for the file in question.
bcvi will also let you use your editor of choice - it just happens to use gvim "out of the box".
If you're already logged into the box with SSH then being able to type 'vi file' on the server and have the editor window pop up on your workstation actually turns out to be really handy. IMHO it's easier to set up than sshfs too.
"easier to set up than sshfs"
sshfs yourname@server /some/where
How can the setup of bcvi be easier then this oneliner?
Well 'bcvi --install server' is pretty simple and that's a one-time setup cost which survives disconnects and reboots.
But yes, of course you can do the same stuff with sshfs and if that's your preferred tool you should definitely use that.
You seem to imply that the "sshfs" command is the analogon to the "bcvi --install" command, which isn't true.
Rather, the "sshfs" command is the replacement for the "ssh" command, and "bcvi --install" is a complete extra step.
Vim has a scp handler to allow you to work locally.
Here is how you do it: vim scp://server//path/to/document
Is it just me, or is SCP very slow in vim?
I never run gvim, are there any real advantages that I am missing?
On the server I just install vim and scp -r .vim* to the server on the desktop I spend most of the time using emacs and only vim when I don't have emacs open and need to do a quick edit.
Tramp mode as stated is painfully slow and emacs doesn't really work for me in terminals as well as vim.
I never run gvim, are there any real advantages that I am missing?
Probably only if you have a mouse connected to your computer. It is much easier for cutting/pasting between documents in different windows in a gui. I understand there are plugins for vi that work (I use vi most of the time), but it's easier for me to just use vim. Seems like to a first-order approximation gvim = vi + gui plugin
The X11 clipboard support in vim works in the terminal, but it only works when X11 support is built in. You just have to use the keyboard shortcuts ("+y = copy / "+gP = paste).
vim has to be built with X11 (gvim) support though b/c vim and gvim are really the same binary, IIRC (gvim = vim -g).
when you compile vim this way, do you get the menus also, or is that only gvim? About the only thing I do by menu is change the color scheme, because I never remember the commands (nor the scheme names, for that matter). Different schemes can be useful for different lighting conditions and different monitors.
The menus are only drawn in gvim. It doesn't draw them in the terminal like Emacs. The colorscheme command is ":colorscheme <scheme>" or ":colors <scheme>". It tab-completes to the scheme names that it has accessible to it, so you don't really need the menu. This is useful even in the terminal due to 256-color support (":set t_Co=256" if it doesn't auto-detect this for you). There are also a couple of plugins that will auto-convert gvim-only (aka fullcolor) colorschemes into 256-color schemes when you are in a 256-color terminal.
"I never run gvim, are there any real advantages that I am missing?"
If you're an Emacs user, probably no particular advantage. I use GVim because as a GUI app it allows me to use my mouse for stuff like selecting areas and copy/pasting. I also like the workflow of having my file open for editing in a separate window and getting my shell prompt back straight away.
There are some terminals which support tabbed windows, and copy and paste. If you have access to those terminals, the reasons you gave for using gVim don't apply. Though I'm not really sure that being able to use the mouse for copy and paste in vim is an advantage. I thought that one of the big productivity boosts when using vim was being able to ditch the mouse. Aren't you suppose to use v[movement]"+y to get something to your clipboard?
If you do want to use the mouse for selection for copy/paste, then selecting across the terminal text doesn't really work. Things like line numbers, folds, line-wrap characters and ':set list' characters end up in the selection when you don't let vim intelligently filter these things out for you.
If you are running vim in a terminal, then try ":set mouse=a" and it will use the XTerm mouse extensions. Most terminals support this (gnome-terminal, xfce4-terminal, rxvt-unicode, xterm). I don't know about the level of support in Putty, Terminal.app or iTerm.app though.
Works pretty well in PuTTY, but you lose your local mouse support since clicks/drags are now passed straight to the server rather than selecting/copying/pasting text from PuTTY to the Windows clipboard. It's a tradeoff between easier text manipulation in vim, vs easier text transfer between the PuTTY window and other local windows (and vice versa).
However, PuTTY only switches on XTerm mouse reporting when an app needs it, so it should be easy enough to bind ":set mouse=a"/":set mouse-=a" to a hot key, and toggle mouse support on and off depending on the required operation.
... "and emacs doesn't really work for me in terminals as well as vim."
What kind of problems are you facing running emacs in terminal? I always run emacs in terminal (wrapped inside a screen session) and I have found no problem so far.
I run emacs-trunk/rxvt with 256 colors/bash. But have also used gnome-terminal.
> I run emacs-trunk/rxvt with 256 colors/bash.
I suggest trying zsh.
Maybe if the server admin is an emacs fanatic and has deleted vim. And prohibits you from building it locally. err... nevermind
(make-frame-on-display ":0")
This is really cool. However, one of the advantages of using vi is that you use it on any machine without really needing your configuration files, the defaults are comfortable enough.
:set paste
...but then you need to ":set nopaste", afterwards.
I frequently do this, instead: ":r !cat"
...but then you need to ":set nopaste", afterwards.
For me, it's just <F8>, then pasting, then pressing <F8> again. This works because of the following line in my .vimrc which I highly recommend:
Does it work on Mac?
If you use GVim on your mac then it should work fine.
If you use a different editor then it should be pretty easy to hack up a plugin that launches your preferred editor instead. The plugin API docs give an example of launching GNOME gedit: http://search.cpan.org/perldoc?App::BCVI::Plugins
Would be interesting to see a setup with textmate editing on the local workstation using this.
Symlinking gvim to mvim seems to make everything work perfectly.