2018-03-12 0:36 GMT+03:00 Matthew Winn <v...@matthewwinn.me.uk>:
> On 11/03/18 15:04, Bram Moolenaar wrote:
>>
>> 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.
>
>
> But it is a small thing to include. Vim already includes code that is called
> when a tab needs to be displayed and works out how many columns need to be
> skipped to get to the next multiple of the tabstop setting. From what I
> remember all the variable tabs change does is check to see if the new
> setting has been set and if so it looks up how many columns to skip instead
> of calculating it. It's really not that complicated, and it has the
> advantage that if the new setting isn't set then the only line of new code
> that is called is the one that checks whether the setting is used. If not
> then only the existing code runs, which means that anyone who doesn't use
> the new setting has no chance of seeing any alteration in behaviour.
>
> The only slightly iffy thing about it is that it doesn't play well with the
> linebreak setting, but that's a known issue with the current tab
> implementation as well.
>
> If Vim was in some sort of feature freeze state where it was considered to
> be complete for all time and no changes apart from bug fixes would ever be
> made then I could understand your reluctance to add this, but you've been
> perfectly willing to add far larger and far more disruptive changes to Vim
> even when there's been no user-driven request for them at all. Why is this
> one such a big problem?
>
>> 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.
>
>
> You can tell what sorts of functions people are likely to find useful by
> looking at the sort of tasks people are likely to do. Very few people are
> likely to want a terminal emulator built into an editor because they already
> have ways to get at command lines outside the editor. They may certainly
> make use of the feature once it's there, but there are very few tasks that
> they couldn't do in an external command line that they can now do inside a
> Vim terminal window. Very few people are likely to want interprocess
> communication because it's not the sort of function people would even expect
> an editor to have.

Many people use Vim as an IDE, and IDE *is* expected to have some kind
of asynchronous communication with external processes: IDE frozen
because it runs even a compilation triggered by user would upset that
user, not to mention the idea of running compilation on file save, to
get the errors if nothing else, is simply impossible on any large
project without upsetting user further or using some kind of
asynchronous communications. And there are more tasks like linting or
running static analyzer, or running related unit tests, … I am far
from thinking that Vim users do not understand what asynchronous IPC
is needed for, even if they would never use it directly and not via
plugins.

Also `system()` and `:{range}!` existed in Vim for years and served
well for many tasks, and that *is* interprocess communication by
definition. Also note that Wikipedia mentions files as one way of
interprocess communication. You do expect editor to be able to edit
files, don’t you?

>
> But editing tabular information is something that a great many people do.
> It's not just a matter of working with tab-separated data files. How often
> do you want to assemble columns of information in a text file where the
> columns are inconvenient sizes? You wrote Vim so I'm sure you use it for all
> sorts of things, and I bet there are times when you've found that spaces are
> annoying for getting the columns aligned while tabs between every column
> waste space and mean you run out of screen. That happens to me a couple of
> times a week, and I doubt my requirements are anything exceptional. That's
> the sort of common real-world situation this change addresses, and right now
> it's something that can't be done in Vim at all. If I want columns of text
> in a reasonable amount of space I need to use a spreadsheet, and then I have
> to keep going through removing all the spurious ks and js and ZZs that
> appear all over the place when I forget which environment I'm in.

Conveniently viewing tab-separated file is one thing, assembling is
entirely another. Who could you share such file except person using
(Neo)Vim with your patch? Spaces are safer and it is not impossible to
write a plugin which makes using them easier (also for viewing if you
can afford (temporary) changing the file). So far I have only seen a
bunch of plugins like tabular which distribute spaces after the fact,
but I never actually looked.

By the way, about “keep going through removing all the spurious …”:
one of the Neovim goals is to make it embeddable into other
applications. So far only to replace the editor area with some control
of the “parent” application from within Neovim, but why not go further
and request separating things enough for the core to be useful for
spreadsheet (and writing corresponding plugin for LO Calc or
whatever)? It is not like variable tabstops would ever allow Vim to
replace spreadsheet applications.

>
> I would bet money that far more people find themselves thinking "I wish Vim
> was better at handling columns of data" than "I wish Vim had better
> interprocess communication" or "I wish Vim had more ways of writing regular
> expressions" or "I wish Vim was programmable in my favourite language".
> Those are developer requirements. Variable tabstops are an end-user feature:
> a basic function that's of use to everyone rather than an advanced addition
> that only experts will care about. Shouldn't end-user features be given
> priority?

Why should they? If you add a feature for plugin developers you get
plugins that benefit from that feature meaning that editor could now
do X. Even if X needs a plugin users still would get that X and it
would not be Bram coding the feature in not-very-developer-friendly C;
additionally this also means that other plugin developers could be
working on Y and Z in parallel. One, of course, needs balance, as
plugins need to be somehow found by users and it is not like many
developers themselves would like a editor which is nothing, but a core
which provides features *only* for developing editor on top of that,
especially given that they know that plugins sometimes conflict.

But “balance” does not means assessing the situation and not giving
end-users or developers priority because of them being end-users or
developers. I do not know why exactly specifically those features were
added, but speaking for myself I find what was recently added more
useful then variable tabstops. (I am more in a developer camp though.)

>
> --
> 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 vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Raspunde prin e-mail lui