1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
$Id: HELP,v 1.1 2000/09/05 22:09:47 cbond Exp $
Since I'll be leaving Stormix today, I thought I'd leave a list of things that may give you trouble in the future, so you won't have to mess around if you want to fix something then.
* libarr does not handle xterms as well as it could. It doesn't deal
with resizing or anything like that. This could be done quite easily,
but not without some evil hacks.
* ktree.c does not contain all of the keys that it could or should. If
you want to add a special key, you must do the following:
* Make sure the key exists in ``man 5 terminfo''.
* Once you've found the termcap code for it, get the source for
something that has all of the string offsets of terminfo
entries. I use S-Lang's sltermin.c. Look for the offset of
the code you just found; it should be in there.
* Put the offset in include/cap_offset.h as OFFSET_<code>:
#define OFFSET_KP <offset>
* Add a new key code to arr.h, and make sure it's not the same
as any of the other AK_ definitions:
#define AK_PAGEDOWN <value>
* Add an entry to ktree.c's k_list[]:
KQUEUE_ENTRY(OFFSET_KP, <arr key code>)
* Multibyte support is less than perfect. This is, however, more of a
problem with kon than it is with libarr. For instance, if you try to
change the color of one byte of a multibyte string, kon won't like it
and the results are undefined. Because of this, libarr will try and
protect you by making both bytes of the multibyte string the same
color. This is not the greatest solution, but it is the best we
could think of at the time. Additionally, libarr's diff routine
sometimes messes up output when dealing with multibyte strings. This
happens when you want to change a multibyte string, but only one of
the bytes change:
originally: <A5><C6>
updated to be: <A5><B9>
(The goal is to produce an entirely different multibyte
character.)
In this case, libarr will only write the second byte of the multibyte
string (since it is the only one that changed). Unfortunately, kon is
stupid and doesn't like this. Results are undefined. Essentially,
this *is* kon's fault, but libarr could be a little nicer about it and
write *both* bytes to the terminal, even though only one of them
changed. This is what kon is expecting.
* ``kon'' is special-cased in tinfo.c. This is simply awful. If you
want libarr to work with another $TERM that supports multibyte
characters, that $TERM needs to be added to mbyte_pairs[]. If you
ever want libarr to work with things like cce, this is what needs to
happen.
That's all I can think of right now. If something ever goes wrong or is not working as expected, don't hesitate to contact me.
Chris L. Bond <cbond@stormix.com>
|
