On Tue, Dec 3, 2013 at 12:40 AM, Tim Chase <[email protected]> wrote: > It seems odd to build a lot of these things into vim when excellent > solutions exist with more generic applications. You (Thiago) mention > already using tmux+vim, and I find that solves most of the issues you > list, and thus I'd find adding those to vim to be superfluous. > > On 2013-12-02 23:13, Thiago Padilha wrote: >> - Multiple clients connected to the same vim instance would provide >> an easy way to have collaborative editing(like pair programming). > > GNU screen and tmux both provide this functionality > > http://www.howtoforge.com/sharing-terminal-sessions-with-tmux-and-screen > > That way, I can not only screen-share my Vim session, but my terminal > commands for building/testing, as well as other shell stuff like > network, process & configuration management. > >> - Vim running in a remote server with local GUI, without the >> security implications of X forwarding > > Though I don't usually need a GUI (the terminal version does just > about everything I need), I find that using ssh's X-forwarding > securely does everything I need without having to open things up > broadly/dangerously via xhost. > >> - Use vim as a terminal multiplexer for detaching from a remote >> server without closing the running programs. > > As above, I recommend just using screen/tmux. Why duplicate the > behavior in Vim, without the ability to multiplex all apps like > screen/tmux already does? > >> - This is actually a very particular use case of mine, but it >> should illustrate another scenario were it would be useful: I do >> all my development work inside a headless linux VM running in >> virtual box in a windows laptop. Having a client/server >> architecture would let me detach a windows-native client, save the >> VM state and restore everything later even across reboots. This is >> already how I work, except that I use a combination of TMUX, >> vcxsrv(windows port of xorg), urxvt and terminal vim. This would >> let me replace all those programs by vim. > > Most of that seem to involve getting a GUI. With terminal vim, > that's just tmux and vim. > > Maybe it's my grumpy-old-man stance, but I don't see them as issues > since they already have robust solutions that do far more than Vim > would encompass. > > -tim > > > -- > -- > You received this message from the "vim_use" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_use" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out.
Tim, While tmux+vim combo serves me very well for now, sometimes I see myself using very hacky solutions for things that would be easy if the two were integrated. For example, [this gist](https://gist.github.com/tarruda/5158535) shows how to integrate tmux and vim, and both with the x11 clipboard. If I could properly run terminals in vim buffers none of that would be needed. I'm not saying that vim should implement a terminal emulator or advanced features like semantic code completion, but if it provided some basic way of updating UI or executing a command after a background job completes then it would integrate much better with other plugins such as youcompleteme and conqueshell which extend its functionality in extreme ways Thiago -- -- You received this message from the "vim_use" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_use" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
