vim sf page ratings and feedback feature

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

vim sf page ratings and feedback feature

MarcWeber
Hi Bram & community,

There are two things on the Vim sf page which bugged me for years:

a)
  There is no way for users adding comments.

  So as plugin author you just get feedback like a rating -2/2 but you
  have no clue why. That's very disappointing.
  This happened to me recently.
  http://www.vim.org/scripts/script.php?script_id=2934
  I think this plugin is great because you don't have to remember dozens
  of mappings.

  To keep open source projects active you need positive feedback loops.
  This doesn't happen for Vim plugins.

  So consider one case: You have uploaded a bug by accident. One users
  downloads your plugin. It doesn't work. So he rates the plugin with
  (-1).

  You can fix the bug. You rating is still -1. The only thing you can do
  about it is polluting the page by adding a new plugin-name which is bad.

b)
  users can't add comments. So if there is a newer plugin or if
  something didn't work or if users have additional comments whatsoever
  they can't put them on the site. The result is that the site isn't as
  valuable as it could be. Eg have a look php.net. If there is a bug
  everyone can upload a comment posting his workaround. It's ugly but it
  works pretty well.

  Indeed it can be much simpler. Adding one link to a discussion site on
  the Vim wiki eg http://$VIMWIK/pulgin_plguin_nr would be enough.
  Zero effort but much value.

c) (less important)
  Plugin information can't be exported. This I and the author of Vimana
  we both implemented hacks to get a list of plugins to support
  installing plugins in an easier way.

  So I'd like to add an interface which returns a big json dict (which
  can be read by Vim!) telling about all plugins and their latest
  versions. This will safe some traffic and a lot of CPU power..

I know both: PHP and MySQL. I can do all changes. There is one thing I'm
unsure about. The Vim database contains information about who donated
how much. This is sensible data. I'm not sure whether I should know
about those records.

So what shall I do to get these features implemented? Ask community on
the mailinglist how they think about it?

Those changes don't cause much work. But they will generate much value
to everyone.

Yours
Marc Weber

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Maxim Kim
Hi Marc,

On 9 фев, 02:20, Marc Weber <[hidden email]> wrote:
> Hi Bram & community,
>
> There are two things on the Vim sf page which bugged me for years:
>
> a)
>   There is no way for users adding comments.

I agree - comments are good to have.

But what about spammers? I rememember there was an issue with comments
on 'Tips' on vim.sf.net.

Maxim.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Tom Link-3
> But what about spammers? I rememember there was an issue with comments
> on 'Tips' on vim.sf.net.

IIRC you were able to post a tip or commment on a tip as anonymous
user without being logged in.

Since there already are several vim-related collaborative media in use
(vim-use, vim.wikia) I wonder if it were possible to use one of those.
E.g., the template for the plugin page could link to a wiki page with
the script ID, e.g., http://vim.wikia.com/wiki/Script123 Such a change
should be rather easy to implement if the wiki maintainers agreed with
this suggestion, I guess. Such a page could also be a place where
users post tips & tricks & sample configurations related to a specific
plugin.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

MarcWeber
Hi Tom,
> the script ID, e.g., http://vim.wikia.com/wiki/Script123 Such a change
Have a look at section b).
I did suggest this. Users are lazy. So something native would be best.

Anyway someone has to give me access to the code so that I can implement
those features. Maybe someone says he dislikes the ideas. So let's wait
a couple of days..

Thanks for your fedback!
Marc Weber

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Benjamin Fritz
In reply to this post by Tom Link-3


On Feb 9, 2:34 am, Tom Link <[hidden email]> wrote:
>
> Since there already are several vim-related collaborative media in use
> (vim-use, vim.wikia) I wonder if it were possible to use one of those.
> E.g., the template for the plugin page could link to a wiki page with
> the script ID, e.g.,http://vim.wikia.com/wiki/Script123Such a change
> should be rather easy to implement if the wiki maintainers agreed with
> this suggestion, I guess. Such a page could also be a place where
> users post tips & tricks & sample configurations related to a specific
> plugin.

For a while now, we've been resisting having a wiki page for every
plugin out there, as such information could easly become overwhelming
or get out of date. We want searches on the wiki to show mostly tips
about how to use Vim, how to write scripts, etc. We didn't want it to
become a place to search for plugins.

