Loading ...
Sorry, an error occurred while loading the content.

Re: Vim homepage - improvements I'd like to implement. Comment please

Expand Messages
  • Marc Weber
    ... Yes: VAM is using it to move /foo.vim into syntax,ftplugin or plugin folder. Not all plugins have a proper archive containing a subdir . That s the only
    Message 1 of 20 , Jan 1, 2011
    • 0 Attachment
      Excerpts from Tom Link's message of Sat Jan 01 12:34:39 +0100 2011:
      > > Bram was so kind adding me to the list of contributors to the Vim project which
      > > means that I can propose Vim web page changes by sending Bram patches.
      >
      > Great to hear.
      >
      > >   A:a way to change the script type afterwards (because Bram had to do this manually using SQL)
      >
      > Is the script type of any use at all as long as vim.org's search
      > function doesn't work and we have to use google to search it?
      Yes: VAM is using it to move /foo.vim into syntax,ftplugin or plugin
      folder. Not all plugins have a proper archive containing a "subdir".
      That's the only reason I know about. Whether that usage was
      intentionally I don't know. It seems to work fine in most cases (for
      those where its set wrong I override it)

      > I'd say only one person should be responsible for maintaining the info
      > on vim.org. But there should be a way to transfer that responsibility/
      > maintainership.
      So you're fine with what I proposed (only reply if I got this wrong)

      > >   D:change the voting system this way:
      >
      > If you actually plan to save votes on a per version basis I'd like to
      > suggest to implement some sort of inflation (i.e., loss of value over
      > time). E.g. older versions should IMHO have less weight when
      > calculating the over-all value. This would also solve/attenuate the
      > problem with downvotes for older versions. I think you'd only have to
      > store one value for previous votes + a current one and then let the
      > over-all value be something like curr + prev * 0.8 or so. And maybe
      > multiply all kharma points with 0.8 every year.

      For plugin versions? Bad idea. You can manipulate by doing version bumps
      only (don't think Vim script authors will do so .. but )

      by time? Great idea. Tools change. so 10 year old karma may no longer be
      valid. But we should discuss which would be the best way.

      So for now I'd like to keep the "old" (stupid ?) value unless more
      discussion has taken place.

      Maybe its best to show both.

      > People will insert dummy text.
      You can't protect against that.
      spam? How to detect spam? Things like adding a 1x1 pixel input worked
      fine in one case I know about. If it contains text a spam bot was used.
      Do you think human spammers are a problem?

      > There are tools to monitor page changes.
      All right. So it should be low priority. Polling causes more traffic
      though.

      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
    • ZyX
      Reply to message «Re: Vim homepage - improvements I d like to implement. Comment please», sent 14:52:59 01 January 2011, Saturday ... I suggest combine this
      Message 2 of 20 , Jan 1, 2011
      • 0 Attachment
        Reply to message «Re: Vim homepage - improvements I'd like to implement. Comment
        please»,
        sent 14:52:59 01 January 2011, Saturday
        by Marc Weber:

        > > If you actually plan to save votes on a per version basis I'd like to
        > > suggest to implement some sort of inflation (i.e., loss of value over
        > > time). E.g. older versions should IMHO have less weight when
        > > calculating the over-all value. This would also solve/attenuate the
        > > problem with downvotes for older versions. I think you'd only have to
        > > store one value for previous votes + a current one and then let the
        > > over-all value be something like curr + prev * 0.8 or so. And maybe
        > > multiply all kharma points with 0.8 every year.
        >
        > For plugin versions? Bad idea. You can manipulate by doing version bumps
        > only (don't think Vim script authors will do so .. but )
        >
        > by time? Great idea. Tools change. so 10 year old karma may no longer be
        > valid. But we should discuss which would be the best way.
        >
        > So for now I'd like to keep the "old" (stupid ?) value unless more
        > discussion has taken place.
        I suggest combine this ideas: inflate neither by time nor for plugin updates,
        but inflate for plugin updates if downvoted version is at least one month older
        then new version. Or another suggestion: make an inflate coefficient depend on
        time between plugin updates with 0.8 as a lower limit. Do not inflate anything
        if no new versions were uploaded: I do not see why votes should change just
        because time was changed.
      • Marc Weber
        ... About 20 years ago you almost only wrote assembler. Today you use languages providing more abstractions for most use cases (?). That s why some inflation
        Message 3 of 20 , Jan 1, 2011
        • 0 Attachment
          Excerpts from ZyX's message of Sat Jan 01 13:36:24 +0100 2011:
          > because time was changed.

          About 20 years ago you almost only wrote assembler. Today you use
          languages providing more abstractions for most use cases (?).

          That's why some inflation could be considered being a good thing.
          A lot new technologies / languages were invented. In the end the
          "ranking" is kind of indicator for popularity. And that changes over
          time (?)

          You're free to disagree. What I wrote here is very vague anyway.

          So if something like this was implemented we definitely want it to be a
          "view" on the collected data only.

          Your mail shows that we should discuss this in depth or keep it as is
          using an additional "details" page or such only which I suggested the
          first time?
          Maybe there is no way to get this right.

          Maybe it could be added as experimental feature for sorting search
          results. But in the end you try multiple packages anyway keeping what
          serves you best.

          There is an alternative as well:
          Now that we have (multiple) package managers installing vim scripts
          maybe its a better idea to ask for submitting the list of used packages
          once a year anonymously? (That would be even more convenient for users
          and you'd have the decay of "usage-karma" whenever you call for
          submission again.

          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
        • Tom Link
          ... You suggested to allow multiple people to upload new files. For simplicity, I d rather vote for having only one release manager who manages the info on
          Message 4 of 20 , Jan 1, 2011
          • 0 Attachment
            > > I'd say only one person should be responsible for maintaining the info
            > > on vim.org. But there should be a way to transfer that responsibility/
            > > maintainership.
            >
            > So you're fine with what I proposed (only reply if I got this wrong)

            You suggested to allow multiple people to upload new files. For
            simplicity, I'd rather vote for having only one "release manager" who
            manages the info on vim.org -- mostly because I'd assume that it
            requires fewer changes in the source code. But it probably doesn't
            matter.

            > For plugin versions? Bad idea.

            It was meant as a simplification. Another simple solution would be a
            yearly inflation.

            Regards,
            Tom

            --
            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
          • Tom Link
            ... With time vim has changed too. Many plugins on vim.org with very high ratings were written for vim 6.0 -- i.e. no autoload, no lists, no dictionaries etc.
            Message 5 of 20 , Jan 1, 2011
            • 0 Attachment
              > Do not inflate anything
              > if no new versions were uploaded: I do not see why votes should change just
              > because time was changed.

              With time vim has changed too. Many plugins on vim.org with very high
              ratings were written for vim 6.0 -- i.e. no autoload, no lists, no
              dictionaries etc. However brilliantly written those plugins may be,
              given the limitations of vimscript from back then, I think their
              ratings should be moderately devalued.

              Regards,
              Tom

              --
              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
            • Alan Young
              A: change script type What about allowing multiple types via tags or keywords. Also, as a separate option, allow users to suggest tags they find useful as
              Message 6 of 20 , Jan 1, 2011
              • 0 Attachment
                A: change script type

                What about allowing multiple types via tags or keywords.

                Also, as a separate option, allow users to suggest tags they find
                useful as well.

                B: repository field

                Other pieces of info should be included too. E.g. issues, wiki, etc.

                D: change voting system

                I like StackOverflow's setup. Perhaps something similar to that.

                D1: return list of scripts/archives in JSON format

                I'd like to see other formats supported as well. Also, being able to
                restrict results to certain parameters would be nice.
                --
                Alan Young

                --
                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
              • David Fishburn
                ... I personally find the user comments far more valuable then the PHP docuemenation since they provide code snippets. I would imagine the Vim community could
                Message 7 of 20 , Jan 1, 2011
                • 0 Attachment
                  On 1/1/2011 5:20 AM, Marc Weber wrote:
                  Excerpts from Marc Weber's message of Fri Dec 31 08:44:02 +0100 2010:
                  
                  ...
                  About the PHP.net style comments: Yes, they can be messy. However
                  sometimes they also contain valuable contents (maybe 1 out of 10
                  messages are useful and that could be worth it. In fact we could add a
                  voting system and hide comments which have a very bad voting
                  automatically)
                  
                  
                  I personally find the user comments far more valuable then the PHP docuemenation since they provide code snippets.

                  I would imagine the Vim community could add useful maps and other such HowTos to a particular Vim script.


                  About changing ownership: Bram wants to be very conservative.
                  So maybe this should be manually.
                  I can't even think about a system would make sense to track
                  "orphandness" or the like.
                  A possibilty could be users adding claims such as
                  

                  I am also in this boat, maintaining a script.  The original author no longer uses Vim.  As long as we have collaborators I would be very happy.


                  Dave

                  --
                  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
                • Ben Fritz
                  ... I do not feel strongly either way about this, but the last time I remember a discussion about leaving comments on the vim scripts site, we eventually
                  Message 8 of 20 , Jan 1, 2011
                  • 0 Attachment
                    On Dec 31 2010, 1:44 am, Marc Weber <marco-owe...@...> wrote:
                    >
                    > FUTURE (?)
                    >   PHP docs contain a feature: You can add comments below each documentation page.
                    >   Someone (Bram) already added link to a per script id wiki page. However I feel
                    >   that showing user comments in the same page could be a nice idea (?)
                    >   Do you have a strong opinion on this?
                    >   We should add a note that comments "are not maintained" by script authors.
                    >   We don't want to put an additional burden on them.
                    >
                    >   Maybe there should a way for users to subscribe to comment changes (?)
                    >
                    >   This is not a top priority for me so only comment about this if you
                    >   feel strong about it and if you think I should change something here.
                    >

                    I do not feel strongly either way about this, but the last time I
                    remember a discussion about leaving comments on the vim scripts site,
                    we eventually decided on the dedicated wiki pages for a few reasons:

                    * easy to do, virtually no setup
                    * support from Wikia for maintenance if needed
                    * support from Wikia for spam fighting with decent filters already in
                    place
                    * Bram went ahead and created the link and people started creating
                    pages (becoming the de facto method of choice)

                    I don't want to see a whole bunch of effort put into something that
                    won't give us much more benefit. I especially worry about spam.
                    Although some high-traffic sites can rely on things like voting down
                    bad comments, I doubt vim.org gets that kind of traffic. Spammy
                    contributions and comments were one of the main reasons for moving the
                    tips to wikia back in 2007 or whenever that happened.

                    --
                    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
                  • Ben Fritz
                    ... Great idea, and probably very easy to implement and low risk. Go for it. ... Also a great idea. It would allow users to get the cutting edge version if
                    Message 9 of 20 , Jan 1, 2011
                    • 0 Attachment
                      On Dec 31 2010, 1:44 am, Marc Weber <marco-owe...@...> wrote:
                      > Bram was so kind adding me to the list of contributors to the Vim project which
                      > means that I can propose Vim web page changes by sending Bram patches.
                      > If you have any urgent feature requests its the time to start talking about them.
                      >
                      > I'd like to implement:
                      >
                      >   A:a way to change the script type afterwards (because Bram had to do this manually using SQL)
                      >

                      Great idea, and probably very easy to implement and low risk. Go for
                      it.

                      >   B:a "repository" field. This way you can register a
                      >     git/mercurial/whatsoever repository along with your plugin.
                      >

                      Also a great idea. It would allow users to get the cutting edge
                      version if needed. Maybe don't limit it to a version control field. I
                      know people like Dr. Chip like to host script versions on their
                      websites before publishing to vim.org. Also as someone mentions, a
                      "bug tracker" field could be useful as well.

                      >   C:an opt-in collaboration feature: You can add other users as collaborators to
                      >     your scripts which means that they can change the description and upload new
                      >     versions as well (This is similar to what can be done on github)
                      >
                      >     I'm not sure whether a collaborator should be able to add/drop other
                      >     collaborators.
                      >

                      I like this, but I don't think all collaborators should be able to add/
                      drop other collaborators. Maybe you could give two levels of access,
                      not just one, but that would be harder. Another possibility would be
                      all collaborators need to agree with the addition/removal of another
                      collaborator (except for the person being removed, obviously).

                      >     There was a request on the mailinglist for transfering
                      >     maintainership to someone else. If this should be possible a
                      >     collaborator should be able to add drop collaborators?
                      >
                      >     I think yes because you have to trust collaborators anyway.
                      >
                      >   D:change the voting system this way:
                      >
                      >     1) votings should be tight to a specific versions. If a plugin fixed bugs
                      >        there is no reason why bad ratings of version 0.0 should still affect the
                      >       latest version ( which might be 10.0 )
                      >
                      >       Because you can delete specific version archives later there may be votings
                      >       for versions which can longe be downloaded
                      >
                      >       I'm not sure which voting to show by default. Maybe the current figures
                      >       should be kept but an optional "detailed" few should be added?

                      I like the idea of starting voting over on a new version, though
                      obviously it would be open to abuse. Maybe showing the voting of the
                      version next to the entry in the history would limit the abuse. Show
                      the most recent vote tally, or a weighted average of all the versions
                      (newer versions weighted higher).

                      >
                      >     2) force users to give a reason if they vote something down. This will be
                      >        kind of dialog and it'll help devs to understand user requirements
                      >

                      I don't like this. Maybe highly encourage it but don't force it or it
                      will discourage legitimate negative votes. The voting is really meant
                      for people considering trying out the script, not for the script
                      author.

                      --
                      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
                    • Bram Moolenaar
                      ... More general: a link to where the plugin is maintained. Could be a sourceforge or Google code project. There you can have a bugtracker and everything.
                      Message 10 of 20 , Jan 4, 2011
                      • 0 Attachment
                        Marc Weber wrote:

                        > Bram was so kind adding me to the list of contributors to the Vim
                        > project which means that I can propose Vim web page changes by sending
                        > Bram patches. If you have any urgent feature requests its the time to
                        > start talking about them.
                        >
                        > I'd like to implement:
                        >
                        > A:a way to change the script type afterwards (because Bram had to do this manually using SQL)
                        >
                        >
                        > B:a "repository" field. This way you can register a
                        > git/mercurial/whatsoever repository along with your plugin.

                        More general: a link to where the plugin is maintained. Could be a
                        sourceforge or Google code project. There you can have a bugtracker and
                        everything.

                        > C:an opt-in collaboration feature: You can add other users as collaborators to
                        > your scripts which means that they can change the description and upload new
                        > versions as well (This is similar to what can be done on github)
                        >
                        > I'm not sure whether a collaborator should be able to add/drop other
                        > collaborators.
                        >
                        > There was a request on the mailinglist for transfering
                        > maintainership to someone else. If this should be possible a
                        > collaborator should be able to add drop collaborators?
                        >
                        > I think yes because you have to trust collaborators anyway.
                        >
                        >
                        > D:change the voting system this way:
                        >
                        > 1) votings should be tight to a specific versions. If a plugin fixed bugs
                        > there is no reason why bad ratings of version 0.0 should still affect the
                        > latest version ( which might be 10.0 )
                        >
                        > Because you can delete specific version archives later there may be votings
                        > for versions which can longe be downloaded
                        >
                        > I'm not sure which voting to show by default. Maybe the current figures
                        > should be kept but an optional "detailed" few should be added?
                        >
                        > 2) force users to give a reason if they vote something down. This will be
                        > kind of dialog and it'll help devs to understand user requirements

                        We can't allow users to add arbitrary text and especially links. This
                        will soon result in spamming, as what happened with Tips and forced us
                        to take it down.

                        It might be OK if we filter out anything that looks like a URL.

                        > 3) create a new page returning a list of all scripts and achives as JSON format
                        > which can be used by tools like vim-addon-manager or similar.
                        >
                        > FUTURE (?)
                        > PHP docs contain a feature: You can add comments below each documentation page.
                        > Someone (Bram) already added link to a per script id wiki page. However I feel
                        > that showing user comments in the same page could be a nice idea (?)
                        > Do you have a strong opinion on this?
                        > We should add a note that comments "are not maintained" by script authors.
                        > We don't want to put an additional burden on them.

                        Like above, spamming may become a problem. That's why there is a link
                        to the tips page.

                        > Maybe there should a way for users to subscribe to comment changes (?)
                        >
                        > This is not a top priority for me so only comment about this if you
                        > feel strong about it and if you think I should change something here.
                        >
                        > Provide feedback about these ideas, please

                        --
                        hundred-and-one symptoms of being an internet addict:
                        79. All of your most erotic dreams have a scrollbar at the right side.

                        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                        /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                        \\\ an exciting new programming language -- http://www.Zimbu.org ///
                        \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                        --
                        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
                      • Bram Moolenaar
                        ... Instead of actually deleting it, we can mark scripts as deprecated . Like with version control, it s often good to never throw anything away. ... -- You
                        Message 11 of 20 , Jan 4, 2011
                        • 0 Attachment
                          Jeet Sukumaran wrote:

                          > I think the ability to delete a script (or, at least, its listing/
                          > publishing) would be quite desirable. Unless there is a technical or
                          > theoretical (design) reason for it not being there now?

                          Instead of actually deleting it, we can mark scripts as "deprecated".
                          Like with version control, it's often good to never throw anything away.

                          > Comments would be great, but without moderation and maintenance of any
                          > sort, it may quickly become messy and ugly.
                          >
                          >
                          >
                          > On Dec 31 2010, 3:44=A0pm, Marc Weber <marco-owe...@...> wrote:
                          > > Bram was so kind adding me to the list of contributors to the Vim project=
                          > which
                          > > means that I can propose Vim web page changes by sending Bram patches.
                          > > If you have any urgent feature requests its the time to start talking abo=
                          > ut them.
                          > >
                          > > I'd like to implement:
                          > >
                          > > =A0 A:a way to change the script type afterwards (because Bram had to do =
                          > this manually using SQL)
                          > >
                          > > =A0 B:a "repository" field. This way you can register a
                          > > =A0 =A0 git/mercurial/whatsoever repository along with your plugin.
                          > >
                          > > =A0 C:an opt-in collaboration feature: You can add other users as collabo=
                          > rators to
                          > > =A0 =A0 your scripts which means that they can change the description and=
                          > upload new
                          > > =A0 =A0 versions as well (This is similar to what can be done on github)
                          > >
                          > > =A0 =A0 I'm not sure whether a collaborator should be able to add/drop ot=
                          > her
                          > > =A0 =A0 collaborators.
                          > >
                          > > =A0 =A0 There was a request on the mailinglist for transfering
                          > > =A0 =A0 maintainership to someone else. If this should be possible a
                          > > =A0 =A0 collaborator should be able to add drop collaborators?
                          > >
                          > > =A0 =A0 I think yes because you have to trust collaborators anyway.
                          > >
                          > > =A0 D:change the voting system this way:
                          > >
                          > > =A0 =A0 1) votings should be tight to a specific versions. If a plugin fi=
                          > xed bugs
                          > > =A0 =A0 =A0 =A0there is no reason why bad ratings of version 0.0 should s=
                          > till affect the
                          > > =A0 =A0 =A0 latest version ( which might be 10.0 )
                          > >
                          > > =A0 =A0 =A0 Because you can delete specific version archives later there =
                          > may be votings
                          > > =A0 =A0 =A0 for versions which can longe be downloaded
                          > >
                          > > =A0 =A0 =A0 I'm not sure which voting to show by default. Maybe the curre=
                          > nt figures
                          > > =A0 =A0 =A0 should be kept but an optional "detailed" few should be added=
                          > ?
                          > >
                          > > =A0 =A0 2) force users to give a reason if they vote something down. This=
                          > will be
                          > > =A0 =A0 =A0 =A0kind of dialog and it'll help devs to understand user requ=
                          > irements
                          > >
                          > > =A0 =A0 3) create a new page returning a list of all scripts and achives =
                          > as JSON format
                          > > =A0 =A0 =A0 which can be used by tools like vim-addon-manager or similar.
                          > >
                          > > FUTURE (?)
                          > > =A0 PHP docs contain a feature: You can add comments below each documenta=
                          > tion page.
                          > > =A0 Someone (Bram) already added link to a per script id wiki page. Howev=
                          > er I feel
                          > > =A0 that showing user comments in the same page could be a nice idea (?)
                          > > =A0 Do you have a strong opinion on this?
                          > > =A0 We should add a note that comments "are not maintained" by script aut=
                          > hors.
                          > > =A0 We don't want to put an additional burden on them.
                          > >
                          > > =A0 Maybe there should a way for users to subscribe to comment changes (?=
                          > )
                          > >
                          > > =A0 This is not a top priority for me so only comment about this if you
                          > > =A0 feel strong about it and if you think I should change something here.
                          > >
                          > > Provide feedback about these ideas, please
                          > >
                          > > Marc Weber
                          >
                          > --=20
                          > 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 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
                        • Bram Moolenaar
                          ... I don t think it s possible to send mail. Unless sourceforge has re-enabled this. It stopped working a couple of years ago. ... Please don t start yet
                          Message 12 of 20 , Jan 4, 2011
                          • 0 Attachment
                            Marc Weber wrote:

                            > Excerpts from Marc Weber's message of Fri Dec 31 08:44:02 +0100 2010:
                            >
                            > E) new password request the way its known by other sites:
                            > - receive mail
                            > - click link
                            > - reset password

                            I don't think it's possible to send mail. Unless sourceforge has
                            re-enabled this. It stopped working a couple of years ago.

                            > F) add a way to change a password
                            >
                            > G) hide script (we don't have to delete it)?
                            > only maintainers / authors should be able to hide a script
                            >
                            > E) bug tracking system or url field?
                            > It should be KISS simple: You have to have an account.
                            > states: open, closed
                            >
                            > actions:
                            > - create
                            > - close
                            > - add comment

                            Please don't start yet another bug tracking system. There are plenty
                            around.

                            > Usually a site such as www.vim.org should not be abused to reinvent the
                            > wheel. However most Vim scripts are very small and not all are hosted on
                            > github or the like (?)
                            >
                            > About the "reasons" of downvoting: Of course they should be visible to
                            > everyone. Maybe maintainers should be able to add comments so that you
                            > can correct false claims.
                            >
                            > About the PHP.net style comments: Yes, they can be messy. However
                            > sometimes they also contain valuable contents (maybe 1 out of 10
                            > messages are useful and that could be worth it. In fact we could add a
                            > voting system and hide comments which have a very bad voting
                            > automatically)
                            >
                            > About changing ownership: Bram wants to be very conservative.
                            > So maybe this should be manually.
                            > I can't even think about a system would make sense to track
                            > "orphandness" or the like.
                            > A possibilty could be users adding claims such as
                            >
                            > date |
                            > xxx | tried contacting by mail foo@host but no reply
                            > ....
                            >
                            > However you can see that this is not easy to get right. So for now I'd
                            > like to skip this idea and do it the usual way: Post to the mailinglist
                            > - hope for replies. Its archived so you can look it up later as well.
                            >
                            > Maybe this should be documented (?)

                            --
                            hundred-and-one symptoms of being an internet addict:
                            81. At social functions you introduce your husband as "my domain server."

                            /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                            /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
                            \\\ an exciting new programming language -- http://www.Zimbu.org ///
                            \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

                            --
                            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
                          • Marc Weber
                            ... We could make an HTTP request to an external sever which can send mail. So if we want it we can make it work easily. ... Agreed. Maybe we can setup a
                            Message 13 of 20 , Jan 5, 2011
                            • 0 Attachment
                              Excerpts from Bram Moolenaar's message of Tue Jan 04 14:01:27 +0100 2011:
                              > I don't think it's possible to send mail. Unless sourceforge has
                              > re-enabled this. It stopped working a couple of years ago.

                              We could make an HTTP request to an external sever which can send mail.
                              So if we want it we can make it work easily.

                              > Please don't start yet another bug tracking system. There are plenty
                              > around.
                              Agreed. Maybe we can setup a mantis tracker and create subprojects for
                              each script or such ?

                              We could then add a new field "bug tracker" to each script. If its empty
                              we could default to mantis.

                              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
                            Your message has been successfully submitted and would be delivered to recipients shortly.