On Sunday, December 22, 2013 3:52:35 AM UTC-6, 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. >
That's the dumbest idea I've heard about Vim development, and yet I keep hearing it. No. That's like saying, "I think Windows should only support C# from now on. Nobody wants to use anything else." That's just stupid. Maybe YOU don't want to use anything else. Personally I don't know python, I don't want to learn python, I will probably never write a Vim python plugin or script. I know Perl. I know vimscript. There are plenty of Ruby or TCL or other language scripts and libraries written which could be leveraged as well. Why drop them? So you can be lazy when you compile? If you know there's a plugin you want that needs one, then install it and compile and be done with it. If you don't have it and find a nice plugin, you just need to ask yourself whether it's worth the trouble to install, or just always install a fully-enabled Vim. As for dropping Vimscript, you DO realize that vimscript is used interactively as well, right? You might as well say, "nobody likes writing scripts is csh dialect, we should drop support for everything but running bash scripts in csh". You're only showing your ignorance when asking to drop support for vimscript. > 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. > Sure, a better plugin manager would be great. I personally use Pathogen which is very bare-bones, but still way better than built-in support. I wouldn't mind seeing one of the plugin managers distributed with Vim. But this doesn't require a rewrite of Vim. Just a good plugin manager. As for not needing to configure a plugin, are you just saying "I don't like the default settings for this plugin", or are you talking about something else? Vim and the plugins you install give you a default range of settings that the developers liked. If you don't like them, you can change them. That's kind of the point of user settings... By the way, I think Vim-Addon-Manager provides some of the features you're looking for. Maybe take a look at that one. > 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. What does this mean? Are you talking about popup dialogs on mouse hover? Or something else? -- -- 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.
