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