April 11, 2002:
1. Finish checking in current mule ws.
2. Start working on bugs reported by others and noticed by me:
-- problems cutting and pasting binary data, e.g. from byte-compiler instructions
-- test suite failures
-- process i/o problems w.r.t. eol: |uniq (e.g.) leaves ^M's at end of
line; running "bash" as shell-file-name doesn't work because it doesn't
like the extra ^M's.
March 20, 2002:
-- TTY-mode problem. When you start up in TTY mode, XEmacs goes through
the loadup process and appears to be working -- you see the startup
screen pulsing through the different screens, and it appears to be
listening (hitting a key stops the screen motion), but it's frozen --
the screen won't get off the startup, key commands don't cause anything
to happen. STATUS: In progress.
-- Memory ballooning in some cases. Not yet understood.
-- other test suite failures?
-- need to review the handling of sounds. seems that not everything is
documented, not everything is consistently used where it's supposed to,
some sounds are ugly, etc. add sounds to `completer' as well.
-- redo with-trapping-errors so that the backtrace is stored away and only
outputted when an error actually occurs (i.e. in the condition-case
handler). test. (use ding of various sorts as a helpful way of checking
out what's going on.)
-- problems with process input: |uniq (for example) leaves ^M's at end of
-- carefully review looking up of fonts by charset, esp. wrt the last
element of a font spec.
-- add package support to ignore certain files -- *-util.el for languages.
-- review use of escape-quoted in auto_save_1() vs. the buffer's own coding
-- figure out how to get the total amount of data memory (i.e. everything
but the code, or even including the code if can't distinguish) used by
the process on each different OS, and use it in a new algorithm for
triggering GC: trigger only when a certain % of the data size has been
consed up; in addition, have a minimum.
-- Occasional crash when freeing display structures. The problem seems to
be this: A window has a "display line dynarr"; each display line has a
"display block dynarr". Sometimes this display block dynarr is getting
freed twice. It appears from looking at the code that sometimes a
display line from somewhere in the dynarr gets added to the end -- hence
two pointers to the same display block dynarr. need to review this
August 29, 2001.
This is the most current list of priorities in `ben-mule-21-5'.
-- support for WM_IME_CHAR. IME input can work under -nuni if we use
WM_IME_CHAR. probably we should always be using this, instead of
snarfing input using WM_COMPOSITION. i'll check this out.
-- Russian C-x problem. see above.
-- make sure it compiles and runs under non-mule. remember that some
code needs the unicode support, or at least a simple version of it.
-- make sure it compiles and runs under pdump. see below.
-- make sure it compiles and runs under cygwin. see below.
-- clean up mswindows-multibyte, TSTR_TO_C_STRING. expand dfc
optimizations to work across chain.
-- eliminate last vestiges of codepage<->charset conversion and similar stuff.
-- test the "file-coding is binary only on Unix, no-Mule" stuff.
-- test that things work correctly in -nuni if the system environment
is set to e.g. japanese -- i should get japanese menus, japanese
file names, etc. same for russian, hebrew ...
-- cut and paste. see below.
-- misc issues with handling lang environments. see also August 25,
"finally: working on the C-x in ...".
-- when switching lang env, needs to set keyboard layout.
-- user var to control whether, when moving into text of a
particular language, we set the appropriate keyboard layout. we
would need to have a lisp api for retrieving and setting the
keyboard layout, set text properties to indicate the layout of
text, and have a way of dealing with text with no property on
it. (e.g. saved text has no text properties on it.) basically,
we need to get a keyboard layout from a charset; getting a
language would do. Perhaps we need a table that maps charsets
to language environments.
-- test that the lang env is properly set at startup. test that
switching the lang env properly sets the C locale (call
setlocale(), set LANG, etc.) -- a spawned subprogram should have
the new locale in its environment.
-- look through everything below and see if anything is missed in this
priority list, and if so add it. create a separate file for the
priority list, so it can be updated as appropriate.
-- clean up the chain coding system. its list should specify decode
order, not encode; i now think this way is more logical. it should
check the endpoints to make sure they make sense. it should also
allow for the specification of "reverse-direction coding systems":
use the specified coding system, but invert the sense of decode and
-- along with that, places that take an arbitrary coding system and
expect the ends to be anything specific need to check this, and add
the appropriate conversions from byte->char or char->byte.
-- get some support for arabic, thai, vietnamese, japanese jisx 0212:
at least get the unicode information in place and make sure we have
things tied together so that we can display them. worry about r2l
some other time.
-- check the handling of C-c. can XEmacs itself be interrupted with C-c?
is that impossible now that we are a window, not a console, app? at
least we should work something out with `i', so that if it receives a
C-c or C-break, it interrupts XEmacs, too. check out how process groups
work and if they apply only to console apps. also redo the way that
XEmacs sends C-c to other apps. the business of injecting code should
be last resort. we should try C-c first, and if that doesn't work, then
the next time we try to interrupt the same process, use the injection