Re: breaking with history ?

> magic [..] forces every single script out there to handle it.
That's fixable by prefixing all regex by \m ?

Then 'lazyredraw', off by
> default, no less: why is this an option to begin with?
Can you add this to the page?
http://vim-wiki.mawercer.de/wiki/vim-development/breaking-with-the-past.html then add ?vim_edit=1
And describe why which options should be gone (or at least be hidden)

> About the docs, can you tell off the top of your head how can I get
> to the list of functions gouped by category? To the list of operator
> priorities? The list of exceptions? How do you even search for these?
But is it a problem? Join irc, ask. Join mailinglist, ask. You usually
get good replies instantly. Yes - it sucks, but people listen and they
do help.

> As for what I'd do differently should the Vim project start from
> scratch, I'd say that would be the GUI.
That's not enough. What exactly are you missing slowing you down?

> most of us) but still valid points. Example of such a rant:
> http://delvarworld.github.io/blog/2013/03/16/just-use-sublime-text/

Let me comment shortly. (CCing the author, because I cannot comment on that
homepage)

> mouse faster than /word<cr>
Vim allows using the mouse, so that's not against Vim

> 1% of time you use features you train yourself for about 2 years
> (thus after leaving the learning curve)
Well, Vim has a 'insertmode' setting. I have a collegue who only is
using Vim for merging. I set that option, and he knowns how to :w.
That's it. That's again not against Vim (eventuall against how to learn
Vim).

> Plugins and Extensibility 1: Management
This really makes me angry. I've been very loud trying to fix this
problem. Still a lot of people don't know that VAM (vim-addon-manager)
is a solution to this. VAM was started end of 2009, exactly to
solve all of this problems. Yet in 2013, there are too many people who
don't even know that it exsits. The blog post dates 2013.
That's why the blog post talks only about "Pathogen" and "Vundle" - note that
Vundle was started after VAM.

So why does this happen? There is no way to modify vim.sf.net in a nice
way, to tell people about what options exist.

That's why almost all plugin authors jump to github, copy paste a
plugin, and adopt it. So they also adopt the "how to use pathogen"
section. After all pathogen is cool, it solves a problem, doesn't it?
Thus if you look at 10 plugins at github you're very likely to
learn about Pathogen, and you're very likely to miss vim-addon-manager.

Why? Because VAM tries to make plugin management that easy that its not
necessary to add long install instructions.

Wikia is not on www.vim.org - so Wikia is not always used. Also people
like me today don't want to contiribute, because Wikia shows too much
ads (for my taste) - yet you cannot get rid of it because it is indexed
by google.

My answer to this is a git based wiki you can editor online:
http://vim-wiki.mawercer.de/wiki/index.html
Its as simple as not needing anything but builtin gf feature for
navigation.

So please join that new wiki effort, so that we can move it to
vim.sf.net in the future. The only way doing so is by having enough
valuable content and contributions happening.

Of course the text I wrote about is based on my view, which might be
incomplete.

But yeah, it would be damn cool if we could create an API so that
plugins could be used by sublime and by Vim (and by Emacs, which also
has python bindings)

Marc Weber

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.