Perhaps it would be possible, if we create a new namespace for the
plugin pages (I think this is possible). Searches would by default not
include these pages, but a user could specify that they *wanted* to
search the plugin namespace if desired.

We'd need to set up a standard format, maybe with a "bug reports"
table that includes the script version of the bug, and a very obvious
"current version" note at the top of the tip.

I've copied the mailing list for the wiki.

John, what do you think?

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

MarcWeber
Hi Ben,

Excerpts from Ben Fritz's message of Tue Feb 09 17:40:15 +0100 2010:
> plugin out there,   [..]

Just think about missing one comment:

"This plugin is superseded. It has been merged with xy.. use xy instead"

How much value can this one comment generate for you?

Think about the original plugin author either
a) died
b) is no longer interested
c) forgot his password (Yes! There is no way to get back a password. The page tells you so!)

I agree that we never ever want to delete any version. But I think we
must have a way to mark such packages as deprecated.

I've started doing so in vim-addon-manager-known-repositories.
However not many people are using it at this point in time.

Why is this that important:
If you look for scripts you do search www.vim.org first.
It's much more unlikely that you look for comments on a wiki.

I dream of:

get plugin vim-addon-c(pp)-tools and have *all* features I can get doing C(++) development using Vim.
Same for Ruby, Vim, Perl, Python, C#, etc.

Because if man power is spread results will suffer. Vim *is* a great
editor. However to keep everything working we have to join efforts else
people (including me) will use Eclipse or such as main editor because
IDE features do matter a lot. I agree that I'm a programmer and that I
want to see specific features to get my work done faster. But it's
programmers who can move Vim into the future. And if programmers have to
spend weeks on setting up Vim they may just use another tool. Vim will
never die. But it maybe won't have the market share it deserves..

There are more things I don't understand yet. Python and Ruby are
supported by Vim. But all interfaces seem to provide only a exec and a
vimeval function. If you want to execute a simple command such as echoe
you have to start thinking about quoting strings. Why don't those
interfaces provide a simple vim_escape function ?
But that's a different (off) topic..

Marc Weber

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Bram Moolenaar
In reply to this post by MarcWeber

Marc Weber wrote:

> Hi Bram & community,
>
> There are two things on the Vim sf page which bugged me for years:
>
> a)
>   There is no way for users adding comments.
>
>   So as plugin author you just get feedback like a rating -2/2 but you
>   have no clue why. That's very disappointing.
>   This happened to me recently.
>   http://www.vim.org/scripts/script.php?script_id=2934
>   I think this plugin is great because you don't have to remember dozens
>   of mappings.
>
>   To keep open source projects active you need positive feedback loops.
>   This doesn't happen for Vim plugins.
>
>   So consider one case: You have uploaded a bug by accident. One users
>   downloads your plugin. It doesn't work. So he rates the plugin with
>   (-1).
>
>   You can fix the bug. You rating is still -1. The only thing you can do
>   about it is polluting the page by adding a new plugin-name which is bad.

The problem with feedback is that spammers will misuse it.  We have had
this problem with Vim tips before they were moved to the wikimedia site.

If we can put the comments also on the wikimedia site, with a link to
it, perhaps that would work.

> b)
>   users can't add comments. So if there is a newer plugin or if
>   something didn't work or if users have additional comments whatsoever
>   they can't put them on the site. The result is that the site isn't as
>   valuable as it could be. Eg have a look php.net. If there is a bug
>   everyone can upload a comment posting his workaround. It's ugly but it
>   works pretty well.
>
>   Indeed it can be much simpler. Adding one link to a discussion site on
>   the Vim wiki eg http://$VIMWIK/pulgin_plguin_nr would be enough.
>   Zero effort but much value.

You can already add links, but a generic mechanism would indeed be
better.

There, I added a link in the header.  Let me know if this will work.

John Beckett can perhaps set up a template for a scripts wiki page.

> c) (less important)
>   Plugin information can't be exported. This I and the author of Vimana
>   we both implemented hacks to get a list of plugins to support
>   installing plugins in an easier way.
>
>   So I'd like to add an interface which returns a big json dict (which
>   can be read by Vim!) telling about all plugins and their latest
>   versions. This will safe some traffic and a lot of CPU power..

