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?
--
Matthew Winn
--
--
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/d/optout.
