contributed to the project by testing, submitting patches, bug
reports, and suggestions. Thanks!
-ARISAWA Akihiro <ari at mbf dot ocn dot ne dot jp>
-Vincent Bernat <bernat at luffy dot cx>
-Han Boetes <han at mijncomputer dot nl>
-Robert J. Chassell <bob at rattlesnake dot com>
-Romain Francoise <romain at orebokech dot com>
-Ami Fischman <ami at fischman dot org>
-Friedrich Delgado Friedrichs <friedel at nomaden dot org>
-IRIE Tetsuya <irie at t dot email dot ne dot jp>
-Yoshiaki Kasahara <kasahara at nc dot kyushu-u dot ac dot jp>
-Jurej Kubelka <Juraj dot Kubelka at email dot cz>
-David Lichteblau <david at lichteblau dot com>
-Xavier Mallard <zedek at gnu-rox dot org>
-Istvan Marko <mi-mtty at kismala dot com>
-Ted Morse <morse at ciholas dot com>
-Dan Nicolaescu <dann at ics dot uci dot edu>
-Gergely Nagy <algernon at debian dot org>
-Mark Plaksin <happy at mcplaksin dot org>
-Francisco Borges <borges at let dot rug dot nl>
-Frank Ruell <stoerte at dreamwarrior dot net>
-Dan Waber <dwaber at logolalia dot com>
+ARISAWA Akihiro <ari@mbf.ocn.ne.jp>
+Vincent Bernat <bernat@luffy.cx>
+Han Boetes <han@mijncomputer.nl>
+Robert J. Chassell <bob@rattlesnake.com>
+Romain Francoise <romain@orebokech.com>
+Ami Fischman <ami@fischman.org>
+Friedrich Delgado Friedrichs <friedel@nomaden.org>
+IRIE Tetsuya <irie@t.email.ne.jp>
+Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
+Bas Kok <nekkobassu@yahoo.com>
+Jurej Kubelka <Juraj.Kubelka@email.cz>
+David Lichteblau <david@lichteblau.com>
+Xavier Mallard <zedek@gnu-rox.org>
+Istvan Marko <mi-mtty@kismala.com>
+Ted Morse <morse@ciholas.com>
+Gergely Nagy <algernon@debian.org>
+Dan Nicolaescu <dann@ics.uci.edu>
+Kalle Olavi Niemitalo <kon@iki.fi>
+Mark Plaksin <happy@mcplaksin.org>
+Francisco Borges <borges@let.rug.nl>
+Frank Ruell <stoerte@dreamwarrior.net>
+Dan Waber <dwaber@logolalia.com>
and many others.
Richard Stallman was kind enough to review an earlier version of my
* GTK support. If you compile your Emacs with the GTK
toolkit, some functionality of multi-tty will be lost.
+ In particular, closing an X display causes a crash.
Current releases of GTK have limitations and bugs that
prevent full-blown multi-display support in Emacs. Use the
Lucid toolkit if you want to see a complete feature set.
*** New functions: frame-tty-name, frame-tty-type, delete-tty,
terminal-local-value, set-terminal-local-value
+ terminal-id, terminal-parameters, terminal-parameter,
+ set-terminal-parameter
+
*** New variables: global-key-translation-map
*** The keymaps key-translation-map and function-key-map are now
THINGS TO DO
------------
-** Having {reset,init}_all_sys_modes in set-input-mode breaks arrow
- keys on non-selected terminals under screen, and sometimes on other
- terminal types as well. The other function keys continue to work
- fine. Sometimes faces on these screens become garbled.
+** Report GTK multi-display problems to GTK maintainers. For extra
+ credit, fix them.
- This only seems to affect displays that are of the same terminfo
- type as the selected one. Interestingly, in screen Emacs normally
- reports the up arrow key as `M-o A', but after the above SNAFU, it
- complains about `M-[ a'. UNIX ttys are a complete mystery to me,
- but it seems the reset-reinitialize cycle somehow leaves the
- non-selected terminals in a different state than usual. I have no
- idea how this could happen.
+** Possibly turn off the double C-g feature when there is an X frame.
+ C.f. (emacs)Emergency Escape.
- Currently set-input-mode resets only the currently selected
- terminal, which seems to somehow work around the problem.
+** 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'.
+
+** The handling of lisp/term/*.el, and frame creation in general, is a
+ big, big mess. How come the terminal-specific file is loaded by
+ tty-create-frame-with-faces? I don't think it is necessary to load
+ these files for each frame; once per terminal should be enough.
+ Update: lisp/term/*.el is not loaded repeatedly anymore, but
+ faces.el still needs to be cleaned up.
+
+** Fix frame-set-background-mode in this branch. It was recently
+ changed in CVS, and frame.el in multi-tty has not yet been adapted
+ for the changes. (It needs to look at
+ default-frame-background-mode.) (Update: maybe it is fixed now;
+ needs testing.)
+
+** I think `(set-)terminal-local-value' and the terminal parameter
+ mechanism should be integrated into a single framework.
+
+** Add the following hooks: after-delete-frame-hook (for server.el,
+ 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
conflicts with stuff like `display-time-mode'. Use `device-'
or `terminal-' instead. I think I prefer `terminal-'.
-** The semantics of terminal-local variables are confusing; it is not
- clear what binding is in effect in any given time. See if
- current_kboard (or at least the terminal-local bindings exported to
- Lisp) might be changed to be tied to the selected frame instead.
- Currently, `function-key-map' and `key-translation-map' may be
- accessed reliably only using the hackish
- `(set-)terminal-local-value' functions.
-
- Perhaps there should be a difference between `last-command' &co.
- and these more conventional configuration variables.
- (E.g. `symbol-value' would use current_kboard to access
- `last-command', but SELECTED_FRAME()->display->kboard to get the
- value of `function-key-map'.
+ It turns out that most of the offending Lisp functions were defined
+ in the trunk. Therefore, compatibility aliases should be defined
+ for the following names:
+
+ display-color-cells terminal-color-cells
+ display-color-p terminal-color-p
+ display-graphic-p terminal-graphic-p
+ display-grayscale-p terminal-grayscale-p
+ display-images-p terminal-images-p
+ display-mm-height terminal-mm-height
+ display-mm-width terminal-mm-width
+ display-mouse-p terminal-mouse-p
+ display-multi-font-p terminal-multi-font-p
+ display-multi-frame-p terminal-multi-frame-p
+ display-pixel-height terminal-pixel-height
+ display-pixel-width terminal-pixel-width
+ display-pixels-per-inch terminal-pixels-per-inch
+ display-planes terminal-planes
+ display-popup-menus-p terminal-popup-menus-p
+ display-save-under terminal-save-under
+ display-screens terminal-screens
+ display-supports-face-attributes-p terminal-supports-face-attributes-p
+ display-visual-class terminal-visual-class
+ framep-on-display framep-on-terminal
+ frames-on-display-list frames-on-terminal-list
+
+ The following functions were introduced in the multi-tty branch, and
+ can be renamed without aliases:
+
+ display-controlling-tty-p terminal-controlling-tty-p
+ display-list terminal-list
+ display-live-p terminal-live-p
+ display-name terminal-name
+ display-tty-type terminal-tty-type
+ frame-display terminal-of-frame
+ delete-display delete-terminal
** The single-keyboard mode of MULTI_KBOARD is extremely confusing
sometimes; Emacs does not respond to stimuli from other keyboards.
by changing the modelines or some other frame-local display element
on the locked out displays.
-** normal-erase-is-backspace-mode in simple.el needs to be updated for
- multi-tty (rep. by Dan Waber).
+** 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:
+
+ #0 0xb7ebc806 in SmcGetIceConnection () from /usr/X11R6/lib/libSM.so.6
+ #1 0x080e6641 in x_session_check_input (bufp=0xbf86c9c0) at xsmfns.c:144
+ #2 0x080d3bbc in XTread_socket (device=0xa722ff8, expected=1, hold_quit=0xbf86ca90) at xterm.c:7037
+ #3 0x080fa404 in read_avail_input (expected=1) at keyboard.c:6696
+ #4 0x080fa4ca in handle_async_input () at keyboard.c:6900
+ #5 0x080d51fa in x_term_init (display_name=162628899, xrm_option=0x0, resource_name=0x857068c "emacs") at xterm.c:10622
+ #6 0x080d920e in x_display_info_for_name (name=162628899) at xfns.c:3975
+ #7 0x080d92f9 in check_x_display_info (object=1) at xfns.c:274
+ #8 0x080d97b8 in Fx_create_frame (parms=151221485) at xfns.c:3016
+ #9 0x0815bf72 in Ffuncall (nargs=2, args=0xbf86ceec) at eval.c:2851
+
+ I installed a workaround to prevent this. The X session manager is
+ only contacted when the very first display in the Emacs session is
+ an X display. Also, x_delete_display() on this display aborts
+ session management, and XTread_socket only calls
+ x_session_check_input when it is called for the display that the
+ session was opened on. While this does not really fix the bug, it
+ makes it much less frequent, because session manager support will
+ not normally be enabled when Emacs can survive the shutdown of the
+ X server.
+
+ See if xsmfns.c should be updated.
** Hunt down display-related functions in frame.el and extend them all
to accept display ids.
that's why raw terminal support is broken again. I really do need
to understand input.)
+** flow-ctrl.el must be updated.
+
** Fix stuff_char for multi-tty. Doesn't seem to be of high priority.
DIARY OF CHANGES
(Done.)
+-- xt-mouse.el needs to be adapted for multi-tty. It currently
+ signals an error on kill-emacs under X, which prevents the user
+ from exiting Emacs. (Reported by Mnemonikk on freenode.)
+
+ (Done, I hope.)
+
+
+-- Having {reset,init}_all_sys_modes in set-input-mode breaks arrow
+ keys on non-selected terminals under screen, and sometimes on other
+ terminal types as well. The other function keys continue to work
+ fine. Sometimes faces on these screens become garbled.
+
+ This only seems to affect displays that are of the same terminfo
+ type as the selected one. Interestingly, in screen Emacs normally
+ reports the up arrow key as `M-o A', but after the above SNAFU, it
+ complains about `M-[ a'. UNIX ttys are a complete mystery to me,
+ but it seems the reset-reinitialize cycle somehow leaves the
+ non-selected terminals in a different state than usual. I have no
+ idea how this could happen.
+
+ Currently set-input-mode resets only the currently selected
+ terminal, which seems to somehow work around the problem.
+
+ Update:
+
+ Dan Nicolaescu <dann@ics.uci.edu> writes:
+ > Some terminals have 2 modes for cursor keys: Application Mode where
+ > the cursor keys transmit the codes defined in the terminfo entry, and
+ > Cursor mode. Applications have to send the smkx and rmkx terminfo
+ > strings to switch between the 2 modes. So Emacs (and emacsclient) have
+ > to send smkx when initializing and rmkx when quitting (or on
+ > suspend).
+
+ (I think patch-370 fixed this.)
+
+-- This long-standing bug (first reported by Han Boetes) seems to come
+ and go all the time. It is time to track it down and fix it.
+
+ emacs
+ M-x server-start
+
+ # From another xterm:
+ emacsclient -e '(y-or-n-p "Do you want me to crash? ")'
+ # Notice how the answer ends up in the *scratch* buffer
+ M-x garbage-collect
+ SIGSEGV
+
+ (Fixed in patch-414 after detailed analysis by Kalle Olavi Niemitalo.)
+
+-- normal-erase-is-backspace-mode in simple.el needs to be updated for
+ multi-tty (rep. by Dan Waber). (The Delete key is broken on X
+ because of this.)
+
+ (Fixed in patch-427.)
+
+-- I think keyboard-translate-table should be made terminal-local.
+
+ (Done in patch-431.)
+
+-- The semantics of terminal-local variables are confusing; it is not
+ clear what binding is in effect in any given time. See if
+ current_kboard (or at least the terminal-local bindings exported to
+ Lisp) might be changed to be tied to the selected frame instead.
+ Currently, `function-key-map' and `key-translation-map' may be
+ accessed reliably only using the hackish
+ `(set-)terminal-local-value' functions.
+
+ Perhaps there should be a difference between `last-command' &co.
+ and these more conventional configuration variables.
+ (E.g. `symbol-value' would use current_kboard to access
+ `last-command', but SELECTED_FRAME()->display->kboard to get the
+ value of `function-key-map'.
+
+ (Fixed in patch-434.)
+
+-- If the first key pressed on a new tty terminal is a function key,
+ it is not recognized correctly. May be related to the bug below.
+
+ (Seems to have been fixed as a side effect of patch-434. "The bug
+ below" was the set-input-mode madness.)
+
;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d