Since there is no specified format, I don't know of a reliable way to do
this.

I don't think there is a way to get a list of uploaded files by date.
Perhaps that's all you need.

> I know both: PHP and MySQL. I can do all changes. There is one thing I'm
> unsure about. The Vim database contains information about who donated
> how much. This is sensible data. I'm not sure whether I should know
> about those records.
>
> So what shall I do to get these features implemented? Ask community on
> the mailinglist how they think about it?
>
> Those changes don't cause much work. But they will generate much value
> to everyone.

I'm careful about giving more people access to the site directly.  If
you say what page you would want to change I can send you the php code
and you can send me a diff.

--
hundred-and-one symptoms of being an internet addict:
211. Your husband leaves you...taking the computer with him and you
     call him crying, and beg him to bring the computer back.

 /// Bram Moolenaar -- [hidden email] -- 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.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

tux.
Bram Moolenaar schrob am 09.02.2010 21:20:
> I'm careful about giving more people access to the site directly.
>  

BTW, did you switch SF.net's new "no export to North Korea" switch?

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

RE: vim sf page ratings and feedback feature

JohnBeckett
In reply to this post by Benjamin Fritz
Ben Fritz wrote:

> For a while now, we've been resisting having a wiki page for
> every plugin out there, as such information could easly become
> overwhelming or get out of date. We want searches on the wiki
> to show mostly tips about how to use Vim, how to write
> scripts, etc. We didn't want it to become a place to search
> for plugins.
>
> Perhaps it would be possible, if we create a new namespace for
> the plugin pages (I think this is possible). Searches would by
> default not include these pages, but a user could specify that
> they *wanted* to search the plugin namespace if desired.

Yes, we could request a namespace specifically for discussion of
vim.org scripts. However, while the problem with vim.org/scripts
is real, I do not want a bunch of extra pages dumped on the wiki
because such pages:
- overwhelm people looking for basic information
- become obsolete as once-enthusiastic authors move on
- have to be maintained by me and Ben Fritz

If we could start again, vim.org/scripts might be managed
differently, but I think there is too much history now for any
realistic collaboration between the scripts site and a wiki
because we cannot force people to update the information on two
different sites.

If it were possible to put the plugins into a reasonably small
number of categories, then it would be reasonable to have one
wiki page per category of script. For example, one wiki page
would list all non-obsolete plugins relating to searching, with
brief notes on status and usage, and a link to the
vim.org/scripts page for installation and usage notes.

I made a page on the wiki to hold various scripts that had
previously been described in separate tips. I think the format
is useful to allow readers to quickly scan for interesting
scripts:
http://vim.wikia.com/wiki/Vim_scripts

There was a suggestion that a wiki page would allow users to
write meaningful comments with useful feedback. Unfortunately,
I think useful comments would be very rare because people are
overwhelmed with choice on the Internet, and Vim is now just
another tool, and the hard-core Vim users are just using Vim,
having got over the initial wave of evangelism that creates an
interactive fan base.

John

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Ingo Karkat
In reply to this post by Bram Moolenaar
On 09-Feb-2010 21:20, Bram Moolenaar wrote:
> I'm careful about giving more people access to the site directly.  If
> you say what page you would want to change I can send you the php code
> and you can send me a diff.

I agree that there should be very few committers to the site; however, in my
opinion, freely sharing the (PHP) source code of the site might have encouraged
more people to send you a patch in order to improve the site's functionality.
As it is, there are these occasional discussions about the site's deficiencies,
but nobody is able to step up and implement an alternative, because the source
code is relatively closed.

So, I would propose putting the vim.org's source code (not the actual user
database and scripts!) into a (Mercurial?) repository (separate from Vim's
source code).

-- regards, ingo

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Bram Moolenaar

Ingo Karkat wrote:

