Trial patch for variable tabstops
Matthew Winn
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"). Note that these are _widths_, not positions. The final
value is repeated as required. If only one value is used the behaviour
should be the same as with an unpatched Vim.
This change has implications for the ballooneval feature and the
Visual Workshop code (workshop.c), but I haven't been able to test
it because I don't have the necessary environment. The changes relate
to how the number of characters from the start of the line is mapped
on to the screen position, so I'd be grateful if someone who uses the
ballooneval feature can check that this mapping happens correctly
and that it doesn't dump cores all over the place.
The internal changes are as follows:--
The existing p_ts and p_sts global option variables and the buffer
variables b_p_ts and b_p_sts have changed from long to char_u*; the
corresponding options are now strings. Each of the buffer variables
is shadowed by an int[] array b_p_ts_ary and b_p_sts_ary. The zeroth
element of this array is the number of tabstops, and the remaining
elements are the tabstop values. Thus after "set ts=8,20,5" the values
in b_p_ts_ary are:
[0] 3
[1] 8
[2] 20
[3] 5
This internal implementation is handled by a set of functions at the
bottom of option.c. The only detail of the implementation that has
leaked out to the rest of Vim is the int* type of the variables.
This patch is against 7.1.135.
--
Matthew Winn
Yakov Lerner
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").
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.
For preserving backward compatibility, I believe it's better
to introduce new option name (some 'vst' for variable tabstop, or suchlike) than to change the type of existing option.
Yakov
Matthew Winn
wrote:
> On 10/5/07, Matthew Winn <v...@mwinn.powernet.co.uk> 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.
Does anyone actually do that? It doesn't make sense to me that anyone
would do arithmetic on a tabstop. I agree that if anyone does it then
it should behave as before. It just doesn't make sense as something
anyone would do. Still, it makes even less sense now:
:set ts=5,7 ts+=3 ts?
tabstop=5,73
Not a very useful ability.
> For preserving backward compatibility, I believe it's better
> to introduce new option name (some 'vst' for variable tabstop, or suchlike)
> than to change the type of existing option.
I did think about adding another two options (two, because there's sts
as well), but then there's a risk of the sort of problem that already
exists with wrapmargin / textwidth, where if the user isn't aware that
one option is set the other seems to be broken because changes to it
are ignored.
It shouldn't be hard to change, though. I'm also wondering if this is
a big enough change to be worth #ifdef FEAT_??? directives.
--
Matthew Winn
Yakov Lerner
On Sat, 6 Oct 2007 10:22:53 +0200, "Yakov Lerner" <ile...@gmail.com>
wrote:
> On 10/5/07, Matthew Winn < v...@mwinn.powernet.co.uk> 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.
Does anyone actually do that?
It's easy to find out. Just check every vim script in existance ;-)
Yakov
Yakov Lerner
> wrote:
>
> > On 10/5/07, Matthew Winn <v...@mwinn.powernet.co.uk> 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.
>
> 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
Matthew Winn
wrote:
Yes. I'll look into that, although tabstops are different because
they're not unique. If the existing setting is "8,12,8,4,8" and you
do -=8 which 8 should be removed? But appending should certainly work.
I've been thinking about it, and I reckon I can make new options work
reasonably logically with old options. Internally, all the code will
use the new options. Setting ts also sets vts (assuming the new option
is called vts), while setting vts causes ts to be left alone and
ignored until vts is cleared. I did think about setting ts to the
first value of vts, but I couldn't see any reason why the first value
should be preferred over any other, and having the old value of ts
left in place and ignored allows it to be "restored" by unsetting vts.
I'm not entirely sure about "variable" tabstops, as tabstops have
always been variable. The phrase used a month ago was "non-uniform",
but that makes for unwieldy option names. I'll stick with variable
unless some better name comes along.
Thanks for your input.
--
Matthew Winn
Zdenek Sekera
vim...@googlegroups.com for the last (over) 2 days?
If anyone sees this email on the vim-dev, would
you, please, confirm to me directly to my direct
email (below)? Then I at least know it arrived to
vim-dev newsgroup and can start looking for reasons
why am I not getting anything from there.
Thanks and best regards,
---Zdenek
-----------------------------------------------------
Zdenek Sekera | zdenek...@cern.ch
LHC Computing Grid Project | +41 76 487 4971 (mobile)
CERN, IT Department | +41 22 767 1068 (office)
CH-1211, Geneva 23, Switzerland
Zdenek Sekera
to vim_dev. Actually I got it directly also, which
surprised me. The only conclusion should now be
there is actually nothing wrong, just the traffic has
been (and still is) zero or extremely low.
Which is not the habit in this newsgroup.
Well, maybe that's the truth...:-)
---Zdenek
sc
> Thanks to all who replyed that this email got
> to vim_dev. Actually I got it directly also, which
> surprised me. The only conclusion should now be
> there is actually nothing wrong, just the traffic has
> been (and still is) zero or extremely low.
> Which is not the habit in this newsgroup.
Zdenek--
traffic is light but not non-existant -- I have 3 emails dated
Oct 10, 1 dated Oct 9, 4 from Oct 7, etc
when you want to verify you are getting the emails you can
look in googlegroups on google to see the list there
sc
Matthew Winn
feature (FEAT_VARTABS) that is only compiled in for big and huge Vims.
The variable tabstops feature is now set with the vartabstops (vts)
and varsofttabstops (vsts) options. There's also a test script named
test65 (as I think test64 is the highest test so far).
Setting the tabstops and softtabstops options also sets their variable
counterparts, so ":set ts=8" does exactly what you'd expect. You can't
set the old options to lists of values: they're still numeric options.
As before, the new options are set by giving them a comma-separated
list of column widths with the last width applying to all subsequent
tabs.
I've been running with this patch for a week and it seems fine, but
I'd appreciate other opinions, especially about the ballooneval
feature.
--
Matthew Winn
Ben Schmidt
> feature (FEAT_VARTABS) that is only compiled in for big and huge Vims.
> The variable tabstops feature is now set with the vartabstops (vts)
> and varsofttabstops (vsts) options. There's also a test script named
> test65 (as I think test64 is the highest test so far).
I am eager to try this out, and will do so shortly! I think this is a great
improvement on the last patch with different options so backward compatibility
isn't broken etc. I don't use any of the features you mention that you would like
testing on, though.
I hope this can be integrated into the next release of Vim. It would be
tremendously useful.
Stay tuned for any comments I have after I try it!
Ben.
Send instant messages to your online friends http://au.messenger.yahoo.com
Matthew Winn
Thanks.
There's a small problem with the patch as it stands, though it doesn't
affect any functionality. I forgot to wrap the functions at the end of
option.c in an #ifdef, so if someone compiles with the variable width
tabs disabled the functions are still compiled into the binary even
though nothing calls them.
--
Matthew Winn
Mark Waggoner
let extra = 0
if a:0 > 0
let extra = a:1
endif
let i = 1
let tabs = []
while i <= line("$")
let fields = split(getline(i),"\t",1)
let i = i + 1
let f = 0
while f < len(fields)
let l = strlen(fields[f])+1+extra
if (len(tabs) <= f)
call add(tabs,l)
else
if (l > tabs[f])
let tabs[f] = l
endif
endif
let f = f + 1
endwhile
endwhile
execute "set vts=" . join(tabs,",")
endfunction
command! -nargs=? AutoTabs call AutoVariableTabstop(<args>)
Mark Waggoner
On 10/27/07, Matthew Winn < v...@mwinn.powernet.co.uk> wrote:
On Sat, 27 Oct 2007 13:45:46 +1000, Ben Schmidt
< mail_ben...@yahoo.com.au> wrote:
>
> > Here's another version of the variable tabstop patch. I've made it a
> > feature (FEAT_VARTABS) that is only compiled in for big and huge Vims.
> > The variable tabstops feature is now set with the vartabstops (vts)
> > and varsofttabstops (vsts) options. There's also a test script named
> > test65 (as I think test64 is the highest test so far).
>
> I am eager to try this out, and will do so shortly! I think this is a great
> improvement on the last patch with different options so backward compatibility
> isn't broken etc. I don't use any of the features you mention that you would like
> testing on, though.
>
> I hope this can be integrated into the next release of Vim. It would be
> tremendously useful.
>
> Stay tuned for any comments I have after I try it!
Thanks.
There's a small problem with the patch as it stands, though it doesn't
affect any functionality. I forgot to wrap the functions at the end of
option.c in an #ifdef, so if someone compiles with the variable width
tabs disabled the functions are still compiled into the binary even
though nothing calls them.Thanks VERY much for implementing this. I too hope it can be incorporated into the next Vim release. I'll be testing on linux, but can't help with testing on other platforms.Meanwhile.... here's a function/command that makes use of this to automatically figure out "good" tabstops. I don't write vim script very often, so there may be a more efficient way to do this, but it works.
function! AutoVariableTabstop(line1,line2,...)
let extra = 0
if a:0 > 0
let extra = a:1
endif
let tabs = []
while i <= a:line2
let fields = split(getline(i),"\t",1)
let i = i + 1
let f = 0
while f < len(fields)
let l = strlen(fields[f])+1+extra
if (len(tabs) <= f)
call add(tabs,l)
else
if (l > tabs[f])
let tabs[f] = l
endif
endif
let f = f + 1
endwhile
endwhile
execute "set vts=" . join(tabs,",")
endfunction
endif
Mark Waggoner
Matthew Winn
<mark.w...@gmail.com> wrote:
> I just thought I'd update this thread to note that I've been using vim with
> this patch for the last month or so, and have not encountered any problems.
> I can't say that I stress the handling of tabs to an extraordinary degree,
> but in my day to day usage, this has worked fine, and has been helpful when
> viewing and editing files with tab separated data. I'm still hoping that
> this can be considered for inclusion in a not-to-distant future version of
> vim.
Thanks. I tried out your script and it works very well. When I get the
time I'll update the patch to the latest patch of Vim, as my patch is
against 7.1.145.
--
Matthew Winn
Ben Schmidt
I tried it out for the first time editing some real data today, and it made the
job about 1000% times easier. The new feature and the AutoTabs command, which I
now have living in my ~/.vim/plugins folder are both brilliant. Of course, if I
find any anomalies, I will let you know, but so far, so good!
Ben Schmidt
I have found a bug in your variable tabstop patch.
When you do :setlocal ts=something, the global value of vartabstop is changed as
well as the local one, and when you :setglobal ts=something, vartabstop doesn't
change at all. Obviously whatever kind of change you make to ts, the same sort of
change should be made to vts, whether local, global or both. I guess there is
likely the same issue with softtabstop and friend.
Matthew Winn
<mail_ben...@yahoo.com.au> wrote:
> I have found a bug in your variable tabstop patch.
Aw, crap.
> When you do :setlocal ts=something, the global value of vartabstop is changed as
> well as the local one, and when you :setglobal ts=something, vartabstop doesn't
> change at all. Obviously whatever kind of change you make to ts, the same sort of
> change should be made to vts, whether local, global or both. I guess there is
> likely the same issue with softtabstop and friend.
Thanks. I see the same thing. I'll look into it presently.
--
Matthew Winn
Richard Hartmann
> Thanks. I see the same thing. I'll look into it presently.
What's the status of this patch? Does it still work with current Vim?
If yes, Markus, would you be willing to merge this into vim_extended?
Richard
Markus Heidelberg
>
> What's the status of this patch? Does it still work with current Vim?
> If yes, Markus, would you be willing to merge this into vim_extended?
It applied, compiled and worked. But with some bugs, if I've understand
the expected behaviour correctly. Before including it I'd like to ask
whether there is a newer version available.
There are still only few patches integrated in vim_extended. Partly it's
a lack-of-time problem, partly an outdated-patches problem.
Markus
Richard Hartmann
<markus.h...@web.de> wrote:
> It applied, compiled and worked. But with some bugs, if I've understand
> the expected behaviour correctly. Before including it I'd like to ask
> whether there is a newer version available.
Thanks! If we don't hear back, I can try it myself. Perhaps the bugs are,
in fact, intended behaviour.
> There are still only few patches integrated in vim_extended. Partly it's
> a lack-of-time problem
A reason we can understand all to well. Thanks for the time you are
putting into this.
> partly an outdated-patches problem.
Hopefully, this will become better now that there is an easy way and
central place to handle patches.
Richard
PS: The build of relnum, float & code checking patches on current
Vim failed. I need to do some more testing, but I suspect this is
the code checker's fault.
Matthew Winn
<markus.h...@web.de> wrote:
> Richard Hartmann, 06.12.2008:
> >
> > What's the status of this patch? Does it still work with current Vim?
> > If yes, Markus, would you be willing to merge this into vim_extended?
>
> It applied, compiled and worked. But with some bugs, if I've understand
> the expected behaviour correctly. Before including it I'd like to ask
> whether there is a newer version available.
It mostly works, but I'm not happy with the fact that if you set vts
and forget that you've done it then setting ts appears broken because
it doesn't do anything. (I spent quite a long time trying to work out
why I couldn't change the tabstop setting, only to discover that I was
setting vts in my .vimrc for testing and that was overriding ts.)
I should have time to look into it before the end of the year.
--
Matthew Winn
Markus Heidelberg
I just tried it again and it seems I had misunderstood some things. The
tabstops have a fixed position. If a word is longer than the space for
the current tabstop, then this tabstop will be ignored and the next will
be taken.
So if no new version is available at the moment, I can already include
it.
Markus
Richard Hartmann
<markus.h...@web.de> wrote:
> I just tried it again and it seems I had misunderstood some things. The
> tabstops have a fixed position. If a word is longer than the space for
> the current tabstop, then this tabstop will be ignored and the next will
> be taken.
> So if no new version is available at the moment, I can already include
> it.
If it's not too much work and if Matthew OKs the basic workability, I
would be willing to trial the existing patch in my normal build.
Richard
PS: vim_extended is awesome. It really helps getting those patches
more and _persistent_ exposure.
Tony Mechelynck
I don't personally use variable tabs so maybe I'm off-target; but for
some options (such as 'syntax' and 'filetype', not to mention
'compatible') special actions are taken at the exact moment when their
their setting is modified by a ":set" command. Why not say that a ":set
ts=" or ":setlocal ts=", with a value (not ":set ts?" or equivalent)
will, at that instant, set vts to empty in the same range (":set",
":setlocal" or even ":setglobal")? (IIUC, 'ts' is remembered but not
acted upon if 'vts' is nonempty, the way, let's say, 'cindent' is
remembered but not acted upon when 'indentexpr' is nonempty)
Or maybe just say (and document in the help for 'vts', which, as long as
this patch is unofficial, had better be a separate file to be dropped
into $VIM/vimfiles/doc/ and not a patch to $VIMRUNTIME/doc/options.txt
that the next runtime upgrade will undo) that the cases of tabs and
indent are parallel: you had better use ":setlocal" to set 'vts' (or
'indentexpr') and however long they remain nonempty, 'ts' (or
'autoindent', 'cindent' etc.) have no effect in the same buffer(s).
Best regards,
Tony.
--
"The porcupine with the sharpest quills gets stuck on a tree more
often."
Richard Hartmann
<antoine.m...@gmail.com> wrote:
> I don't personally use variable tabs so maybe I'm off-target; but for
> some options (such as 'syntax' and 'filetype', not to mention
> 'compatible') special actions are taken at the exact moment when their
> their setting is modified by a ":set" command. Why not say that a ":set
> ts=" or ":setlocal ts=", with a value (not ":set ts?" or equivalent)
> will, at that instant, set vts to empty in the same range (":set",
> ":setlocal" or even ":setglobal")? (IIUC, 'ts' is remembered but not
> acted upon if 'vts' is nonempty, the way, let's say, 'cindent' is
> remembered but not acted upon when 'indentexpr' is nonempty)
Even better, just unset vts if ts is set and vice versa. Or copy all ts
settings into vts, basically removing the ts functionality.
Richard
Richard Hartmann
<antoine.m...@gmail.com> wrote:
> I don't personally use variable tabs so maybe I'm off-target; but for
> some options (such as 'syntax' and 'filetype', not to mention
> 'compatible') special actions are taken at the exact moment when their
> their setting is modified by a ":set" command. Why not say that a ":set
> ts=" or ":setlocal ts=", with a value (not ":set ts?" or equivalent)
> will, at that instant, set vts to empty in the same range (":set",
> ":setlocal" or even ":setglobal")? (IIUC, 'ts' is remembered but not
> acted upon if 'vts' is nonempty, the way, let's say, 'cindent' is
> remembered but not acted upon when 'indentexpr' is nonempty)
Even better, just unset vts if ts is set and vice versa. Or copy all ts
Markus Heidelberg
That's exactly what the relativenumber feature is doing with 'rnu' and
'nu'.
Ben Schmidt
>
> What's the status of this patch? Does it still work with current Vim?
> If yes, Markus, would you be willing to merge this into vim_extended?
FYI, I always have the patch compiled into all my versions of Vim (GTK,
console, MacVim) and haven't experienced any problems specific to the
patch. But, boy, do I enjoy the functionality of the patch on a regular
basis!
Smiles,
Ben.
Markus Heidelberg
>
> On Mon, Dec 8, 2008 at 08:23, Markus Heidelberg
> <markus.h...@web.de> wrote:
>
> > I just tried it again and it seems I had misunderstood some things. The
> > tabstops have a fixed position. If a word is longer than the space for
> > the current tabstop, then this tabstop will be ignored and the next will
> > be taken.
> > So if no new version is available at the moment, I can already include
> > it.
>
> If it's not too much work and if Matthew OKs the basic workability, I
> would be willing to trial the existing patch in my normal build.
Applied and online.
Now it's time to go to work :)
Markus
Matthew Winn
I did try that but it's trickier than it sounds. 'vts' allocates
memory for a parsed copy of the tabstops, and keeping track of that
memory when setting ts was excessively complicated so I opted for a
simpler "ignore ts if vts is set" strategy instead. I'll take another
look at it because I'm not happy with the counterintuitive way in
which 'ts' suddenly ceases to have any effect when 'vts' is set and
I'd rather the two options cooperated.
--
Matthew Winn
Richard Hartmann
> I did try that but it's trickier than it sounds. 'vts' allocates
> memory for a parsed copy of the tabstops, and keeping track of that
> memory when setting ts was excessively complicated so I opted for a
> simpler "ignore ts if vts is set" strategy instead. I'll take another
> look at it because I'm not happy with the counterintuitive way in
> which 'ts' suddenly ceases to have any effect when 'vts' is set and
> I'd rather the two options cooperated.
Don't you deallocate the memory when vts is unset? In that case,
just run the same code to deallocate when ts is being set.
Richard
Richard Hartmann
<markus.h...@web.de> wrote:
> Applied and online.
> Now it's time to go to work :)
Awesome. I am using it already and I love it!
Matthew: Is it possible to mark anything that does not fit into the existing
vts scheme (i.e. anything which forces you to shift the tabs) as ERROR
so it's highlighted?
Is there a better way to give a visual hint when this is happening?
Also, would a scheme like
set vts=auto[/n[/m]]
make sense? auto would obviously auto-space the tabs, while the
n defines the min spacing after the longest segment and m sets
the maximum length of a cell (a cell being text + tabspace).
Of course, this should be possible, as well:
set vts=10,5,auto
The reason I am not choosing a comma, but something else is that
this should _also_ be possible :p
set vts=10,auto/5,7,auto,10,auto
Also, I want a pony.
Richard