www.vim.org contents - what about adding a git based wiki everybody can edit?
Marc Weber
answering common questions such as:
- how to use Vim for python development
- how to configure Vim for coding C/C++
- how to does a common .vimrc look like ?
maybe even add a .vimrc configurator and everybody can provide
snippets?
Example how it could look like: http://mootools.net/core/
However there are much more item - thus a JS based filter by
keywords would be nice.
- ...
On #vim pages like http://sontek.net/turning-vim-into-a-modern-python-ide#id21
are references (which is a good thing) - BUT:
- it still references old msanders snipmate repo
- it does not talk about pyton repl with completion implementations
which are available for Vim (such as vim-addon-async)
That's why I think that we should add kind of "wiki" to www.vim.org.
Modifying it should be dead simple (like adding snippets to
snipmate-snippets). That's why I consider providing any git based
wiki system people can either edit online or by cloning the git repo
into any dir and modifying the source files directly.
This also means that you can browse / read everything offline.
The format used in text files should be dead simple such as vim help
file syntax or markdown like syntax. (I also know that there are many
wiki like plugins for Vim).
Even if its not 'official' at the beginning - such a page could be
created and added integrated into www.vim.org later at some stage.
How do you feel about such a change? Would you appreciate it?
Marc Weber
Ben Fritz
On Feb 20, 9:07 pm, Marc Weber <marco-owe...@gmx.de> wrote:
> I feel thatwww.vim.orgcontents are outdated - and I'd likewww.vim.org
> - how to use Vim for python development
> - how to configure Vim for coding C/C++
> - how to does a common .vimrc look like ?
> maybe even add a .vimrc configurator and everybody can provide
> snippets?
> Example how it could look like:http://mootools.net/core/
> However there are much more item - thus a JS based filter by
> keywords would be nice.
> - ...
>
>
> - it still references old msanders snipmate repo
>
> - it does not talk about pyton repl with completion implementations
> which are available for Vim (such as vim-addon-async)
>
> That's why I think that we should add kind of "wiki" towww.vim.org.
> Modifying it should be dead simple (like adding snippets to
> snipmate-snippets). That's why I consider providing any git based
> wiki system people can either edit online or by cloning the git repo
> into any dir and modifying the source files directly.
> This also means that you can browse / read everything offline.
>
> The format used in text files should be dead simple such as vim help
> file syntax or markdown like syntax. (I also know that there are many
> wiki like plugins for Vim).
>
> Even if its not 'official' at the beginning - such a page could be
> How do you feel about such a change? Would you appreciate it?
>
pages on the existing wikia.com wiki with prominent links from
vim.org? code.google.com also provides a wiki, IIRC. I don't see a
need to create something new.
Marc Weber
> Why not a real wiki with real wiki syntax? Or why not just create
> pages on the existing wikia.com wiki with prominent links from
> vim.org? code.google.com also provides a wiki, IIRC. I don't see a
> need to create something new.
That in turn could make people contribute little bit more because
*editing in vim* is that easy :)
And no, I'm not talking about reinventing the wheel,
it does already exist:
solution 1: http://hackage.haskell.org/package/gitit
solution 2: Vim help file syntax
solution 3: http://www.vim.org/scripts/script.php?script_id=2226
Why not mediawiki? Because sending patches requires "logging in"
Because you can't use Vim for editing (I know that there are plugins
which come close - but - we just *love* Vim, don't we?)
Marc Weber
Christian Brabandt
There used to be a fused based filesystem, that allows to
edit mediawiki sites like local files. I don't know how well this works,
it used to work very well several years ago, but I haven't used it in
years and wikipediafs seems unmaintained currently.
regards,
Christian
A. S. Budden
It's also unlikely to work for all those unfortunate Windows users!
Al
A. S. Budden
I think this sounds like a good idea. I think it's important that it
looks good and not dated and that it still provides a good interface
for scripts (including the existing ones). A few random thoughts in
no particular order:
* Gitit looks pretty (as long as we don't go within a country mile of
that logo!) which is probably a good thing. It also seems to allow
editing by people who don't want to bother with getting a copy of the
code etc;
* The other two both suffer from a rather poor visual impression
unless we get into custom parsers/converters and essentially re-invent
the wheel.
* Having said that, having a way of converting Vim help file syntax
into something pretty would be really nice, especially if it could be
automatically presented for scripts that contain doc/*
* Just using something like (extended) markdown or rest or whatever
would probably give access to more beautifiers than we could ever
possibly want.
* This is a personal opinion and I fully understand that others will
disagree fervently, but my experiences with Git have generally
involved things going wrong and stuff being lost so for the
git-inexperienced among us, it might be worth either (in order of my
preference) using Mercurial (like the vim source itself), offering
both Mercurial and Git access depending on what the user prefers or
giving instructions on how to use hg-git to give people another
alternative.
* +1 for "not mediawiki"
* The MooTools Core example you gave looks good, but we need to make
absolutely sure that there is still an equivalent of
http://mootools.net/ (i.e. a landing page that tells you what Vim is).
I hate arriving at the page of a project and being presented with all
the news about the project but then having to spend 10 minutes
searching the site to figure out what it actually is! Even
www.vim.org does this to some extent, but at least it's somewhere on
the first page, albeit hidden halfway down on the left-hand side.
Al
Marc Weber
> * The other two both suffer from a rather poor visual impression
> unless we get into custom parsers/converters and essentially re-invent
> the wheel.
extend the Vim help syntax ..
Creating parsers is not that hard using the right tools.
> * Having said that, having a way of converting Vim help file syntax
> into something pretty would be really nice, especially if it could be
> automatically presented for scripts that contain doc/*
Strong argument :)
So what does vim help file syntax miss?
- it has links
- headlines ? :-(
(everything after long = or - separators?)
- links
- anchors
- code blocks
What else would be required? (maybe some standardization)
Eg if_lua also contains such headlines:
Properties
----------
o "w()" sets "w" as the current window.
o "w.buffer" contains the buffer of window "w" (read-only).
IMHO something editor friendly should be used.
> * This is a personal opinion and I fully understand that others will
> disagree fervently, but my experiences with Git have generally
> involved things going wrong and stuff being lost so for the
> git-inexperienced among us, it might be worth either (in order of my
> preference) using Mercurial (like the vim source itself), offering
> both Mercurial and Git access depending on what the user prefers or
> giving instructions on how to use hg-git to give people another
> alternative.
git can always be accessed by mercurial bridge.
Also when using github there is a SVN protocol implementation for git
AFAIK.
Also for contributing something like "git diff > file" send file would
be enough. We could provide a Vim command.
I'll shut up and wait for another days - waiting for comments and
thoughts.
> "Keep what is Vim?" at start page?
Agreed.
Marc Weber
Phil Dobbin
Hash: SHA1
I personally think that it's a terrific idea, Marc.
As you point out you can fork the repo, apply changes or add commits all
the while using Vim thereby extricating any copy/paste/convert ugliness
& have fun & help the community too.
FWIW, I'm all for it.
Cheers,
Phil..
- --
But masters, remember that I am an ass.
Though it be not written down,
yet forget not that I am an ass.
Wm. Shakespeare - Much Ado About Nothing
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: §auto-key-locate cert pka ldap hkp://keys.gnupg.net
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJPQ+3PAAoJEKpMeDHWT5ADTvcIAKq8L5Of1qIaoJ0PCE+v3VNY
mxsBMdPGnptLyyaBv3Rqh03VhJvYOSg7b5ipqQ7QeeEXsUKbmNeaB/VCK+UGWP7T
qxTKwlbUTS00XUinSM7701EcoaOYbwfhlWTU+Y5dQdp6MYO4sc2Ad4oQyYjbLUEU
hPD/fyZpkQAZIjtxh5kExtdsXWx9PbYTahUE2pgRkdDyUGj2TzOBszpPJkkWHRs7
It5QhXPuyTizDdutIM7Zjb9aPm97ka31NSI76joPEzX4ezlk6Qy2VQjcjIyBgxOq
QAVVALzPd3EIJk22Gm3uvdNFrikZRgyqovyStbXZ3Q4MfIj55Z3rAkM1Jcp5gLU=
=zJ84
-----END PGP SIGNATURE-----
stardiviner
>
> 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
>
--
>> stardiviner << =>GPG: 5D9F64D8 Twitter: @numbchild
http://stardiviner.dyndns-blog.com/author.html
Ben Fritz
On Feb 21, 10:27 am, Marc Weber <marco-owe...@gmx.de> wrote:
> Excerpts from Ben Fritz's message of Tue Feb 21 16:48:36 +0100 2012:> Why not a real wiki with real wiki syntax? Or why not just create
> > pages on the existing wikia.com wiki with prominent links from
> > vim.org? code.google.com also provides a wiki, IIRC. I don't see a
> > need to create something new.
>
> Because its you who can download it and use it as local resource.
> That in turn could make people contribute little bit more because
> *editing in vim* is that easy :)
>
would, but most of the time people will search the web for a reference
on how to do something, and just bookmark it if they want to use it
again.
> And no, I'm not talking about reinventing the wheel,
> it does already exist:
>
> solution 1:http://hackage.haskell.org/package/gitit
> solution 2: Vim help file syntax
> solution 3:http://www.vim.org/scripts/script.php?script_id=2226
>
web interface. Good to know this isn't what you are saying. I still
think it's a bad idea. We tried a reference section of the vim.org
site before, called "Vim tips". We moved it to vim.wikia.com. I wasn't
involved at that point, so I don't know all the reasons, but I don't
think it's a good idea to move back to vim.org and have TWO resources.
For one thing, it will make information harder to find. People won't
know which resource to search through, or will feel obligated to
search through both. Even worse, there are only a handful of regular
active contributors to the wiki. Adding *another* system to pay
attention to means even less attention to both resources.
> Why not mediawiki? Because sending patches requires "logging in"
> Because you can't use Vim for editing (I know that there are plugins
> which come close - but - we just *love* Vim, don't we?)
>
have somebody constantly responding to pull requests. So potentially
you need to log in anyway.
Maybe we want to allow global push rights, I don't know. The wiki
currently does *not* recquire a login, it would be similar. But one
push could change any number of pages, whereas one wiki edit only
affects a single page. Then again, repairing the damage is just
reverting the one changeset.