vi vs. nvi

[David Young]

These days, NetBSD is shipping two versions of vi, /usr/bin/vi and
/usr/bin/nvi.  IIUC, the plan is to switch from vi to nvi, after
nvi stabilizes in NetBSD.  In the short term, I am concerned that two
versions of vi are larger than one.  In the long term, I am concerned
that the new vi is much bigger than the old.  On i386:

# ls -l `which nvi`
-r-xr-xr-x  3 root  wheel  466648 Jul 18 16:51 /usr/bin/nvi
# ls -l `which vi`
-r-xr-xr-x  3 root  wheel  286516 Jul 18 16:52 /usr/bin/vi

Since one vi will suffice on most systems, I would like to add a build
option, MKNVI, that defaults to 'yes' (build and install both vi and nvi).
If set to 'no', however, MKNVI stops nvi from being built and installed?
Is that ok, so far?

I am concerned that nvi is too big for embedded applications.  What do
we owe the larger size to?  Compilation options?  New (and essential)
features?  Is there any way to bring the size under control?  I'm asking
for your ideas.

Dave

--
David Young             OJC Technologies
dyoung@...      Urbana, IL * [phone] ext 24

[Greg Troxel]

Back when I was young, we used ed(1).  It and the things it needed from
libc (static of course) fit comfortably in 64K and it worked on ASR-33s.
I would think that's enough for fixing things on embedded systems - it's
how I fix hosed NetBSD systems even today.

> ls -l /bin/ed
-r-xr-xr-x  1 root  wheel  52271 May 12 13:56 /bin/ed

So it would be ok with me to add MKVI too :-)

We could try to cut down on vi/nvi size, too, if anyone is motivated.  I
suspect it's easier to learn ed.

[apb-3]

On Fri, 18 Jul 2008, David Young wrote:
> These days, NetBSD is shipping two versions of vi, /usr/bin/vi and
> /usr/bin/nvi.

That's obviously a mistake.  Whoever accidentally set things up so that
nvi gets installed should just undo it.

--apb (Alan Barrett)

[Havard Eidnes-2]

> > These days, NetBSD is shipping two versions of vi, /usr/bin/vi and
> > /usr/bin/nvi.
>
> That's obviously a mistake.  Whoever accidentally set things up so that
> nvi gets installed should just undo it.

I think the point of installing nvi is to get it tested, without
the risk of breaking "vi" for all users.

The old vi is based on nvi version 1.79.  The new nvi is based on
nvi version 1.81.5.  According to doc/3RDPARTY:

   We have lots of local bug fixes, and the point of importing 1.81.x would
   be to get multibyte characters support. For now this means waiting for
   additions in our libcurses.

Apparently, our curses is now mature enough, so some steps along
this path has been taken.

The configure script of the new nvi appears to have an option to
turn on or off the wide characters support, but it does not
appear that the reach-over Makefile in usr.bin/nvi/build/ runs
configure; rather the configure part currently appears to be done
as a step in the import, ref. nvi2netbsd in dist/nvi/.

Regards,

- Håvard

[apb-3]

On Sat, 19 Jul 2008, Havard Eidnes wrote:
> I think the point of installing nvi is to get it tested, without
> the risk of breaking "vi" for all users.

I thought that the point of putting the new nvi sources in the tree was
to enable testing by people who explicitly chose to test it.  The idea,
as I understood it, was that it would not be installed by default, but
would be easy to install by people who wanted to test it.  Installing
nvi by default was not discussed as far as I know, and it should simply
be treated as an mistake and undone.

Having multiple installed versions of a single program is something that
I would almost always oppose.  No matter how many versions of grep, tar,
or vi source code we have in the source tree, there should be only one
version or grep, tar, and vi in the install tree; except for people who
deliberately choose to install extra versions.

--apb (Alan Barrett)

[Adam Hoka]

Open a file with nvi, go to the first line and hit Shift-O.
Do you see the same bug as me? It works in old vi.

David Young wrote:

> These days, NetBSD is shipping two versions of vi, /usr/bin/vi and
> /usr/bin/nvi.  IIUC, the plan is to switch from vi to nvi, after
> nvi stabilizes in NetBSD.  In the short term, I am concerned that two
> versions of vi are larger than one.  In the long term, I am concerned
> that the new vi is much bigger than the old.  On i386:
>
> # ls -l `which nvi`
> -r-xr-xr-x  3 root  wheel  466648 Jul 18 16:51 /usr/bin/nvi
> # ls -l `which vi`
> -r-xr-xr-x  3 root  wheel  286516 Jul 18 16:52 /usr/bin/vi
>
> Since one vi will suffice on most systems, I would like to add a build
> option, MKNVI, that defaults to 'yes' (build and install both vi and nvi).
> If set to 'no', however, MKNVI stops nvi from being built and installed?
> Is that ok, so far?
>
> I am concerned that nvi is too big for embedded applications.  What do
> we owe the larger size to?  Compilation options?  New (and essential)
> features?  Is there any way to bring the size under control?  I'm asking
> for your ideas.
>
> Dave
>
> --
> David Young             OJC Technologies
> dyoung@...      Urbana, IL * [phone] ext 24

