About:
Traditional vi is derived from the 4BSD source and includes support for modern operating systems, 8-bit input, multi-byte character encodings like UTF-8, and features demanded by POSIX.2. It contains few additions beyond this, so it is of interest for those who look for a small but well-defined vi implementation close to that of most commercial Unix systems. It also has some features to cope with primitive terminals or slow connections.

Author:
Gunnar Ritter [contact developer]

Rating:	reset 1 2 3 4 5 6 7 8 9 10
8.16/10.00 (8 votes)

Homepage:
http://ex-vi.sourceforge.net
Tar/BZ2:
http://prdownloads.sourceforge.net/ex-vi/ex-050325.tar.bz2?download
Changelog:
http://ex-vi.sourceforge.net/Changes
CVS tree (cvsweb):
http://ex-vi.cvs.sourceforge.net/ex-vi/

Trove categories: [change]

[Development Status]		5 - Production/Stable
[Environment]		Console (Text Based)
[Intended Audience]		Advanced End Users
[License]		OSI Approved :: BSD License (original)
[Operating System]		POSIX, Unix
[Programming Language]		C
[Topic]		Software Development :: Internationalization, System, Text Editors, Utilities

Dependencies: [change]
No dependencies filed

 Branches

Branch	Version	Last release	License	URLs
Default	050325	25-Mar-2005	BSD License (original)

 Comments

[»] libterm changes
by T.E.Dickey - Jan 4th 2004 06:41:05

multiple tc='s are essentially a terminfo feature (since
they're a byproduct of converting using ncurses infocmp).
So it's not really termcap anymore.

[reply] [top]

[»] Re: libterm changes
by Gunnar Ritter - Jan 5th 2004 07:29:55


> multiple tc='s are essentially a
> terminfo feature (since
> they're a byproduct of converting using
> ncurses infocmp).
> So it's not really termcap anymore.
I don't know of any other reasonably complete termcap file
besides ESR's one (to which your remark applies). So this
seemed a must-have to me for keeping libterm usable. In
principle, that is - in fact, nobody seemed to use one of the
offending entries with vi for years since nobody complained.
The actual reason was that I was notified about a termcap
patch that added a tc= before the last capability, which is
clearly broken, but not a problem anymore for vi now.


[reply] [top]

---

[»] Re: libterm changes
by T.E.Dickey - Jan 6th 2004 12:09:25


>
> % multiple tc='s are essentially a
> % terminfo feature (since
> % they're a byproduct of converting
> using
> % ncurses infocmp).
> % So it's not really termcap anymore.
>
>
> I don't know of any other reasonably
> complete termcap file
> besides ESR's one (to which your remark
> applies). So this
> seemed a must-have to me for keeping
> libterm usable. In
> principle, that is - in fact, nobody
> seemed to use one of the
> offending entries with vi for years
> since nobody complained.
> The actual reason was that I was
> notified about a termcap
> patch that added a tc= before the last
> capability, which is
> clearly broken, but not a problem
> anymore for vi now.
> Not exactly. None of the termcap libraries that I am
aware of other than the termcap emulation in ncurses
support multiple tc='s. (ESR's version btw contains
many more errors than the one that I generate from
ncurses - I consider it an abandoned project).


[reply] [top]

---

[»] Re: libterm changes
by Gunnar Ritter - Jan 6th 2004 12:43:01


> None of the termcap
> libraries that I am
> aware of other than the termcap
> emulation in ncurses
> support multiple tc='s.
The comment in ESR's termcap file claims that both
4.4BSD libterm and GNU libtermcap (later than 1.3)
support them. A quick look at 4.4BSD and GNU v2.0.8
sources verifies this claim.

But what's your point at all? Do you actually think it's
an error to support multiple tc='s in a termcap library?
I don't see any serious compatibility issues here; it
doesn't seem likely that some termcap entries contain
multiple tc='s with the intention that only the last one
gets evaluated.

[reply] [top]

---

[»] Re: libterm changes
by T.E.Dickey - Jan 6th 2004 14:55:23


>
> % None of the termcap
> % libraries that I am
> % aware of other than the termcap
> % emulation in ncurses
> % support multiple tc='s.
>
>
> The comment in ESR's termcap file claims
> that both
> 4.4BSD libterm and GNU libtermcap (later
> than 1.3)
> support them. A quick look at 4.4BSD and
> GNU v2.0.8
> sources verifies this claim.
I'm looking at termcap 1.3.1, which states that it is not
(and am recalling more than one bug report for FreeBSD,
NetBSD that led me to investigate this). Ditto 2.0.8.

The version number is misleading - "2.0.8" dates several
years before termcap 1.3.1.


> But what's your point at all? Do you
> actually think it's
> an error to support multiple tc='s in a
> termcap library?
no - I thought it was ironic. And it would annoy some of the
frequent posters to FreeBSD mailing lists.


> I don't see any serious compatibility
> issues here; it
> doesn't seem likely that some termcap
> entries contain
> multiple tc='s with the intention that
> only the last one
> gets evaluated.


[reply] [top]

---

[»] Re: libterm changes
by Gunnar Ritter - Jan 7th 2004 02:20:29


> I'm looking at termcap 1.3.1, which
> states that it is not
> (and am recalling more than one bug
> report for FreeBSD,
> NetBSD that led me to investigate this).
> Ditto 2.0.8.
OIC, I was using Fedora sources and there's
a termcap-2.0.8-fix-tc.patch which adds this.
Sorry.


> no - I thought it was ironic. And it
> would annoy some of the
> frequent posters to FreeBSD mailing
> lists.
http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/gen/getcap.c
still provides the 4.4BSD code supporting multiple tc='s,
but all of libterm(cap) is apparently in Attic. What a pity.

[reply] [top]

---