I think Matthew's argumentation is well thought out, clear and valid. I don't use variable tabs myself but I can empathize with those who do. I remember that floating-point functions were at first a crippled set, and it took some time (a year? two? more?) to convince Bram that the full set (which was available in the meantime as a "third party patch") was worth including (and would add only ridiculously little executable bloat). IMHO the time is ripe for making variable tab stops a "standard" part of Vim, even though it is a feature which I do not use myself.
In order to decide whether or not it is actually "a small thing" in terms of executable bloat I would like to see figures: let's say the size of two Huge executables for the same OS, word size (32/64) and GUI, differing only in inclusion or not of the variable-tabs feature. (I assume that that feature, if and when part of "standard" Vim, would be "ifdeffable" at compile time, via configure on the OSes where configure is used; and this means that it would routinely be ifdeffed-out in Tiny builds.) Best regards, Tony. On Sun, Mar 11, 2018 at 10:36 PM, Matthew Winn <v...@matthewwinn.me.uk> wrote: > 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. > > 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. > > 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? > > -- > 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.
