On 22/12/13 10:52, Ishfaque Jahan Rafee wrote:
I don't know if I am in the correct position to evaluate or say this, because I
am using Vim for less than a year now. I would love criticism, but please try
to avoid harsh comment as much as possible.
1. Drop support for anything except Python (including vimscript)
Reason:
Take it from me, nobody wants to start using an editor & wants to know that, due to
some compile time events, they can't use this plugin. I wanted to install Command-T
plugin & came to know that, I can't install it, because I don't have +ruby in my
vim. It sucks.
Dropping Vimscript support may be the toughest job, but think of it. Do you feel in
your heart that, there's anyone on earth, who honestly want to program in vimscript? Is
there anything, that can be done in vimscript, but can't be done in python? By loosing
vimscript, you will be losing many years of plugin development. But look at the bright
side. I feel a little bit frustrated, when I see the plugin I am going to use, was last
developed 3 years before(Though it works better than anything else I have used). Losing
vimscript, you are bringing a revolution in development. If you are thinking no plugin
will be developed, take a look at sublime text & see how fast it has caught up with
emacs & vim.
2. Improved plugin management like pip.
Reason:
I am a big fan of Vundle. It is simple & does what it supposed to do. It downloads all the files from a git repository & adds
them to the path. But think about a complicated plugin, plugins that are to be compiled before use(e.g. YouCompleteMe), or plugins like
powerline, which takes quite a bit of setup before use. These scenarios can be vastly simplified by using things like pip. Lets think
for a second, if you could just "pip install powerline" or "pip install youcompleteme" & get the desired
result, wouldn't it be awesome? In this way setting up a new system might be as easy as, "pip freeze" & "pip install
-r requirements.txt".
In this way, one can mark another plugin as dependency for his own one in a
convenient way.
3. Embedded shell support like screen.vim.
Reason:
Screen.vim is awesome. I agree to the fullest. But it uses an external program
& the support it provides is not native. Now a days Vim is becoming a de-facto
standard for interpreted language development in UNIX. In interpreted language
development, having a shell with your editor is pretty much a requirement. Please
don't let these people run to something like Sublime Text or Emacs for this.
Embedded shell support would greatly help debugging of compiled language
development too.
4. (This one is GVim specific, because I don't think its possible on Terminal
vim). I am a big fan of preview-mode for latex in emacs. But nothing like that
exists on vim.
5. Documentation support at point. Plugin's like YouCompleteMe provides
language documentation. But it opens a window at top, rather than at the place
where I am typing. The author of the plugin said its a Vim limitation. So I
would urge people to take a notice here.
You know what? Rather than Python, drop support for everything except
LISP. With just a little research, you may find out that the editor for
that has already been written. But I'm not going to tell you under what
name, it would spoil the joke.
Best regards,
Tony.
--
Two longtime friends sipped Scotch in a local bar and talked about
their troubles. "And on top of everything else," said the first, "my wife
has cut me down to just once a week."
"That's too bad," agreed his friend, "but it could be worse. I know
two guys she's cut off altogether.
--
--
You received this message from the "vim_dev" 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_dev" 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.
