On Jul 15, 2013 3:02 AM, "Lech Lorens" <[email protected]> wrote:
>
> On 14-Jul-2013 Bram Moolenaar <[email protected]> wrote:
> >
> > Ken Takata wrote:
> >
> > > When I run the test 98 with gvim, it stops at the last line of
test98a.in.
> > >
> > > > call feedkeys(":setl scb\n\<C-w>\<C-w>", 't')
> > >
> > > It seems that feedkeys() works different on CUI and GUI.
> > > I don't know why the difference occurs, but using feedkeys()
> > > is not necessary for this test. I think using "setl scb" and
> > > "wincmd w" is enough.
> > > Please check the attached patch.
> >
> > Thanks.  I also have no clue why feedkeys() was used here.
>
> Ken: sorry for including you here, even thought only a tiny bit is
> a reply for you.
>
> I have been thinking about writing this email for at least a year now.
> This patch is the straw that breaks the camel's back, so here it comes.
>
> feedkeys() is essential there.
> Try re-running the test without the fix that was introduced along with
> the test. Magic: the test succeeds even without the fix!
> It took 9 days for the fix to be accepted for inclusion because you,
> Bram, asked for a working test (one that would fail without the fix).
> Now it takes 40 minutes (!!!) to have a patch included that breaks the
> test and makes all my effort (I wrote how I needed to use gdb to come up
> with a method that would reproduce the problem in a script) go to
> a waste.
>
> I know, my bad for not putting in a comment, but the patches are
> micromanaged to the point that the name of the file test96extra.in gets
> renamed to test98a.in yet the very point of tests gets lost after only
> 4 days (!!!) since inclusion! That's less time than it took me to
> prepare the bloody test!
>
> Bram, don't get offended, I actually do hope that one day I will become as
> competent a programmer as you are, but still I think Vim's development
> process is severely broken:
> - the single point of failure (Bram),
> - how the decision what gets included is made with the community totally
>   oblivious,
> - we don't have a development branch of Vim because we want stability.
>   Therefore the unaware users are without a single warning presented
>   with 7.3.970 which breaks half of syntax scripts, makes the rest 10
>   times slower, breaks regular expressions and introduces random
>   crashes. Only after a number of patches and becoming stable is the
>   only branch renamed to 7.4 alpha!
> - we manage patches as files (as opposed to the distributed VCS way:
>   pull requests) because it allegedly "just works". Yet there was
>   a spell of a few weeks where every single week there was at least one
>   patch which was either applied twice, applied only partly or applied
>   to a wrong part of code. How can it "just work" if it so obviously
>   doesn't work?

Just in case somebody missed previous threads on the similar topic:
- https://groups.google.com/forum/m/#!topic/vim_dev/OlkOgDEDAq0
- https://groups.google.com/forum/m/#!topic/vim_dev/hAg_60fEdvM
- https://groups.google.com/forum/m/#!topic/vim_dev/78RMC7ajGfE

> All this means that a lot of effort of developers goes to a waste:
> - because Bram can't (how could he possibly? He's a man: he needs to
>   eat, to sleep and to rest) evaluate all the possible patches and they
>   are added to the mythical todo.txt which means their changes of
>   getting included drop to almost 0,
> - even though a patch got to todo.txt (and therefore will not be
>   included) people still work on it because they believe it will,
> - people prepare a patch to fix something, a fix is published but the
>   solution has been totally rewritten; not a single word of explanation
>   is given,
> - people prepare a patch, it gets included but for some reason the bug
>   doesn't go away. I recently had to re-debug Vim after my fix got
>   included only to discover that a line from my patch was not included.
>   The funny thing was that I did include a test and this single stable
>   branch of Vim was published with a failing test.
>
> For some reason how people waste their time is OK because they volunteer
> to waste their time, they are the guilty ones. But it also means that
> Bram's time gets wasted:
> - he needs to update todo.txt,
> - he won't explain what was wrong with a patch so people will submit
>   those incorrect patches which Bram will have to rewrite,
> - he needs to fix the problems with the mis-applied patches.
>
> I used the pronoun "we" to mean "community" but the sorry state of Vim
> development community is that IT DOES NOT EXIST. "Community" implies
> a N-to-M relation between its members where N,M > 1. Here it's
> a one-to-many relation between Bram and multiple patch submitters
> because Bram has to evaluate every single patch. This means there's very
> little incentive to examine each other's work (I will check your patch,
> this way you will be more likely to check mine). That's why these
> I-would-appreciate-it-if-some-people-tried-it-out emails from Bram get
> so little response (and because people know that their work might go to
> a waste). People work to scratch their own itches; there's no point in
> scratching the itches of others.
>
> I could write more but I think there's no point – this already got quite
> long. I believe these things drive people away from Vim development or
> make them one-time contributors. There used to be a nice small community
> of contributors to vim-extended. We produced a number of stable, well
> tested (we – as in more than an I – used them on daily basis!) features,
> most of which got abandoned (because there was no change of them going
> into mainline Vim. Instead the (still buggy) conceal feature got
> included because someone convinced Bram it would be nice to be able turn
> a text editor into e.g. a web browser. Some bugs simply got renamed as
> features and everyone's happy.
>
> I don't know why I'm writing this. I don't hope this email will change
> anything. I *AM SORRY* and perhaps I believe that sharing will somehow
> help me. I am a contributor of around 50-100 patches to Vim, I've been
> here for 5 years and I don't feel I'm being taken seriously. I know
> there are many others that will come and replace me, people whose work
> could replace what I have done (I have seen one of the issues in
> todo.txt solved 3 times before it got removed from todo.txt) but this
> doesn't make it any less wrong. I don't deserve it. And I don't deserve
> to have this email ignored.
>
> Lech Lorens
>
> --
> --
> 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
>
> ---
> You received this message because you are subscribed to the Google Groups
"vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

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

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


Raspunde prin e-mail lui