> On 09-Feb-2010 21:20, Bram Moolenaar wrote:
> > I'm careful about giving more people access to the site directly.  If
> > you say what page you would want to change I can send you the php code
> > and you can send me a diff.
>
> I agree that there should be very few committers to the site; however,
> in my opinion, freely sharing the (PHP) source code of the site might
> have encouraged more people to send you a patch in order to improve
> the site's functionality.  As it is, there are these occasional
> discussions about the site's deficiencies, but nobody is able to step
> up and implement an alternative, because the source
> code is relatively closed.
>
> So, I would propose putting the vim.org's source code (not the actual
> user database and scripts!) into a (Mercurial?) repository (separate
> from Vim's source code).

This would also make the site vunerable for hackers.  I don't know
enough PHP to locate possible holes and opening it up won't fix that.
I rather not do this.  Having only a few maintainers looking at the code
is better.

--
hundred-and-one symptoms of being an internet addict:
212. Your Internet group window has more icons than your Accessories window.

 /// Bram Moolenaar -- [hidden email] -- 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.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Tom Sorensen
On Wed, Feb 10, 2010 at 9:47 AM, Bram Moolenaar <[hidden email]> wrote:
> This would also make the site vunerable for hackers.  I don't know
> enough PHP to locate possible holes and opening it up won't fix that.
> I rather not do this.  Having only a few maintainers looking at the code
> is better.

Really? Security through obscurity?

If the site is vulnerable, then I don't believe that having the source
hidden is going to significantly deter a hacker. It will certainly
impede any attempts to fix it though.

I love vim and greatly appreciate all of the work you've put into it
and the community over the past two decades. But the website really
could use some improvement. The wiki has done a lot to fill some of
the need (a need we see regularly on the #vim IRC channel), but having
tighter integration with the main site would be far better, without
overwhelming the wiki. That's not going to happen unless people like
Marc can easily and readily provide help where they can.

Tom

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

RE: vim sf page ratings and feedback feature

MarcWeber
In reply to this post by JohnBeckett
We should start a wiki page containing a website wish list.
We can put up a summary of changes there.

Bram: I'm totally fine with sending you diffs.

If nobody else does I'll create this wiki page within 24h

Marc Weber

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

vim sf wishlist

MarcWeber
Done. If you have further suggestions reply to this thread or add them
to this wiki page yourself.
http://vim.wikia.com/index.php?title=Vim_Homepage_Wishlist&action=edit

I also suggested removing the negative rating feature. Maybe its
misused. If people don't like a plugin they should add comments telling
why.

Also have a look at a new idea e) It may or it may not take off.
I think there are that many people using vim that this could actually
make sense..

  e) I'd like to see Vim making more progress. Thanks to Bram for having
  added completion features.  However there is more which could be done.
  What's the problem? Vim is complex. Many configuration options, many
  guis. So it's hard to test.  You need some time getting started. Most
  people just want to get done their job. So it's hard to get started in
  Vim development. So what about adding a page to the homepage where
  everyone can add a feature request and say he'd pay $ x for it. Someone
  else might join and say he'd pay $ y for it. Then a third person steps
  up and says: Hey. I'd take the money and implement it (maybe a fraction
  can be given to Uganda?). Than a Vim developer can have an (probably
  small ?) income and many people can benefit. Such a feature wish list
  could look like:

  feature            | description                            | sum of $ which people are willing
                     |                                        | to spend on developing a feature
  -------------------------------------------------------------------------------------------------
  async communication| find a way to talk to external apps.   |  $100 (3 people)
                     | This will make implementing debuggers  |
                     | and the like feasable                  |
  -------------------------------------------------------------------------------------------------
  on the fly         |  make scripting languages provide      |
  type checking      |  the error list                        |
  -------------------------------------------------------------------------------------------------
  on :e! don't loose |                                        |
   history           |                                        |

Does a simple buildfarm exists which builds Vim in various configuration
options doing some sanity checks?

