2018-03-13 2:11 GMT+03:00 tooth pik <[email protected]>: > 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
I fail to see how this your suggestion is different from cleverly remapped `<Tab>`. Doubt they really will though, plugins which make aligning with spaces easier exist for a hell lot of time, you don’t really benefit from variable tabstops unless you do have tab stops. > > 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. -- -- 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.
