Marc Weber wrote:
> > I also wonder if a shared document is the best way to do these things.
> > At least this allows multiple people at the same time making changes.
> > Most wiki's are not good at that.
>
> If it is versioned then why not ? It can be accessed easily by everyone.
> If its not versioned I'd prefer git or mercurial ..
There is a history. Using a versioning system doesn't allow easy
editing, tables, etc.
> > Comments?
> Given that there are tons of different compile configuration of Vim and
> tons of operating systems Vim runs on .. calling for some human testers
> is nice but will not bring any benefits in the future.
>
> What about setting up a test suite (driven by git or mercurial?)?
There already is a "make test". Extending this is also a good idea.
And perhaps moving slower tests to a separate target, so that one can do
a quick check after building and a more comprehensive test.
> I could setup a cron-job which pulls latest tests patches once a day and
> runs it on Linux.
I run the tests quite often, this won't catch much more.
> If we used Ruby test suites it can be run easily on all major OS
> systems.
>
> I can't do so today - but within some days.
>
> Comments?
I prefer a Vim-script solution. One problem with this is that one
cannot check what is actually on the display. E.g., to check for the
conceal bugs that have been fixed recently.
--
Clothes make the man. Naked people have little or no influence on society.
-- Mark Twain (Samuel Clemens) (1835-1910)
/// Bram Moolenaar -- [email protected] -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
--
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
