nikolay: don't worry about other people being able to see the properly formatted columns
users of this feature will more than likely have 'expandtab' set On Mon, Mar 12, 2018 at 5:06 PM, Nikolay Aleksandrovich Pavlov < [email protected]> wrote: > 2018-03-12 0:36 GMT+03:00 Matthew Winn <[email protected]>: > > 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 [email protected]. > > 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 [email protected]. > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
