Complete Overwrite Vim
Ishfaque Jahan Rafee
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.
Ben Fritz
> 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?
Nikolay Pavlov
On Dec 22, 2013 9:40 PM, "Ishfaque Jahan Rafee" <mij.raf...@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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
James McCoy
> 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.
It works in console vim and gvim.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>
Ishfaque Jahan Rafee
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.
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.
Nikolay Pavlov
On Dec 23, 2013 12:15 AM, "Ishfaque Jahan Rafee" <mij.raf...@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.
>
Ishfaque Jahan Rafee
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.
Nikolay Pavlov
On Dec 23, 2013 12:32 AM, "Ishfaque Jahan Rafee" <mij.raf...@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.
>
Ingo Karkat
> [1 sentence deleted] But yet requirement of compile time support for
> not drop support, it should be made mandatory for all package manager
> to have everything as "+".
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.
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.
(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
James McCoy
> 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.
See ":help tex-conceal".
Marc Weber
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)
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.
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.
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?
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?
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.
wise to think about which upstream to provide.
> 2. Improved plugin management like pip.
> Reason:
> I am a big fan of Vundle.
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 as wikia: Only individualists try to
improve them. I cannot make contributing easier than even allowing to
edit without login.
> vundle
it eg fails on loading plugins at runtime (lazily to keep startup time
fast), it fails on non git sources - but I agree it works good enough
for most use cases.
> YouCompleteMe
Again, a distribution such as "nixos" in combination with vundle/vam
will make it a lot easier. Then you can install YouCompleteMe by distro
and symlink it to ~.vim/plugin-dir/YouCompleteMe and have it activated
by vundle/pathogen/vam.
A Vim only solution will never reall succeed installing such complicated
combinations (same about ocaml completion support, eclim etc).
> or plugins like powerline, which takes quite a bit of setup before use.
Also have a look at this which wants to use ruby gems for managing vim
plugins:
https://www.relishapp.com/kana/vim-flavor/docs/philosophy
(And now you have the mess, support Ruby or Python? Its hard to force
community)
This author didn't even reply to me when I asked about how VAM and that
project can collaborate, because VAM is also about having a maintained
pool of packages (and telling users about alternatives for outdated
packages). The implementation is not perfect but it gets the job done
IMHO.
> In this way, one can mark another plugin as dependency for his own one
> in a convenient way.
addon-info.json which may contain
{ dependencies: {
"plugin-name": { .. }
"other-plugin-name": { .. }
}
If you need more info contact me on irc or by mail.
The values of the dependencies can even be links to github urls. But I
prefer people submitting packages to VAM-kr so that they can be referred
to by uniq human readable names.
> 3. Embedded shell support like screen.vim.
you cannot use vi keys. vim-addon-async tries to be a smart async
solution redirecting stdin/out to from processes.
It implements ruby/python/php completion for repl, too.
Thus just "having a shell" might be what you want, or not.
But yeah, it sucks which is why I say that async is a real problem, too.
We know all know it.
For older Vims there has been a patch turning a buffer into a terminal.
> 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.
I need fast. Thus instead of making sure something like TList is always
on the left I map a key to "open it on the left side".
Eg I've mapped <m-s-X> where X is hjklq to wincmd X so that hiding
buffers is one hit only.
Of course my reply will not solve your problems, but it might help you
in some ways. Vim is historically grown very much, and there is no
trivial fix which can be applied in 5 days IMHO. (or at least I cannot
do it, maybe somebody else can ?)
So let me suggest that you keep posting about the most urgent problems,
maybe there are workarounds so that you can at least still use Vim in a
productive way. Community is listening and helping.
This is my biased view on the topic. My knowledge is limited, too.
I hope others point out where I'm obviously wrong.
So before suggesting to rewrite VIm have a look at history of some
famous editors such as jedit, Vim, Emacs - it does take quite a while.
Yours
Marc Weber
Ali Polatel
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.
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.
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.
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.
>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.
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
Tony Mechelynck
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.
Christian Brabandt
> 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
there wasn't any development within the last few years? Perhaps it just
works and there is not much to do. Why would that be a reason for
dropping that plugin?
> 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.
and I don't feel like switching to another language. There really is no
reason to drop support for vimscript, besides making the whole community
angry.
> 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.
before. Vim isn't about making it an emacs clone.
Best,
Christian
Ishfaque Jahan Rafee
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
ZyX
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.
Marc Weber
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
Adrien Piérard
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!
> --
> 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
Français, English, 日本語, 한국어
Nikolay Pavlov
On Dec 25, 2013 5:32 AM, "Adrien Piérard" <axio...@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.
Marc Weber
> reload changed files, so does xdvi. Do not know whether xpdf has this
> feature, but it is not unlikely.
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
marcelsp...@gmail.com
> 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
Marc Weber
> lightweight and fast. Also an example why vim-script should not be
> dropped.
proof that the language is fast enough for many (common?) use cases.
http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-viml-suck.html
The only reason why it still exists the way it is is because rewriting
(it and plugins) would be so much work.
The only reason to keep is the amount of code which has been written.
> I never used VAM, sorry Marc. NeoBundle does everything I want.
this never was a problem. In fact its a design choice: Less
possibilities to combine packages => less maintainance => less trouble.
Nobody ever created a bug report about it (yet) - authors usually fix
issues fast. If you really need a fixed well known state of your .vim,
then just put everything into a git repository (VAM recently got some
experimental support for recording this all), but due to post patches
its not that nice at all ..
Differences:
- 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.
- it allows arbitrary sources, git(hub),svn, etc.
(Due to mirroring (vim-scriptsn) I agree this is unlikely to be such a big advantage)
Anyway I've tried updating the matrix adding most NeoBundle features I
found. If you feel something is missing drop me a note:
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html
So thanks for telling me.
So it looks like there is yet another competitive rewrite of plugin
management.
Marc Weber
Marcel Boon
Excerpts from marcelspostbakje's message of Fri Dec 27 11:25:08 +0100 2013:
> Airline is a pure vim-script alternative to powerline and thus isBullshit. Just because something happens to exist which is fast does not
> lightweight and fast. Also an example why vim-script should not be
> dropped.
proof that the language is fast enough for many (common?) use cases.
http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-viml-suck.html
The only reason why it still exists the way it is is because rewriting
(it and plugins) would be so much work.
The only reason to keep is the amount of code which has been written.
this never was a problem. In fact its a design choice: Less
possibilities to combine packages => less maintainance => less trouble.
- 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.
That is great, but will only work if all packages follow the guidelines. You'll create a high quility repository this way, which is great. But I said before it also limits the number of packages as long as not every plugin developer follows that guideline.
- it allows arbitrary sources, git(hub),svn, etc.
(Due to mirroring (vim-scriptsn) I agree this is unlikely to be such a big advantage)
*neobundle-options-type*
type (String)
Specify the repository type. If omitted, a guess is made
based on {repository}.
Available types:
"nosync" : No synchronous
"raw" : Raw plugin file ("script_type" attribute is
needed)
"git" : Git
"hg" : Mercurial
"svn" : Subversion
Example:
>
NeoBundle 'git://host/path/repo.git', {'type': 'hg'}
NeoBundle 'thinca/vim-localrc', {'type' : 'svn'}
Anyway I've tried updating the matrix adding most NeoBundle features I
found. If you feel something is missing drop me a note:
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html
So thanks for telling me.
So it looks like there is yet another competitive rewrite of plugin
management.
The lazy loading is my favourite option, works with most plugins out of the box and makes Vim startup fast even with a lot of plugins installed. I think that option deserves to be mentioned. If you don't use the plugin it won't be loaded. It's loaded on demand.
Marc Weber
> packages it's not for me. I'll take the risk if I use unmaintained
> packages.
shown, such as "this plugin is is outdated, try xy instead, continue
[y/n]" - so you always have full control.
> said before it also limits the number of packages as long as not every
> plugin developer follows that guideline.
- a dump from vim.sf.net - thus its always accurate and up to date
- manually mantained set of github urls for packages which get
contributed
Then its you who can customize the function merging those sources or
adding additional name <-> repository information. (or use
'github/name/repo' shortcuts when installing)
We don't want to limit the user in any way.
If a package needs patching (eg different runtimepath in subfolder)
an addon-info.json file is written by VAM for that package according to
this patch info:
https://github.com/MarcWeber/vim-addon-manager-known-repositories/blob/master/db/patchinfo.vim
Thus all of those still work !
The goal of VAM is to make using of plugins as painless as possible -
not to limit the freedom of the user to do what he wants.
The other goal is to provide a pool of packages, which in theory could
be reused by other distribution systems such as linux distributions.
It just happens that the info is encoded in text files in a git
repository because it was fastest to get started.
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 ?
addon-info.json was meant to provide such. So I welcome all plugin
solutions to join.
> git/hg NeoBundle does too.
I know, see my wiki. Sry if I forgott to change my mail before sending.
> > VAM and NeoBundle have different target users. VAM goes for quality
> management of the plugins, NeoBundle is for the users who want to have the
> most options.
pool. Then only code is left doing whatever you want.
Eg you can also install by 'github/name/repo' and be done, too.
Just for my packages (eg vim-addon-async vim-addon-actions etc) it does
make sense to encode dependencies without having to ask the user to take
care - because there are many - because I prefer modular reusable code.
There are situations about optional dependencies, and here the user must
explictly install them. It would be wrong to hardcode them.
> lazy loading deserves to be mentioned
I did, see my wiki.
VAM has had support for lazy loading since 2012-02-27. We don't have
dummy mappings yet - but that's a trivial task to add.
Neobundle:
2012-12-29 10:29:16 - Implemented autoload mappings.
2012-12-29 07:45:30 - Implemented autoload filetypes.
So VAM has been earlier here, too (but less complete, because it missed
mappings)
Fine, I accept diversity and rewriting is good - I accept that NeoBundle
is competitive.
Marc Weber
Nikolay Pavlov
On Dec 28, 2013 9:01 PM, "Marc Weber" <marco-...@gmx.de> wrote:
>
> > > That is a nice feature, but as it is limiting the use of unmaintained
> > packages it's not for me. I'll take the risk if I use unmaintained
> > packages.
> You can always take the risk. The difference is that a small message is
> shown, such as "this plugin is is outdated, try xy instead, continue
> [y/n]" - so you always have full control.
>
> > said before it also limits the number of packages as long as not every
> > plugin developer follows that guideline.
> You're wrong. The pool is made up of
> - a dump from vim.sf.net - thus its always accurate and up to date
> - manually mantained set of github urls for packages which get
> contributed
Set of SCM URLs is *mostly* no longer maintained manually. There are some URLs maintained manually and there still will be more, but autoget.py now handles the great part of plugins; almost all new URLs come from autoget.py.
Note that for every person who has an idea about how boring it is to maintain such pool "manually maintained set of URLs" is a disadvantage.
And also do not forget that we do not have a set of *github* URLs. Supporting non-github SCM URLs is one of our advantages over some plugins.
>
> Then its you who can customize the function merging those sources or
> adding additional name <-> repository information. (or use
> 'github/name/repo' shortcuts when installing)
github:name/repo if I am not mistaking.
Marcel Boon
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 ?
From his github page: Shougo...@gmail.com
> > VAM and NeoBundle have different target users. VAM goes for quality
> management of the plugins, NeoBundle is for the users who want to have the
> most options.
You got a bad impression. VAM allows you to opt-out from the default
pool. Then only code is left doing whatever you want.
Thank you for clarifying this. My impression was based on your email. It was my lack of knowledge about VAM.
> lazy loading deserves to be mentioned
I did, see my wiki.
VAM has had support for lazy loading since 2012-02-27. We don't have
dummy mappings yet - but that's a trivial task to add
http://bling.github.io/blog/2013/06/02/unite-dot-vim-the-plugin-you-didnt-know-you-need/
http://eblundell.com/thoughts/2013/08/15/Vim-CtrlP-behaviour-with-Unite.html
http://lonelyproton.com/2013/11/Unite.vim/
Marc Weber
bazaar is like svn/mercurial/git/cvs/fossil (just yet another SCM)
> get-vim-scripts-org?
dropped, you're right.
> You didn't know what unite was.
comment was bad, I agree.
I mean you can complete
- arbitrary plugins (if you have pool like VAM has)
- installed plugins
- plugins to uninstall
etc
Marc Weber
Shougo
>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.
Vim must not drop support of Vim script.
Because, Vim must have backward compatiblities.
If Vim drop it, Vim will be not Vim(it is Vim like another editor).
And the suggestion is too hard work.
If Vim supports another default script language, I think Lua is better.
Yes, Python is good language and has good libraries.
But it is too huge as default built-in language.
Lua is small, fast, and available most of architectures.
So the "I think xxx is better default script language than VimL" is like the editor war.
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 a topic in the Google Groups "vim_dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_dev/drZDXZmYBsY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_dev+u...@googlegroups.com.
Shougo
> 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.
Benjamin Klein
> 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?
--
b
Sent from my iPhone
Marc Weber
> 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 fact I don't, which is why I'd like to collaborate in the future.
I've created this issue at VAM-kr to indicate that I'd like to
collaborate.
https://github.com/MarcWeber/vim-addon-manager-known-repositories/issues/78
> 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.
> neobundle has supports of git, svn, hg. Bazzaar and archives are not.
> You can add the features easily.
that much. Ho can we collaborate on recipes? If this means its time to
move contentsn of VAM-kr into a online database I'm fine with such
choice.
Maybe just tell me what has been the reason to continue / start NeoBundle ?
I'd like to understand what happened from the beginning. In the end VAM
was started in 2009-12, NeoBundle was started in 2011-09.
We as community really have other problems to work on than
duplicating recipes or "plugin managers" ?
Marc Weber
Shougo
>
> > 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.
>
> But you have time to maintain your own plugin management system?
>
> In fact I don't, which is why I'd like to collaborate in the future.
>
>
>
> I've created this issue at VAM-kr to indicate that I'd like to
>
> collaborate.
>
> https://github.com/MarcWeber/vim-addon-manager-known-repositories/issues/78
>
>
>
> > 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.
>
> I agree, can we talk about how this should look like ?
>
>
>
> > neobundle has supports of git, svn, hg. Bazzaar and archives are not.
>
> > You can add the features easily.
>
> If you support two adding a third is trivial - which is why I don't care
>
> that much. Ho can we collaborate on recipes? If this means its time to
>
> move contentsn of VAM-kr into a online database I'm fine with such
>
> choice.
>
>
>
> Maybe just tell me what has been the reason to continue / start NeoBundle ?
>
> I'd like to understand what happened from the beginning. In the end VAM
>
> was started in 2009-12, NeoBundle was started in 2011-09.
>
I didn't know about VAM in that time.
I think to use VAM is too hard in Vundle user and the settings is difficult.
It is like snipMate vs xptemplate problem.
>
>
> We as community really have other problems to work on than
>
> duplicating recipes or "plugin managers" ?
>
User should choose your own plugin manager.
But "duplicate plugin information repositories" is not OK.
It is useless.
>
>
> Marc Weber
Vladimir Marek
[...]
> > 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.
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