Bas Kok <nekkobassu@yahoo.com>
Jurej Kubelka <Juraj.Kubelka@email.cz>
David Lichteblau <david@lichteblau.com>
+Richard Lewis <rtf@jabble.com>
+mace <mace@kirjakaapeli.lib.hel.fi>
+Suresh Madhu <madhu@cs.unm.edu>
Xavier Mallard <zedek@gnu-rox.org>
Istvan Marko <mi-mtty@kismala.com>
Ted Morse <morse@ciholas.com>
THINGS TO DO
------------
-** Let-binding `overriding-terminal-local-map' on a brand new frame
- does not seem to work correctly. (See `fancy-splash-screens'.)
- The keymap seems to be set up right, but events go to another
- terminal. Or is it `unread-command-events' that gets Emacs
- confused? Investigate.
+** `tool-bar-mode', `scroll-bar-mode', `menu-bar-mode' and
+ 'fringe-mode' are modes global to the entire Emacs session, not
+ just a single frame or a single terminal. This means that their
+ status sometimes differs from what's actually displayed on the
+ screen. As a consequence, the Options | Show/Hide menu sometimes
+ shows incorrect status, and you have to select an option twice for
+ it to have any visible effect on the current frame.
+
+ Change Emacs so that the status of the items in the Options |
+ Show/Hide menu correspond to the current frame.
+
+** emacsclient -t on the console does not work after su:
+
+ # su lorentey
+ $ emacsclient -t
+ *ERROR*: Could not open file: /dev/tty1
+
+ The tty can be opened as /dev/tty by emacsclient, but not by Emacs.
+ This seems to be a serious problem. Currently my only idea is to
+ bring back the ugly pty proxy hack from the initial versions of
+ multi-tty. Suggestions would be appreciated.
+
+** Understand how `quit_throw_to_read_char' works, and fix any bugs
+ that come to light.
+
+** See if getcjmp can be eliminated somehow. Why does Emacs allow
+ asynchronous input processing while it's reading input anyway?
** `delete-frame' events are handled by `special-event-map'
immediately when read by `read_char'. This is fine but it prevents
Emacs with GTK support. If you want to play around with GTK
multidisplay (and don't mind core dumps), you can edit src/config.h
and define HAVE_GTK_MULTIDISPLAY there by hand.
+
+ http://bugzilla.gnome.org/show_bug.cgi?id=85715
+
+ Update: Han reports that GTK+ version 2.8.9 almost gets display
+ disconnects right. GTK will probably be fully fixed by the time
+ multi-tty gets into the trunk.
+
+ Update: I am still having problems with GTK+ 2.8.10. I have the
+ impression that the various multidisplay fixes will only get
+ released in GTK+ 2.10.
** Audit `face-valid-attribute-values' usage in customize and
elsewhere. Its return value depends on the current window system.
** frames-on-display-list should also accept frames.
-** I smell something funny around pop_kboard's "deleted kboard" case.
- Determine what are the circumstances of this case, and fix any
- bug that comes to light.
-
** Consider the `tty-type' frame parameter and the `display-tty-type'
function. They serve the exact same purpose. I think it may be
a good idea to eliminate one of them, preferably `tty-type'.
instead of delete-frame-functions),
after-delete-terminal-functions, after-create-terminal-functions.
-** Fix set-input-mode for multi-tty. It's a truly horrible interface;
- what if we'd blow it up into several separate functions (with a
- compatibility definition)?
-
** BULK RENAME: The `display-' prefix of new Lisp-level functions
conflicts with stuff like `display-time-mode'. Use `device-'
or `terminal-' instead. I think I prefer `terminal-'.
by changing the modelines or some other frame-local display element
on the locked out displays.
+ Update: In fact struct kboard does have an echo_string slot.
+
** The session management module is prone to crashes when the X
connection is closed and then later I try to connect to a new X
session:
terminals in xterm and konsole. The screen does flicker a bit,
but it's so quick it isn't noticable.
+ (Update: This is probably some problem with padding or whatnot on
+ the secondary terminals.)
+
** Move baud_rate to struct display.
** Implement support for starting an interactive Emacs session without
** Do a grep on XXX and ?? for more issues.
-** Understand Emacs's low-level input system (it's black magic) :-)
- What exactly does interrupt_input do? I tried to disable it for
- raw secondary tty support, but it does not seem to do anything
- useful. (Update: Look again. X unconditionally enables this, maybe
- that's why raw terminal support is broken again. I really do need
- to understand input.)
- (Update: I am starting to understand the read_key_sequence->read-char
- ->kbd_buffer_get_event->read_avail_input->read_socket_hook path. Yay!)
-
** flow-ctrl.el must be updated.
** Fix stuff_char for multi-tty. Doesn't seem to be of high priority.
against `delete-frame-functions' throwing an error and preventing a
frame delete. (patch-475)
+-- Fix set-input-mode for multi-tty. It's a truly horrible interface;
+ what if we'd blow it up into several separate functions (with a
+ compatibility definition)?
+
+ (Done. See `set-input-interrupt-mode', `set-output-flow-control',
+ `set-input-meta-mode' and `set-quit-char'.) (patch-457)
+
+-- Let-binding `overriding-terminal-local-map' on a brand new frame
+ does not seem to work correctly. (See `fancy-splash-screens'.)
+ The keymap seems to be set up right, but events go to another
+ terminal. Or is it `unread-command-events' that gets Emacs
+ confused? Investigate.
+
+ (Emacs was confused because a process filter entered
+ `recursive-edit' while Emacs was reading input. I added support
+ for this in the input system.) (patch-489)
+
+-- I smell something funny around pop_kboard's "deleted kboard" case.
+ Determine what are the circumstances of this case, and fix any
+ bug that comes to light.
+
+ (It happens simply because single_kboard's terminal is sometimes
+ deleted while executing a command on it, for example the one that
+ kills the terminal. There was no bug here, but I rewrote the whole
+ single_kboard mess anyway.) (patch-489)
+
+-- Understand Emacs's low-level input system (it's black magic) :-)
+ What exactly does interrupt_input do? I tried to disable it for
+ raw secondary tty support, but it does not seem to do anything
+ useful. (Update: Look again. X unconditionally enables this, maybe
+ that's why raw terminal support is broken again. I really do need
+ to understand input.)
+ (Update: I am starting to understand the read_key_sequence->read-char
+ ->kbd_buffer_get_event->read_avail_input->read_socket_hook path. Yay!)
+
+ (Update: OK, it all seems so easy now (NOT). Input could be done
+ synchronously (with wait_reading_process_input), or asynchronously
+ by SIGIO or polling (SIGALRM). C-g either sets the Vquit_flag,
+ signals a 'quit condition (when immediate_quit), or throws to
+ `getcjmp' when Emacs was waiting for input when the C-g event
+ arrived.)
+
+-- Replace wrong_kboard_jmpbuf with a special return value of
+ read_char. It is absurd that we use setjmp/longjmp just to return
+ to the immediate caller.
+
+ (Done in patch-500.)
;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
HCoop / bpt / emacs.git / blobdiff