Marc Weber

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Ingo Karkat
In reply to this post by Bram Moolenaar
On 10-Feb-2010 15:47, Bram Moolenaar wrote:
> Ingo Karkat wrote:
>> So, I would propose putting the vim.org's source code (not the actual
>> user database and scripts!) into a (Mercurial?) repository (separate
>> from Vim's source code).
>
> This would also make the site vunerable for hackers.  I don't know
> enough PHP to locate possible holes and opening it up won't fix that.
> I rather not do this.  Having only a few maintainers looking at the code
> is better.

PHP is very common; there are many Vim users with a lot of PHP knowledge out
there. The vim.org site isn't very complex; I guess one or two capable
contributors would be able to quickly review and fix any security issues. I
certainly would (but I'm afraid my PHP isn't any better than yours), just out of
gratitude for Vim and the great community.

Leaving aside the whole "security by obscurity" topic, I'd venture that the
tech-savvy vim.org community isn't a prime target for hackers, so IMO it's worth
a risk. As you can see from the replies to this thread, the current site is
minimal and okay, but there are many ideas for improvements out there. In the
past years, many open source projects have really lifted the bar for community
sites...

-- regards, ingo

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

MarcWeber
Excerpts from Ingo Karkat's message of Thu Feb 11 07:32:53 +0100 2010:

> On 10-Feb-2010 15:47, Bram Moolenaar wrote:
> > Ingo Karkat wrote:
> >> So, I would propose putting the vim.org's source code (not the actual
> >> user database and scripts!) into a (Mercurial?) repository (separate
> >> from Vim's source code).
> >
> > This would also make the site vunerable for hackers.  I don't know
> > enough PHP to locate possible holes and opening it up won't fix that.
> > I rather not do this.  Having only a few maintainers looking at the code
> > is better.
>
> PHP is very common; there are many Vim users with a lot of PHP knowledge out
> there. The vim.org site isn't very complex; I guess one or two capable
> contributors would be able to quickly review and fix any security issues. I
> certainly would (but I'm afraid my PHP isn't any better than yours), just out of
> gratitude for Vim and the great community.
>
> Leaving aside the whole "security by obscurity" topic, I'd venture that the
> tech-savvy vim.org community isn't a prime target for hackers, so IMO it's worth
> a risk. As you can see from the replies to this thread, the current site is
> minimal and okay, but there are many ideas for improvements out there. In the
> past years, many open source projects have really lifted the bar for community
> sites...

I don't think it's a problem. Bram said he will forward sources to
interested people. I just said he won't forward it to everyone. I don't
think this is limiting us. We have to know how the "new" (?) site should
look like. So let's discuss new features or changes rather than the how
to do it. Bram replied and he's listening. So I'm sure we'll find a way
to achieve the goals. We have to define those.

Marc Weber

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Ben Schmidt
On 12/02/10 3:34 AM, Marc Weber wrote:

> Excerpts from Ingo Karkat's message of Thu Feb 11 07:32:53 +0100 2010:
>> On 10-Feb-2010 15:47, Bram Moolenaar wrote:
>>> Ingo Karkat wrote:
>>>> So, I would propose putting the vim.org's source code (not the actual
>>>> user database and scripts!) into a (Mercurial?) repository (separate
>>>> from Vim's source code).
>>>
>>> This would also make the site vunerable for hackers.  I don't know
>>> enough PHP to locate possible holes and opening it up won't fix that.
>>> I rather not do this.  Having only a few maintainers looking at the code
>>> is better.
>>
>> PHP is very common; there are many Vim users with a lot of PHP
>> knowledge out there. The vim.org site isn't very complex; I guess one
>> or two capable contributors would be able to quickly review and fix
>> any security issues. I certainly would (but I'm afraid my PHP isn't
>> any better than yours), just out of gratitude for Vim and the great
>> community.

My PHP is pretty good; MySQL also, though old-fashioned. If I can be of
assistance looking over code, or helping with development for a better
site, I'd be more than happy to.

I agree with Bram and Marc that having a few interested people looking
at the site code rather than making it public is fine. We're a pretty
tech-savvy community, but that doesn't mean everybody has time to devote
to fixing security holes, particularly not with the sort of notice you
get with a hacker attack!

Ben.




--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

Benjamin Fritz
In reply to this post by JohnBeckett


On Feb 10, 12:44 am, "John Beckett" <[hidden email]> wrote:
> Yes, we could request a namespace specifically for discussion of
> vim.org scripts. However, while the problem with vim.org/scripts
> is real, I do not want a bunch of extra pages dumped on the wiki
> because such pages:
> - overwhelm people looking for basic information
> - become obsolete as once-enthusiastic authors move on
> - have to be maintained by me and Ben Fritz
>

John's been a busy bee and got a new namespace on the wiki for script
comments, a policy page for it, and a nifty template for each script
page providing a disclaimer and brief instructions, along with the
script name and a link back to vim.org.

Check it out:

http://vim.wikia.com/wiki/Vim_Tips_Wiki:Script_comment_guidelines
http://vim.wikia.com/wiki/Script:1234

Bram, I'm not sure if John emailed you privately, but if you'd change
the link to the wiki on vim.org pages from Script-1234 to Script:1234,
I think that's all that you need change.

Comments are, of course, welcome.

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf page ratings and feedback feature

MarcWeber
Excerpts from Ben Fritz's message of Sat Feb 13 19:16:42 +0100 2010:

>
> On Feb 10, 12:44 am, "John Beckett" <[hidden email]> wrote:
> > Yes, we could request a namespace specifically for discussion of
> > vim.org scripts. However, while the problem with vim.org/scripts
> > is real, I do not want a bunch of extra pages dumped on the wiki
> > because such pages:
> > - overwhelm people looking for basic information
> > - become obsolete as once-enthusiastic authors move on
> > - have to be maintained by me and Ben Fritz
> >
>
> John's been a busy bee and got a new namespace on the wiki for script
> comments, a policy page for it, and a nifty template for each script
> page providing a disclaimer and brief instructions, along with the
> script name and a link back to vim.org.
>
> Check it out:
>
> http://vim.wikia.com/wiki/Vim_Tips_Wiki:Script_comment_guidelines
> http://vim.wikia.com/wiki/Script:1234
>
> Bram, I'm not sure if John emailed you privately, but if you'd change
> the link to the wiki on vim.org pages from Script-1234 to Script:1234,
> I think that's all that you need change.

Looks great. However I'd move the Wiki link near the rating. And I'd
still remove negative ratings. Scripts which are awesome will have a
high rating anyway and you're interested in them.

Is there a way to add the wiki frame to the vim sf script page?
If some people don't like it we can add an option to hide it (based on
cookies).