--
Adam

[David Laight]

On Sun, Jul 20, 2008 at 05:21:26PM +0200, Adam Hoka wrote:
> Open a file with nvi, go to the first line and hit Shift-O.
> Do you see the same bug as me? It works in old vi.

Yes.

Also I added the 'matchchars' option to vi in order to remove '<' and '>'
from the characters matched by '%'.
Historically only "()[]{}" were matched by '%' although "<>" might be
useful in some languages, they are not in C.
In particular I often (yes often!) type c% at the start of xx->yy(zz)
and the '>' needs to be ignored.

        David

--
David Laight: david@...

[Jim Wise]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 18 Jul 2008, David Young wrote:

># ls -l `which nvi`
>-r-xr-xr-x  3 root  wheel  466648 Jul 18 16:51 /usr/bin/nvi
># ls -l `which vi`
>-r-xr-xr-x  3 root  wheel  286516 Jul 18 16:52 /usr/bin/vi
>
>I am concerned that nvi is too big for embedded applications.

Forget for a second that vi needs a fair amount of shared library code
and on-disk support files to be useful, so that space difference is, as
a percentage, much smaller than it looks.

Most embedded applications don't need to include vi.  As for those which
provide enough of a `unix-like' environment for vi to be relevant, I
can't think of a current embedded platform for which 160K is a lot of
space.

Let's _please_ not let this sort of hand-waving about alleged problems
for embedded developers detract from NetBSD's usefulness as a server --
a problem space where a good basic editor capable of handling
multinational character sets is something we currently lack as compared
to our competition.

- --
                                Jim Wise
                                jwise@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (NetBSD)

iD8DBQFIh9luq/KRbT0KwbwRAo2JAJwMhaH6KSz/CPK5zRmsuddH2VonLACeLV2m
Fva61dr8Jnqe34yH/Oc6Seo=
=y6lV
-----END PGP SIGNATURE-----

[Thor Lancelot Simon]

On Wed, Jul 23, 2008 at 09:22:53PM -0400, Jim Wise wrote:
>
> Most embedded applications don't need to include vi.  As for those which
> provide enough of a `unix-like' environment for vi to be relevant, I
> can't think of a current embedded platform for which 160K is a lot of
> space.

