Mercurial > hg > xemacs-beta
view TODO.ben-mule-21-5 @ 799:03d9f9084848
[xemacs-hg @ 2002-03-30 04:46:47 by youngs]
2002-03-30 Steve Youngs <youngs@xemacs.org>
* package-index.LATEST.gpg: Update to current reality.
* package-index.LATEST.pgp: Ditto.
author | youngs |
---|---|
date | Sat, 30 Mar 2002 04:46:48 +0000 |
parents | e38acbeb1cae |
children | a5954632b187 |
line wrap: on
line source
March 20, 2002: bugs: -- 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. -- 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 code. -- md5 doesn't work. (Lstream not open errors) Causes w3 to fail. -- 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 line. August 29, 2001. This is the most current list of priorities in `ben-mule-21-5'. Updated often. high-priority: [input] -- 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. [clean-up] -- 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. [other] -- 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. mid-priority: -- 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 encode. -- 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 method.