Re: improving Vim - Kickstarter - brainstorming - goals - who wants to join?

agree
I think it'll move vim to a new milestone if more cool stuff can be integrated into vim. Throw away other sick hackings and stay just with vim . Like emacs . How about lightweight version (current) and a new(heavy ) version , toggle-able via a new 'compatible ' knob?

from iPhone


On Dec 2, 2013, at 23:10, Thiago Padilha <tpadilha84@gmail.com> wrote:

> 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.

--
--
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.