1: gforth.el: indentation does not work right on the first line of a
2: buffer. anton 27jan95
3:
4: Conditional compilation continues after the file ends. This is allowed
5: by the standard (through an ambiguous condition), but the compiler
6: should at least produce a warning. anton 27jan95
7:
8: QUERY and TIB may behave differently than some may expect. TIB always
9: points to the current SOURCE, and QUERY puts its result there. anton
10: 28nov96
11:
12: open-path-file expands "./" into the sourcefilename. It should either
13: not expand "./" or provide a mechanism that allows the application to
14: determine what "./" should expand to. anton 16jun98
15:
16: gforth.el: Typing <ret> does not work when tabs separate words in a
17: line, and there is a \-comment at the end of the line. anton 19feb00
18:
19: SEE does not work when the control structure is too complex (e.g.,
20: load http://www.complang.tuwien.ac.at/forth/pentomino.fs and then do
21: SEE NEXT-PIECE). anton 5mar2000
22:
23: Include cannot handle lines longer than 255 characters. anton 4sep00
24:
25: Errors happening during a LOAD do not report the offending word and
26: its context (e.g., the 64-byte line). anton 8sep00
27:
28: Our ecvt routine apparently does not work correctly for Infs and NaNs.
29: Try "ac_cv_func_ecvt=no ./configure; make" and then in Gforth: "1e 0e
30: f/ f. 0e 0e f/ f.". anton 25sep00
31:
32: Our ecvt routine does not round correctly, e.g., 0.25->0.3. Marcel
33: Hendrix 3oct00 <8rdcmd$j96$1@news.IAEhv.nl>
34:
35: Newline has only LF (instead of CRLF) in DOS. Bruce Hoyt 25oct2000
36: <39f7b14b$2@clear.net.nz>
37:
38: SIGPIPE can make Gforth hard to stop (e.g.,
39: gforth -m 2M wordfreq.fs -e bye|head
40: anton 30may01
41:
42: F. does not print trailing zeroes (e.g., "10 SET-PRECISION 125e f.")
43: anton 31may01
44:
45: It may be useful for printing tables of FP numbers to have ways to
46: control the number of digits before and after the decimal point.
47: anton 31may01
48:
49: Block 0 does not work as it should: "0 block drop update save-buffers"
50: does not write to the blocks file. "0 block 1024 dump" seems to give
51: the previous contents of the buffer. Travis Bemann 10jul2001
52: <3b4b4f57$0$42883$272ea4a1@news.execpc.com>
53:
54: When accessing a block beyond the end of the block file, the result is
55: filled with spaces (this is also documented). However, when accessing
56: a previously unwritten block before the end of the block file, we will
57: get a block full of zeroes on most (all?) OSs. This inconsistency
58: should be eliminated and the documentation fixed. anton 14jul2001
59:
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>