add a short test program. use hard values instead of GDK defines in the 0
[vte.git] / README
1 * What is VTE?
2 - You could say that VTE is something of a research project of mine, based on
3   the simple question:  "if programs can use a termcap file (through either
4   libtermcap or curses or ncurses) to determine how to drive a terminal, why
5   can't a terminal emulator use a termcap file to determine how to behave?"
6
7 * What does VTE include?
8 - VTE includes a library (libvte) which implements such a terminal emulator
9   widget for GTK+ 2.0, and a sample application (vte) which wraps that widget
10   in a GTK window.  Because I'm more concerned with whether or not it works,
11   all settings are hard-coded to whatever I needed to test the last time I
12   touched it.  If you actually want to use the widget to get work done, you
13   should probably be using gnome-terminal.
14
15 * How does it work?
16 - The VTE library inserts terminal capability strings into a tree of tables,
17   and then uses it to determine if data received from a pseudo-terminal is a
18   control sequence or just random data.  The sample program "interpret"
19   illustrates more or less what the widget sees after it filters incoming data.
20
21 * What's missing?
22 - Accessibility doesn't work right yet.
23 - Chinese and Korean text isn't displayed correctly because we pass it through
24   iconv() before performing substitutions, and they both use GR characters.
25   Japanese works because it only uses GL characters, which iconv() essentially
26   casts to gunichars, where we perform substitutions.  Probably we need to break
27   the text into narrow and wide chunks by performing substitution first (to find
28   and break out the wide chunks) and then iconv the narrow sets (what's left)
29   one chunk at a time.
30 - Mouse hilite tracking isn't implemented yet.
31 - Most control sequences are recognized, but many aren't implemented.  There
32   are enough to run ls, vim, less, emacs and mutt, but more need to be
33   implemented (ff, i1, i3, is, iP, LF, LO, MC, mh, ML, mm, mo, nw, pf,
34   pk, pl, pf, po, pO, ps, px, r1, r2, r3, RA, RF, rp, rs, RX, SA, SX, wi,
35   several more from the XTerm set).
36 - I'm not sure the widget implementation itself is correct.  There are many
37   changes in going from GTK+ 1.2 to 2.0, and examples of the proper way to do
38   things is currently scarce, so some of it's guesswork.
39 - An actual property interface needs to be retrofitted over the various options
40   which are only presented as get/set accessors.
41
42 * What's weird?
43 - Relative cursor motion is weird.  When the character to the right of the
44   cursor is a 3-byte UTF-8 sequence for a character which occupies two
45   columns on the screen, three things may happen when the application sends
46   the "cursor left" control sequence:
47   * the cursor moves two columns (one character) to the left
48     This eliminates the possibility of moving the cursor into the middle of
49     a multi-column character.
50   * the cursor moves one column (one half-character) to the left
51     This makes determining where the cursor is easier, but requires the
52     application to emit a control sequence more than once for multi-column
53     characters.
54   * the cursor moves one "byte" to the left
55     This happens to work for a few locales, and is otherwise just broken.
56   Currently VTE follows the second convention.  More on this topic:
57   http://czyborra.com/unicode/terminals.html
58   http://mail.nl.linux.org/linux-utf8/1999-10/msg00014.html
59   http://www.debian.org/doc/manuals/intro-i18n/ch-output.en.html
60 - Depending on your locale, the current encoding, and possibly the strengh
61   of cosmic rays, the display width of certain Unicode characters changes.
62   For the most part this works correctly now, but if you find that it
63   doesn't, please file a bug report including a screenshot, the typescript
64   file produced by the incorrectly displayed program run under "script", and
65   the contents of your LANG environment variable.