Projects / Traditional ex/vi

Traditional ex/vi

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.

Tags
Licenses
Operating Systems
Implementation

Recent releases

  •  25 Mar 2005 03:26

    Release Notes: vi no longer dies with a segmentation fault if a line does not fit on the screen after an insertion. The 'p' vi command now works correctly if the buffer contains a partial line with multibyte characters. Traditional regular expressions that sometimes failed to operate correctly have now been fixed.

    •  25 Feb 2005 02:42

      Release Notes: Many East Asian multibyte encodings are now supported. Traditional regular expressions can now be used with multi- byte characters. When the 'ignorecase' option is toggled, saved regular expressions are now updated accordingly again. The display is now updated correctly again when a tabulator is inserted at the beginning of a line. A lot of minor issues concerning multibyte character support and POSIX conformance have been fixed.

      •  19 Jan 2005 18:01

        Release Notes: The 'X' vi command works again; it was broken since the previous release. A lot of fixes were made for multibyte and multicolumn character support. An old vi bug concerning combinations of ex and vi copy/delete and paste commands was fixed. Compiling with diet libc works again.

        •  02 Dec 2004 20:25

          Release Notes: Support for multi-byte character encodings like UTF-8 has been added. The 'w' visual command now advances beyond blanks at the end of the current line. The ':s/foo/%/' substitution mechanism is now supported. Some possible heap overflows have been fixed. The code has been converted to ANSI C, and support for pre-POSIX systems has been dropped.

          •  05 Jun 2004 13:14

            Release Notes: An RPM spec file is now provided; some Makefile variables have been changed for this. When running on FreeBSD with a terminal baud rate of 38400, the window size is now set correctly.

            Recent comments

            07 Jan 2004 02:20 gritter

            Re: libterm changes

            > 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.

            06 Jan 2004 14:55 tedickey

            Re: libterm changes

            >
            > % 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.


            06 Jan 2004 12:43 gritter

            Re: libterm changes

            > 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.

            06 Jan 2004 12:09 tedickey

            Re: libterm changes

            >
            > % 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).

            05 Jan 2004 07:29 gritter

            Re: libterm changes

            > 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.

            Screenshot

            Project Spotlight

            OpenStack4j

            A Fluent OpenStack client API for Java.

            Screenshot

            Project Spotlight

            TurnKey TWiki Appliance

            A TWiki appliance that is easy to use and lightweight.