Subject: new options for vi
To: None <tech-userlevel@netbsd.org>
From: David Laight <david@l8s.co.uk>
List: tech-userlevel
Date: 06/21/2002 23:00:45
I have been editing a file that has tab separated columns (eg
a spreadsheet dump) and trying to get the screen layout to
look sensible given the length of some of the fields are
rather variable between the records.

The first trick is to increase the tabstop to a large value (in
a wide window).  This works ok for the LHS of the file until
the window reaches 500 columns.

'To avoid core dumps' vi limits the number of lines or columns
to 500.  Now when this was written (1994ish) that probably seemed
a lot more than a screen would ever hold.
Howver a full with window on my monitor (with the font I normally
use) is 262 columns - so 500 isn't really a suitable upper limit.

Removing (ok I replaced it with 4000 [1]) this arbitrary limit
did indeed generate core dumps.
After fixing libcurses to use 1024 column temporary buffers
and libterm to do cursor addressing beyond column 999 I can
now edit files in reasonble large windows (>2k columns).
(bug lib/xxxxx raised)

However with ts=65 the fields are a bit sparse!

It struck me that what you really need is for some of the
tab stops to be ignored.  To do this I've added an option
tabmask=mask where the n'th tab is ignored if 'mask & (1<<n)'.
For the file in question tabmask=0xabfaed is about right.
(I've allowed numeric options to be input in hex...)

While inside vi I've fixed another 'feature' that has been
annoying me.  At some point 'nvi' was modified so that '%'
treats <> as brackets.  Now this is probably fine for
HTML, but a right pain for C source.
(I use c% across things like  pointer->field...(...) quite often)
I've added another option 'matchchars=()[]{}<>' defining the
pairs of characters that % will use.  This lets me remove <>.
I've also coded it so that "" and '' can be included and do
something moderately sensible - again useful for c%)

Is anyone interested in the diffs?

	David

[1] I think all the result from all the malloc() calls are
checked, so maybe this limit isn't needed at all.
(maybe just ensure that lines*columns*sizeof (struct) doesn't
exceed 2^32 so appear to suceed! IIRC lines=columns=16384
will confuse curses)

-- 
David Laight: david@l8s.co.uk