On 10/6/07, Matthew Winn <[EMAIL PROTECTED]> wrote:
>
> On Sat, 6 Oct 2007 10:22:53 +0200, "Yakov Lerner" <[EMAIL PROTECTED]>
> wrote:
>
> > On 10/5/07, Matthew Winn <[EMAIL PROTECTED]> wrote:
> > >
> > > I've been working on an implementation of the non-uniform tabstops
> > > that were discussed about a month ago, and I have a patch ready for
> > > trying out. I've done some testing on Linux and Windows XP; the parts
> > > I'm able to test seem to be OK and on Linux it survives "make test"
> > > cleanly, but I need people to try it out on other systems and test
> > > the parts I can't reach.
> > >
> > > With this patch the set tabstop, set softtabstop and retab commands
> > > take a comma-separated list of tab widths (as in ":set ts=4,20,8" or
> > > ":retab 20,4").
> >
> > You changed the option type from numeric to string, right ?
> >
> > I believe this breaks some backward-compatibility:
> > 1) The old code rightly expected &ts to be proper number and did
> > arithmetics on it; this gets broken.
> > 2) Also, if old code had things like 'set ts+=3', 'set ts-=3', it gets
> > broken, too.
>
> :set ts=5,7 ts+=3 ts?
> tabstop=5,73
>
> Not a very useful ability.
Wrong. On a comma-separated string option, += normally
adds the implied/needed comma.
Try this:
:set ve= ve+=block ve+=insert ve?
virtualedit=block,insert
Notice how += adds the comma ?
Your example above is not how += usually behaves on the
comma-separated string options.
On the comma-separated string option, your example
should look like this:
:set option=5,7 option+=3 option?
option=5,3,7
, not 5,37.
Then it sort of starts making sense, no ?
Yakov
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
