On Tue, Dec 3, 2013 at 12:40 AM, Tim Chase <vim@tim.thechases.com> 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 vim_use+unsubscribe@googlegroups.com.
> 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 vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
No comments:
Post a Comment