Re: Re: Complete Overwrite Vim
Hi, [...] 3. Embedded shell support like screen.vim. ConqTerm or such come close. However it only works in insert mode, and you cannot use vi keys. It seems that Conque is dead at the moment, so I started a fork which tries to improve usability. So I'm curious, what exactly does bother you on Conque? https://github.com/vlmarek/ConqueVlad At the moment it's not perfect as I have some other fixes locally which I want to push soon. Cheers -- Vlad -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
- VAM supports a pool of known packages. Thus if a package is obviously replaced/outdated/unmaintained there is a way to tell the users. Thus this reduces questions about why doesn't my old sander's snipmate fail with X on irc. - VAM allows package maintainers to specify dependencies in a package description, thus installing it by name is enough, no need to declare dependencies in vimrc. Yes. I think VAM has great repository information. But neobundle has similar feature. It is recipe. You can read sample recipes in the following repository. https://github.com/Shougo/neobundle-vim-recipes The real question is: How can NeoBundle and VAM collaborate? Even if some parts are implemented differently, dosen't it make sense to collaborate on installation instructions etc ? Yes. I get the request. https://github.com/Shougo/neobundle.vim/issues/117 Your repositories are great. But I think to support current VAM-known repositories in neobundle is hard work. I must write converter. I have not much time for it. In Vim todo list, Vim needs standard plugin management. - Improve plugin handling: Automatic updates, handle dependencies? E.g. Vundle: https://github.com/gmarik/vundle I think Vim needs standard plugin repositories than standard plugin management system. Users may use different plugin management system instead of standard. But all plugin management system needs plugin repositories information. - it allows arbitrary sources, git(hub),svn, etc. neobundle has supports of git, svn, hg. Bazzaar and archives are not. You can add the features easily. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
On Dec 22, 2013, at 3:52 AM, Ishfaque Jahan Rafee mij.rafee.1...@gmail.com wrote: 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? I am late to this entire conversation, but just thought I should mention: I'm on Earth and I very much want to program in Vimscript. :) -- b Sent from my iPhone -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite 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.
If you like Vundle, you'll love NeoBundle. It works like Vundle, but with more
possibilities. A lot more. Some examples from my .vimrc.
Can used like Vundle:
NeoBundle 'bling/vim-airline'
Airline is a pure vim-script alternative to powerline and thus is lightweight
and fast. Also an example why vim-script should not be dropped.
But Neobundle can do more than Vundle, much more
Automatic compiling:
NeoBundle 'Shougo/vimproc', {
\ 'build' : {
\ 'windows' : 'make -f make_mingw32.mak',
\ 'cygwin' : 'make -f make_cygwin.mak',
\ 'mac' : 'make -f make_mac.mak',
\ 'unix' : 'make -f make_unix.mak',
\},
\ }
Loading only on a specific command or filetype:
NeoBundleLazy 'thanthese/Tortoise-Typing', { 'autoload' : {
\ 'commands' : 'TortoiseTyping'
\ }}
NeoBundleLazy 'mattn/emmet-vim', {'autoload':
\ {'filetypes': ['html', 'xhttml', 'css', 'xml', 'xls',
'markdown']}}
Dependecy handling:
NeoBundleLazy 'xolox/vim-lua-ftplugin' , {
\ 'autoload' : {'filetypes' : 'lua'},
\ 'depends' : 'xolox/vim-misc',
\ }
You even can specify the revision if you don't want the latest revision of your
plugins. Read the documentation for all features.
https://github.com/Shougo/neobundle.vim/blob/master/doc/neobundle.txt
You can have really a lot of plugins in your vimrc, but if they all are loaded
lazy your vim will be fast, because only the plugins you need are used.
Shougo's own vimrc is a nice example of how many you can have without a problem.
https://github.com/Shougo/shougo-s-github/blob/master/vim/.vimrc
I never used VAM, sorry Marc. NeoBundle does everything I want.
Marcel Boon
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
Excerpts from Nikolay Pavlov's message of Wed Dec 25 07:43:17 +0100 2013: Is forced remote update really needed? Okular is known to automatically reload changed files, so does xdvi. Do not know whether xpdf has this feature, but it is not unlikely. Evince does reload when it gets selected. I've documented both: http://vim-wiki.mawercer.de/wiki/languages/latex.html This case alone should be a hint why a maintained wiki is valuable to all, please join ! Marc Weber -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
Its been a pleasure discussing with you. I learnt a lot from it. @MarcWeber thanks a lot for your cordial response. I use some of your plugins love them. Some of you, I think got me wrong. I am not a Vim hater. If I was, I wouldn't have come here at all. Actually every new system/IDE/editor I use, the first thing I do is, setup plugins so that it behave like Vim itself. But what I want, is not using anything else at all. Why use something like Visual Studio/Eclipse when I have Vim. But whether you agree or not, Vim's debugging support is not up to the mark. I tried PyClewn, Setting it up is a complete mess, let alone using it. About embedded shell support, why are you thinking its the feature of OS? Let me try a bit, lets say you have Screen.vim installed put :IPython! in command line. It opens a split, just like now supports every operation like now, but doesn't use something like Tmux. And by supporting it natively it will not need copying the code to window. As much as I have seen, Vim-R-Plugin managed to do it best. I am quite sure he had to manage a lot of workaround to do that using screen. But if it was supported natively, it would have been much easier on his part. And some of the problems in this option are pointed by MarcWeber. But nevertheless, it was a good experience. with regards, Rafee -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
On Tuesday, December 24, 2013 8:53:19 PM UTC+4, Ishfaque Jahan Rafee wrote: Its been a pleasure discussing with you. I learnt a lot from it. @MarcWeber thanks a lot for your cordial response. I use some of your plugins love them. Some of you, I think got me wrong. I am not a Vim hater. If I was, I wouldn't have come here at all. Actually every new system/IDE/editor I use, the first thing I do is, setup plugins so that it behave like Vim itself. But what I want, is not using anything else at all. Why use something like Visual Studio/Eclipse when I have Vim. But whether you agree or not, Vim's debugging support is not up to the mark. I tried PyClewn, Setting it up is a complete mess, let alone using it. About embedded shell support, why are you thinking its the feature of OS? Let me try a bit, lets say you have Screen.vim installed put :IPython! in command line. It opens a split, just like now supports every operation like now, but doesn't use something like Tmux. And by supporting it natively it will not need copying the code to window. As much as I have seen, Vim-R-Plugin managed to do it best. I am quite sure he had to manage a lot of workaround to do that using screen. But if it was supported natively, it would have been much easier on his part. And some of the problems in this option are pointed by MarcWeber. Wondering who said about OS here? I said about plugins. We need some things that will make embedding shell easier (mostly async support). I do not see how one needs direct support for such a specific task in vim. And do not talk about screen (it supports tmux BTW, if you are talking about http://www.vim.org/scripts/script.php?script_id=2711). Check out Conque_Shell: it is almost full vt100 terminal embedded in the vim buffer. Not perfect: last time I remember using it it suffered from color-related problems (using colors sometimes) and lagging updating (this requires some asynchronous features or at least recent settimeout/setinterval patch). If you have non-regex-based API for syntax coloring and threading support you can do much more then if you have just embedded shell support. Once you have threading it is much easier to write asynchronous :make/:grep/:vimgrep (preferably in the vim core, not in some plugin), but they do not require any kind of embedded shell support. But nevertheless, it was a good experience. with regards, Rafee -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
About Vim vs Emacs (latex-preview mode): There is a third option: Lyx.
About debugging: vim-addon-async based debugging is available for
PHP/Ruby/python pdb.
plugin names:
github.com/MarcWeber/vim-addon-{xdebug,rdebug,rdebug-ide,python-pdb}
The python plugin might be incomplete, at least stepping should work,
you can enter pdb commands at the python process window (see
vim-addon-async).
They are not perfect, but could give you some idea what needs to be
done to have a VimL only solution. Some features are not implemented
yet.
Again: use the best tool for a job, thus consider using emacs for
debugging if none of the plugins suite your needs.
Here are some tips to look for plugins (I guess you know about them)
http://vim-wiki.mawercer.de/wiki/topic/finding-a-vim-plugin.html
Marc Weber
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
What I did for LaTeX a while ago was write a plugin and a script
that'd compile latex in the background, and then remotely update an
instance of xpdf to refresh with the newest file. It's a workaround,
but it works well without messing with vim itself.
P!
On 24 December 2013 16:45, Marc Weber marco-owe...@gmx.de wrote:
About Vim vs Emacs (latex-preview mode): There is a third option: Lyx.
About debugging: vim-addon-async based debugging is available for
PHP/Ruby/python pdb.
plugin names:
github.com/MarcWeber/vim-addon-{xdebug,rdebug,rdebug-ide,python-pdb}
The python plugin might be incomplete, at least stepping should work,
you can enter pdb commands at the python process window (see
vim-addon-async).
They are not perfect, but could give you some idea what needs to be
done to have a VimL only solution. Some features are not implemented
yet.
Again: use the best tool for a job, thus consider using emacs for
debugging if none of the plugins suite your needs.
Here are some tips to look for plugins (I guess you know about them)
http://vim-wiki.mawercer.de/wiki/topic/finding-a-vim-plugin.html
Marc Weber
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Français, English, 日本語, 한국어
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
On Dec 25, 2013 5:32 AM, Adrien Piérard axiopl...@gmail.com wrote:
What I did for LaTeX a while ago was write a plugin and a script
that'd compile latex in the background, and then remotely update an
instance of xpdf to refresh with the newest file. It's a workaround,
but it works well without messing with vim itself.
Is forced remote update really needed? Okular is known to automatically
reload changed files, so does xdvi. Do not know whether xpdf has this
feature, but it is not unlikely.
P!
On 24 December 2013 16:45, Marc Weber marco-owe...@gmx.de wrote:
About Vim vs Emacs (latex-preview mode): There is a third option: Lyx.
About debugging: vim-addon-async based debugging is available for
PHP/Ruby/python pdb.
plugin names:
github.com/MarcWeber/vim-addon-{xdebug,rdebug,rdebug-ide,python-pdb}
The python plugin might be incomplete, at least stepping should work,
you can enter pdb commands at the python process window (see
vim-addon-async).
They are not perfect, but could give you some idea what needs to be
done to have a VimL only solution. Some features are not implemented
yet.
Again: use the best tool for a job, thus consider using emacs for
debugging if none of the plugins suite your needs.
Here are some tips to look for plugins (I guess you know about them)
http://vim-wiki.mawercer.de/wiki/topic/finding-a-vim-plugin.html
Marc Weber
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Français, English, 日本語, 한국어
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Complete Overwrite Vim
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 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
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
Re: Complete Overwrite Vim
On Dec 22, 2013 9:40 PM, Ishfaque Jahan Rafee mij.rafee.1...@gmail.com 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. If we drop viml we might as well switch to sublime. It is pointless: it is easier to replicate non-viml vim functionality in other editors then create something usable after dropping viml. 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. Try vim-addon-manager. If plugin or VAM-kr contains description of post-install and post-update hooks then you do not need to do complicated setup by yourself. Also note that powerline does not require any complicated setup: one (installed with vundle) or five (installed with pip) lines in the vimrc and even they are not needed if you use portage/paludis (these are Gentoo system package managers) or VAM to install powerline. In this way, one can mark another plugin as dependency for his own one in a convenient way. VAM also handles dependencies. 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. Becoming?! It was a de-facto standard for years. We also do not need embedded shell support. We need threading. If vim is thread-safe adding embedded shell support is not a problem. But it is not thread-safe. You may also like to look at conque. 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 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
On Sun, Dec 22, 2013 at 01:52:35AM -0800, Ishfaque Jahan Rafee wrote: 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. :help tex-conceal It works in console vim and gvim. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@jamessan.com -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
On Dec 23, 2013 12:15 AM, Ishfaque Jahan Rafee mij.rafee.1...@gmail.com wrote: Thanks a lot for your reply, I agree to your arguments you are much more knowledgeable than me, I am sure of it. But yet requirement of compile time support for different language, while installing plugins during use, does suck. If not drop support, it should be made mandatory for all package manager to have everything as +. Because I believe compile time issues, shouldn't matter later on. As for powerline you need to do some jobs, like doing a pip installation then font installation etc. For YouCompleteMe Command-T you have to compile after installation. As these are must, not a choice, I think these should be automated. You can configure powerline so that it does not need fonts. Also Gentoo portage (not VAM) with ebuild from raiagent overlay will install some fonts for you (note: setup to get fonts working cannot be performed by pip. Full setup requires fontconfig and/or terminal configuration.). I never had much problems with my current terminal emulator thus happened to forget how much issues about urxvt we had in our bug tracker. Command-T compilation is automated by VAM, YCM compilation may be (but currently nobody have written appropriate spec). About dropping Vimscript support, I just realized how dumb the idea is. I am absolutely sorry about that. Nobody said about number 4 argument. Latex is the only major language that's pushing me to emacs. I think its about time scopes are created for plugins like preview-latex in Vim. Its impossible in terminal vim, but shouldn't be impossible on GVim. Argument number 5 was about opening up documentation where I am editing. If you ever use YouCompleteMe or Jedi-vim, you will see that they provide pydoc documentation to the buffer I am editing. The popup contains the completion data, but the documentation is displayed at a split at Top. But it would be much better if the documentation was provided at the point where I am editing, so that I don't need to move my eyes from one place to another. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
@Ben its not about being clumsy while compiling, its about not compiling at all. I always love to use pre-compiled packages from package managers. I find compiled packages hard to maintain. I find it far more comfortable to rely on package managers for update believe, there are many noobs on earth like me, who feels in similar fashion. You can say, screw you noob, go read the man page etc. But the truth is there will always be noobs. Today's noobs are tomorrows expert. Vim has the potential to have similar appeal for both class of users. But as people start repelling them, more posts like this http://devblog.avdi.org/2012/10/16/lets-stop-telling-programming-newbies-to-learn-vim-or-emacs/ will start appearing. I am afraid of that day, I don't want that day. Just few months into this editor caused me to love it. Though the credit is mostly to YouCompleteMe, yet the end result is, I love Vim that's the truth. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
On Dec 23, 2013 12:32 AM, Ishfaque Jahan Rafee mij.rafee.1...@gmail.com wrote: @Ben its not about being clumsy while compiling, its about not compiling at all. I always love to use pre-compiled packages from package managers. I find compiled packages hard to maintain. I find it far more comfortable to rely on package managers for update believe, there are many noobs on earth like me, who feels in similar fashion. You are wrong about compiling. There are only two differences between precompiled binary package installed by package manager and package compiled by package manager: 1. Not small binary packages are faster to install. 2. There are less potential points of failure when you use binary packages. By the way, pip you suggested earlier does compile, it does not use precompiled binaries except for some very rare cases. You can say, screw you noob, go read the man page etc. But the truth is there will always be noobs. Today's noobs are tomorrows expert. Vim has the potential to have similar appeal for both class of users. But as people start repelling them, more posts like this http://devblog.avdi.org/2012/10/16/lets-stop-telling-programming-newbies-to-learn-vim-or-emacs/will start appearing. I am afraid of that day, I don't want that day. Just few months into this editor caused me to love it. Though the credit is mostly to YouCompleteMe, yet the end result is, I love Vim that's the truth. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
On 22-Dec-2013 21:15 +0100, Ishfaque Jahan Rafee wrote: [1 sentence deleted] But yet requirement of compile time support for different language, while installing plugins during use, does suck. If not drop support, it should be made mandatory for all package manager to have everything as +. Better leave that decision to the package managers; I think most do try to offer as much as possible. For example, the Vim that comes with my Ubuntu installation supports all of Perl, Python, and Ruby. [2 paragraphs deleted] Nobody said about number 4 argument. Latex is the only major language that's pushing me to emacs. I think its about time scopes are created for plugins like preview-latex in Vim. Its impossible in terminal vim, but shouldn't be impossible on GVim. Vim strives to be as consistent (between terminal and GUI) as possible. See here: ,[ :help design-not ] | - Vim is not a fancy GUI editor that tries to look nice at the cost of | being less consistent over all platforms. But functional GUI | features are welcomed. ` Argument number 5 was about opening up documentation where I am editing. If you ever use YouCompleteMe or Jedi-vim, you will see that they provide pydoc documentation to the buffer I am editing. The popup contains the completion data, but the documentation is displayed at a split at Top. But it would be much better if the documentation was provided at the point where I am editing, so that I don't need to move my eyes from one place to another. Don't compare Vim too much to IDEs! Because of its strict cell layout (also in the GUI, see counter-argument 4 above), there's much less space for showing the completion information than a proportional, smaller-sized font would allow. I find the use of the preview window for additional information a very clever invention. -- regards, ingo -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
On Sun, Dec 22, 2013 at 12:15:16PM -0800, Ishfaque Jahan Rafee wrote: Nobody said about number 4 argument. Latex is the only major language that's pushing me to emacs. I think its about time scopes are created for plugins like preview-latex in Vim. Its impossible in terminal vim, but shouldn't be impossible on GVim. It's possible in both vim and gvim as I mentioned before. See :help tex-conceal. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@jamessan.com -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Complete Overwrite Vim
Vim is both: beloved and hated by me(for those reasons you mention ). I still love it more than I hate it :) To keep the summary short: This is may way to cope with it: Start documenting what to change: http://vim-wiki.mawercer.de/wiki/index.html also see this subpage - (please add all your items there so that they don't get lost) http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html The main issue is: I don't know which is the perfect way to fix everything I found yet. Will take at least till April till I know more about this. On irc there is an unoffical #vim-mutiny channel with people who would like to improve many of the things you mention. One of the reasons is: Its a lot of work. Some partial consens is: - C gets the job done, but writing abstract code is tough (too tough for me, sry. I'd even call it a waste of time - but the compiler I'd like to use does not exist AFAIK) - C++ is close to usable now that C11++ is there (with pointer knowing about responsibilities and such). - But is this the most general solution? Shouldn't we strive to merge power of Emacs/Sublime/Vim users by working on apis and implementing the plugins we want based on those apis? Or create a new compiler which can compile down to js, C, lisp so that plugins can be shared across emacs/vim/Yi ? If you follow the path you've started (thinking about what sucks and how to improve) you'll start learning that there are many solutions. Which one is best? I invite you to take part finding it. But let me also try to help you with your current issues 1. Drop support for anything except Python (including vimscript) vimscript is 70% of vim. A lot of plugins such as matchit are used that often that dropping vimscript means you can start using Emacs right away. Also the VimL stuff is coupled with Vim functionality (internally), eg there is no python only implementation of map, command like commands. So for now forgett about it unless you have much time. that, due to some compile time events, they can't use this plugin. Well - maybe join gituhb.com/MarcWeber/vim-addon-manager and add a bug report that it should add constraints, such as this plugin requires ruby - thus prevent installing it. However Command-T is well known, and there are many alternatives which work almost as good, see this simple FastGlob implementation which has been good enough for me for ages: http://vim-wiki.mawercer.de/wiki/topic/opening-switching-files.html There are many additional implementations. Maybe even try such: https://github.com/Shougo/unite.vim Thus think about whether you really need it. Also installing vim with ruby support is dead simple if you need the right distribution, such as nixos linux. Dropping Vimscript support may be the toughest job, but think of it. You're wrong. Because then you could just use Yzis. And that has been abondoned. Thus it has been done. Community is still here - think and learn about why. Yzis uses lua though. Do you feel in your heart that, there's anyone on earth, who honestly want to program in vimscript? Depends on the task. Complicated or performance critical stuff: No. But given its age useful is - autoload feature - that eval happens to be close to json_decode - releading works nicely (With reload plugin) - ... but yes, no closures (funcref in github.com/MarcWeber/vim-addon-mw-utils) implements a workaround and similar make it hard. But the bigger problem is async support. Is there anything, that can be done in vimscript, but can't be done in python? Wrong question. XSL and Haskell type level programming both are touring complete, too. Its worth that VimL can be interrupted in for loops and resize events get triggered (due to run event loop now to look for ctrl-c abort) and such. That sucks. Fixing it would require introducing threading etc. 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. I totally agree, but you also split community which is why it should be wise to think about which upstream to provide. 2. Improved plugin management like pip. Reason: I am a big fan of Vundle. Again - try vam. Vundle was started after VAM. VAM is more powerful. See here: http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html (if somebody feels any of the tools being treated unfair just fix, thanks) That you don't mention vim-addon-manager means you didn't know about it (which means that Vim also has a documentation issue, again, something I want to fix with the simple git based wiki. Currently the docs are spread over :help www.vim.org www.vim.org/scripts vim wikia http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html and many additional places But if you have a look at the amount of contributors to my wiki you'll understand that its the same
Re: Complete Overwrite Vim
(Ishfaque, resending this to the list with my subscribed e-mail address. Please reply to this one if you do.) On Sun, Dec 22, 2013 at 01:52:35AM -0800, 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. IMHO this is unjust reasoning. I feel in my heart that there are many people on earth and wherever else[1] who honestly do NOT want to program in Python. I believe this is true for any language[2]. Take it this way, Vim is at least respecting people's faith by giving the option to choose your religion. The world of an editor is much like the world itself. Heterogeneous with respect to beliefs, thoughts and choices. Upstream still chooses a way and go with it. (read vimscript) To make everyone happy you give everyone the option to choose whatever way they demand to choose to follow you. (read python, ruby) And even the choice to get rid of you and walk another way. (read forking) Now, compare the availability and feasibility of these options between emacs, vim and sublime. You get the idea? 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. I'd like this to happen. (Still there are many number of options to choose from and none of us should be forced into pip. But you said 'like pip' not 'use pip' so I'll stop.) 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. You are confusing apples with oranges. Vim is neither a de-facto standard, nor an operating system. It is an editor with a religious background. If you are looking for an IDE, I know one with all the support you want built-in. It is called UNIX (Bonus: 99% of the time you get vi installed by default.) 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. I don't know what preview-mode is. 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. I am inclined to think this is not really a priority. Personally I wouldn't want documentation stuck into my nose and would rather read it at the top. (This is just an opinion.) [1]: Counting on the fact that some aliens might just not like the five surviving Pythons [2]: http://blog.aegisub.org/2008/12/if-programming-languages-were-religions.html -- Ali Polatel pgp0GOk1ZSDw9.pgp Description: PGP signature
more GUI features in GVIM? (RE: Complete Overwrite Vim)
From: vim_dev@googlegroups.com On 22-Dec-2013 21:15 +0100, Ishfaque Jahan Rafee wrote: Nobody said about number 4 argument. Latex is the only major language that's pushing me to emacs. I think its about time scopes are created for plugins like preview-latex in Vim. Its impossible in terminal vim, but shouldn't be impossible on GVim. Vim strives to be as consistent (between terminal and GUI) as possible. See here: ,[ :help design-not ] | - Vim is not a fancy GUI editor that tries to look nice at the cost of | being less consistent over all platforms. But functional GUI | features are welcomed. ` Sure, this is an important point, so - see my further text [*foo*] Don't compare Vim too much to IDEs! Because of its strict cell layout (also in the GUI, see counter-argument 4 above), there's much less space for showing the completion information than a proportional, smaller-sized font would allow. I find the use of the preview window for additional information a very clever invention. Recently, I've found out that it is quite possible to add GUI Gtk2 widgets directly into GVIM(gtk2); likewise - surely - for other GUI vims, so - making it possible having either preview windows (smooth dropdown listboxes for completion or distant view window a la sublime's or etc) [*foo*]: while - nice to have, it would make VIM and GVIM further away from each other, and it could be that this is not in line with general strategy. So, if a bit more of GUI API will be exposed - GVIM could be scripted for more visual features by user - is it desirable or not? -- -- 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 vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