Marc Weber

--
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: vim sf wishlist

Tony Mechelynck
In reply to this post by MarcWeber
On 11/02/10 01:23, Marc Weber wrote:
[...]
> Does a simple buildfarm exists which builds Vim in various configuration
> options doing some sanity checks?
>
> Marc Weber
>

It's easy to construct one, but only on Unix-like systems, including
Unix-like Cygwin and (IIUC) Mac OS X. Not on native-Windows AFAIK,
because the configure script doesn't run on that platform. I guess you
(Marc) know the following but I'm spelling it out for anyone interested:

0) Get the source.
1) Make as many "shadow" subdirectories of src/ as you want different
configurations, using "make shadow" with src/Makefile; after each pass,
rename src/shadow (or comment away the Makefile line "SHADOWDIR =
shadow" and define SHADOWDIR differently yourself for each run of "make
shadow").
2) Construct shell include scripts (let's call them
src/$SHADOWDIR/config.sh) similar to the one near the top of my howto
page http://users/.skynet.be/antoine.mechelynck/vim/compunix.htm , one
per configuration with the desired settings.
-- For some particularly "unusual" configurations, you may have to break
the softlink for feature.h and comment or uncomment some of its lines
differently in different shadowdirs.
3) In each shadowdir:
        source config.sh
        make && make test

Notes:

* Run the above in a different shell for each shadowdir to avoid stray
environment variables carrying over from one run to the next. You may
run them in parallel if you want (and if your machine has the resources
to make it useful).

* config.sh must be sourced, not run, because its purpose is to modify
the environment: it must NOT be run in a subshell.

* "make" runs configure implicitly if auto/config.cache doesn't exist;
if you changed the config.sh or the installed software, use "make
reconfig" instead (or precede "make" by rm -vf auto/config.cache or by
make distclean) to force a configure pass followed by a full compile.

* "make test" is supposed to run a number of post-compile sanity checks
on the newly produced executable. I haven't tried it yet. Pre-compile
sanity checks (on your software environment and configuration settings)
are done by configure.


Best regards,
Tony.
--
TALL KNIGHT: We shall say Ni! again to you if you do not appease us.
ARTHUR:      All right!  What do you want?
TALL KNIGHT: We want ... a shrubbery!
                  "Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD

--
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

To unsubscribe, reply using "remove me" as the subject.