Many wireless routers have 8MB of flash, or even less.  I actually imported
FreeBSD's "ee" to my local source tree (though I find it fairly repulsive)
because it was so much smaller than the old vi -- I have a platform which
is in fact very similar to many of the smaller wireless routers, I need an
editor (we've repeatedly tried to remove it.  customers have howled.) and
100K is a make-or-break difference.

I'd much rather have vi, but I haven't figured out what to squeeze out
elsewhere to make it fit.  The current state of nvi makes it ~impossible,
and for, as far as I can tell, functionality that very few people use.  I
think its build should be slimmed down by default, or it should just be
removed.

Thor

[Christos Zoulas]

On Jul 24, 12:20am, tls@... (Thor Lancelot Simon) wrote:
-- Subject: Re: vi vs. nvi

| On Wed, Jul 23, 2008 at 09:22:53PM -0400, Jim Wise wrote:
| >
| > Most embedded applications don't need to include vi.  As for those which
| > provide enough of a `unix-like' environment for vi to be relevant, I
| > can't think of a current embedded platform for which 160K is a lot of
| > space.
|
| Many wireless routers have 8MB of flash, or even less.  I actually imported
| FreeBSD's "ee" to my local source tree (though I find it fairly repulsive)
| because it was so much smaller than the old vi -- I have a platform which
| is in fact very similar to many of the smaller wireless routers, I need an
| editor (we've repeatedly tried to remove it.  customers have howled.) and
| 100K is a make-or-break difference.
|
| I'd much rather have vi, but I haven't figured out what to squeeze out
| elsewhere to make it fit.  The current state of nvi makes it ~impossible,
| and for, as far as I can tell, functionality that very few people use.  I
| think its build should be slimmed down by default, or it should just be
| removed.

This is all a red herring. Nvi is not much larger than vi, it is only by
30-40K or so. And most of it is because it contains a copy of the regex
library because traditional regex libraries don't operate on wchar_t.
It only appears to be so big because it sets COPT=-g and that overrides
-O2 and the compiler generates large and suboptimal code.

christos

[Bill Stouder-Studenmund]

On Fri, Jul 18, 2008 at 07:28:55PM -0500, David Young wrote:
>
> I am concerned that nvi is too big for embedded applications.  What do
> we owe the larger size to?  Compilation options?  New (and essential)
> features?  Is there any way to bring the size under control?  I'm asking
> for your ideas.

Sorry for the delay, I'm still catching up w/ mail.

Why does this matter for an embedded system? Yes, I know space is tight.
What I don't see is why the fact we build it means it actually shows up on
the device. ??

If you don't want nvi, don't put it on your flash installs. :-)

I do not mind the build option, I am however concerned about the arguement
in favor of it.

Take care,

Bill

[Thor Lancelot Simon]

On Sat, Jul 26, 2008 at 01:32:18PM -0700, Bill Stouder-Studenmund wrote:

> On Fri, Jul 18, 2008 at 07:28:55PM -0500, David Young wrote:
> >
> > I am concerned that nvi is too big for embedded applications.  What do
> > we owe the larger size to?  Compilation options?  New (and essential)
> > features?  Is there any way to bring the size under control?  I'm asking
> > for your ideas.
>
> Sorry for the delay, I'm still catching up w/ mail.
>
> Why does this matter for an embedded system? Yes, I know space is tight.
> What I don't see is why the fact we build it means it actually shows up on
> the device. ??
>
> If you don't want nvi, don't put it on your flash installs. :-)

It is evidently intended that nvi replace our current vi.

Thor

[David Laight]

On Wed, Jul 23, 2008 at 09:13:47PM +0100, David Laight wrote:

> On Sun, Jul 20, 2008 at 05:21:26PM +0200, Adam Hoka wrote:
> > Open a file with nvi, go to the first line and hit Shift-O.
> > Do you see the same bug as me? It works in old vi.
>
> Yes.
>
> Also I added the 'matchchars' option to vi in order to remove '<' and '>'
> from the characters matched by '%'.
> Historically only "()[]{}" were matched by '%' although "<>" might be
> useful in some languages, they are not in C.
> In particular I often (yes often!) type c% at the start of xx->yy(zz)
> and the '>' needs to be ignored.

Another bug ...

When 'vi' askes for 'press any key to continue' after opening a file
(eg because the filename is too long)
the command keys (eg '/' and ':') have always been acted on as well.

        David

--
David Laight: david@...

[Aymeric Vincent]

Alan Barrett <apb@...> writes:

> On Fri, 18 Jul 2008, David Young wrote:
>> These days, NetBSD is shipping two versions of vi, /usr/bin/vi and
>> /usr/bin/nvi.
>
> That's obviously a mistake.  Whoever accidentally set things up so that
> nvi gets installed should just undo it.

Thank you for your comment.

My mistake was to delay the announcement of this decision on a public
list because I thought there was some movement on the front of some
japanese character set support. Apparently things have stalled here,
but I think we really need to have _any_ user be able to test the new
nvi while still providing a thoroughly tested text editor. 5.0 should
ship with only the new nvi.

Christos gave the reasons why nvi is bigger: the wchar_t-enabled regex
library and the compilation flags.

 Aymeric

[Aymeric Vincent]

Adam Hoka <adam.hoka@...> writes:

> Open a file with nvi, go to the first line and hit Shift-O.
> Do you see the same bug as me? It works in old vi.

Please file a PR.

Thanks,
 Aymeric

[Aymeric Vincent]

David Laight <david@...> writes:

> Also I added the 'matchchars' option to vi in order to remove '<' and '>'
> from the characters matched by '%'.
> Historically only "()[]{}" were matched by '%' although "<>" might be
> useful in some languages, they are not in C.
> In particular I often (yes often!) type c% at the start of xx->yy(zz)
> and the '>' needs to be ignored.

Hm, looks like an e-mail I sent you got lost: I told you I would put
this feature back as soon as I can. Sven told me he's unlikely to
accept it but will think about it when he sees a patch.

Regards,
 Aymeric

[Adam Hoka]

Aymeric Vincent wrote:

> Adam Hoka <adam.hoka@...> writes:
>
> > Open a file with nvi, go to the first line and hit Shift-O.
> > Do you see the same bug as me? It works in old vi.
>
> Please file a PR.

Done: bin/39293

--
Adam

[Aymeric Vincent]

Adam Hoka <adam.hoka@...> writes:

>> > Open a file with nvi, go to the first line and hit Shift-O.
>> > Do you see the same bug as me? It works in old vi.
>>
>> Please file a PR.
>
> Done: bin/39293

Thank you.

 Aymeric

[Jason Thorpe]

On Aug 5, 2008, at 7:43 AM, Aymeric Vincent wrote:

> Christos gave the reasons why nvi is bigger: the wchar_t-enabled regex
> library and the compilation flags.


Are there plans to get a wchar_t-capable regex into libc?

-- thorpej

[Thor Lancelot Simon]

On Tue, Aug 05, 2008 at 04:43:41PM +0200, Aymeric Vincent wrote:
>
> Christos gave the reasons why nvi is bigger: the wchar_t-enabled regex
> library and the compilation flags.

He did mention the compilation flags.  But that's going to be changed,
right?

As to "the wchar_t-enabled regex library":  I object to paying once for
the whole system (in libc) a lot less than once per executable.  In other
words, "Christos gave the reasons why..." says precisely nothing about
whether they are actually _sufficient_ reasons; it says only that they
_are_ reasons.

I'm not against growing the system, if it provides adequate benefit.  I
am still skeptical about whether there is adequate benefit for the
considerable amount of growth in this case.

--
Thor Lancelot Simon                                   tls@...
 "My guess is that the minimal training typically provided would only
 have given the party in question multiple new and elaborate ways to do
 something incomprehensibly stupid and dangerous." -Rich Goldstone