Matthew Winn wrote:
> On 09/03/18 10:36, Bram Moolenaar wrote:
> >
> >> would this be a bad time to ask about variable tab stops?
> >
> > Yes, this is the kind of patch that needs time to wrinkle out all the
> > problems.
> > Like other things that change how text is displayed (linebreak, conceal).
> > Also, I anticipate Vim becoming slower. And I think the audience is
> > actually
> > quite small.
>
> As the person who originally wrote that patch, I find your attitude to
> it quite bizarre.
>
> This was an often-requested feature. It was one of the items that
> featured in a poll of "future changes that should be added to Vim" well
> over a decade ago and although it didn't make the top few that were an
> immediate priority for you to work on it still did pretty well, and that
> was the reason why, when I found myself out of work at about the same
> time, I decided to take this idea off Vim's TODO list and work on it
> myself instead of going straight back to job-hunting.
>
> Between learning the internals of Vim, development and waiting for
> feedback from enthusiastic testers I spent several weeks on it, and at
> the time I wrote it there were NO problems. All the issues - and there
> were only ever a couple - were fixed. Completely. I submitted it along
> with a suitable set of tests. And ... nothing.
>
> Eventually my development environment died and someone else took over
> maintenance of the patch, and still nothing.
>
> What makes you think the audience for this is small? People have been
> asking for this for over a decade and it's useful for everyone who needs
> to handle tables of information. What makes you think there will be
> problems with speed and stability? All it does is make a minor change to
> the existing display code to calculate the size of a tab. And even if
> there are problems, you've been perfectly happy to accept features that
> have actually destabilised Vim but have had an audience that is
> vanishingly small: things like a new regex engine or a built-in terminal
> emulator, for example, and how many end users do you think care about
> asynchronous I/O? Features like that are of zero interest to the average
> user of Vim and many have resulted in data-losing crashes but you
> encouraged them anyway. What is it about this particular feature that
> makes you think it's so much more dangerous than anything else?
>
> This is a feature that is of general interest to ALL users, not just the
> people on the vim-dev list who want to push things to the limit. This is
> a feature that affects nothing but the display code, and in the unlikely
> event that it does cause problems those problems can be solved by just
> not using it. It's a far safer change than many of the ones you've
> accepted, so why are you so strongly opposed to adding a useful EDITING
> feature to an EDITOR?
>
> Way back when that poll for future features was conducted you said that
> you'd work on the winning features and other people should feel free to
> pick up any of the others, so that's what I did. You even chipped in
> with suggestions for improvements while I was working on it. Don't you
> think that if you ask people to help implement features that you don't
> have the time to work on yourself you have an obligation to accept
> working patches from people who do exactly as you asked?
First of all, I'm sorry to disappoint you. This patch has been floating
around for a long time and has never made it in. It's not urgent, and
not a small thing to include, with the result I have been postponing it
for a long time.
A few statements needs further discussion though. I have recently been
involved in a product launch, which fortunately had the resources to do
user studies and gather statistics about usage from different kinds of
users. Including doing user surveys that are statistically sound.
What has become very clear is that there is no direct relation between
what comes up in forums and what users really need or want. For bugs
and things that are hard to understand it can work, the more people
complain the more likely it is a real problem.
When it comes to new features or changes in existing features, it can go
in any direction. Some user may loudly express their opinion, and also
get other users to say they also want it. But when asking the average
user, it turns out they won't need it, or even get confused by it.
And in other cases users don't ask for functionality, but when we add it
then lots of users find it very useful.
For Vim we can't do a good user survey. Asking around doesn't get us the
average user but a very skewed group of users. I often encounter Vim
users who never looked at the mailing lists or the Vim website. That we
hear some users ask for functionality is a weak signal only. I do
listen to these signals, but still try to estimate what the real value
of the functionality is. That of course is my personal opinion and
won't ever be perfect. But it did bring Vim where it is now.
--
Bad fashion can discourage normal people from interacting with the engineer
and talking about the cute things their children do.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- b...@moolenaar.net -- 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_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 vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
