changeset 83774:4bcdc5c592d1

Move to admin/notes/multi-tty, with some edits.
author Glenn Morris <rgm@gnu.org>
date Thu, 30 Aug 2007 05:11:16 +0000
parents 3592dd2e8c0c
children 9d2d4dee14ae
files README.multi-tty
diffstat 1 files changed, 0 insertions(+), 1465 deletions(-) [+]
line wrap: on
line diff
--- a/README.multi-tty	Thu Aug 30 05:09:07 2007 +0000
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,1465 +0,0 @@
-			-*- coding: utf-8; mode: text; -*-
-GOAL
-----
-
-This branch implements support for opening multiple, different tty
-devices and simultaneous X and tty frames from a single Emacs session.
-
-Some use cases:
-Emacs is notoriously slow at startup, so most people use another
-editor or emacsclient for quick editing jobs from the console.
-Unfortunately, emacsclient was very awkward to use, because it did not
-support opening a new Emacs frame on the current virtual tty.
-Now, with multi-tty support, it can do that.  (Emacsclient starts up
-faster than vi!)
-
-Some Gnus users (including me) run Gnus in an X frame in its own Emacs
-instance, which they typically leave running for weeks.  It would be
-nice if they could connect to this instance from a remote ssh session
-and check their messages without opening a remote X frame or resorting
-to gnus-slave.
-
-THANKS
-------
-
-The following is a (sadly incomplete) list of people who have
-contributed to the project by testing, submitting patches, bug
-reports, and suggestions.  Thanks!
-
-Bernard Adrian <bernadrian@free.fr>
-ARISAWA Akihiro <ari@mbf.ocn.ne.jp>
-Vincent Bernat <bernat@luffy.cx>
-Han Boetes <han@mijncomputer.nl>
-Francisco Borges <borges@let.rug.nl>
-Damien Cassou <damien.cassou@laposte.net>
-Robert J. Chassell <bob@rattlesnake.com>
-Romain Francoise <romain@orebokech.com>
-Ami Fischman <ami@fischman.org>
-Noah Friedman <friedman@splode.com>
-Friedrich Delgado Friedrichs <friedel@nomaden.org>
-Samium Gromoff <_deepfire@mail.ru>
-Mikhail Gusarov <dottedmag@dottedmag.net>
-Eric Hanchrow <offby1@blarg.net>
-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>
-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>
-Gergely Nagy <algernon@debian.org>
-Dan Nicolaescu <dann@ics.uci.edu>
-Kalle Olavi Niemitalo <kon@iki.fi>
-Mark Plaksin <happy@mcplaksin.org>
-Frank Ruell <stoerte@dreamwarrior.net>
-Tom Schutzer-Weissmann <trmsw@yahoo.co.uk>
-Joakim Verona <joakim@verona.se>
-Dan Waber <dwaber@logolalia.com>
-and many others.
-
-Richard Stallman was kind enough to review an earlier version of my
-patches.
-
-
-STATUS
-------
-
-The branch is now very stable and almost full-featured.  All of the
-major problems have been fixed, only a few minor issues remain.  (It
-still needs to be ported to Windows/Mac/DOS, though.)  Both multiple
-tty device support and simultaneous X and tty frame support works
-fine.  Emacsclient has been extended to support opening new tty and X
-frames.  It has been changed to open new Emacs frames by default.
-
-The multi-tty branch has been scheduled for inclusion in the next
-major release of Emacs (version 23).  I expect the merge into the
-development trunk to occur sometime during next year (2006), after the
-merge of the Unicode branch.
-
-Tested on GNU/Linux, Solaris 8, FreeBSD and OpenBSD.  Please let me
-know if you succeed or fail to use it on other platforms---I'll have a
-few tricky test cases for you.
-
-Known problems:
-
-        * GTK support.  If you compile your Emacs with the GTK
-          toolkit, some functionality of multi-tty may be lost.  In
-          particular, you may get crashes while working on multiple X
-          displays at once.  Previous releases of GTK had limitations
-          and bugs that prevented full-blown multi-display support in
-          Emacs.  (GTK crashed when Emacs tries to disconnect from an
-          X server.)  Things are much improved in the current GTK
-          version, but if you do experience crashes in libgtk, try
-          compiling Emacs with the Lucid toolkit instead.
-
-        * The single-kboard mode.
-
-	  If your multi-tty Emacs session seems to be frozen, you
-	  probably have a recursive editing session or a pending
-	  minibuffer prompt (which is a kind of recursive editing) on
-	  another display.  To unfreeze your session, switch to that
-	  display and complete the recursive edit, for example by
-	  pressing C-] (`abort-recursive-edit').
-
-	  I am sorry to say that currently there is no way to break
-	  out of this "single-kboard mode" from a frozen display.  If
-	  you are unable to switch to the display that locks the
-	  others (for example because it is on a remote computer),
-	  then you can use emacsclient to break out of all recursive
-	  editing sessions:
-
-		emacsclient -e '(top-level)'
-
-	  Note that this (perhaps) unintuitive behaviour is by design.
-	  Single-kboard mode is required because of an intrinsic Emacs
-	  limitation that is very hard to eliminate.  (This limitation
-	  is related to the single-threaded nature of Emacs.)
-
-	  I plan to implement better user notification and support for
-	  breaking out of single-kboard mode from locked displays.
-
-	* Mac and DOS support is broken, doesn't even
-  	  compile.  Multiple display support will probably not provide
-  	  new Emacs features on these systems, but the multi-tty
-  	  branch changed a few low-level interfaces, and the
-  	  system-dependent source files need to be adapted
-  	  accordingly.  The changes are mostly trivial, so almost
-  	  anyone can help, if only by compiling the branch and
-  	  reporting the compiler errors.
-
-
-HOW TO GET THE BRANCH
----------------------
-
-To get the branch, check out the "multi-tty" CVS branch from Emacs CVS.
-
-Alternatively, you can use Bazaar version 1 (not 2) or tla:
-
-	baz register-archive http://arch.sv.gnu.org/archives/emacs
-	baz get emacs@sv.gnu.org/emacs--multi-tty--0 <directory>
-
-
-COMPILATION
------------
-
-The multi-tty branch is compiled the same way as Emacs itself:
-
-	make maintainer-clean  # (If you have compiled Emacs before)
-
-	./configure <your favourite options>
-	make bootstrap
-	make install
-
-If you have strange compilation errors, they may be caused by old
-*.elc files that are left over from an earlier bootstrap.  The `make
-maintainer-clean' target deletes them, so it is a good idea to run
-that before reporting a bug.  (Emacs requires a clean recompilation
-after certain kinds of source code changes.)
-
-TESTING
--------
-
-To test the multi-tty branch, start up the Emacs server with the
-following commands:
-
-	emacs
-	M-x server-start
-
-and then (from a shell prompt on another terminal) start emacsclient
-with
-	emacsclient -t /optional/file/names...   (for a tty frame)
-	emacsclient /optional/file/names...      (for an X frame)
-
-(Make sure both emacs and emacsclient are multi-tty versions.)
-You'll hopefully have two fully working, independent frames on
-separate terminals. The new frame is closed automatically when you
-finish editing the specified files (C-x #), but delete-frame (C-x 5 0)
-also works.  Of course, you can create frames on more than two tty
-devices.
-
-Creating new frames on the same tty with C-x 5 2 (make-frame-command)
-works, and behaves the same way as in previous Emacs versions.  If you
-exit emacs, all terminals should be restored to their previous states.
-
-This is work in progress, and probably full of bugs.  It is a good
-idea to run emacs from gdb, so that you'll have a live instance to
-debug if something goes wrong.  Please send your bug reports to
-emacs-devel@gnu.org.  Please don't forget to mention that you are
-using the multi-tty branch.
-
-TIPS & TRICKS
--------------
-
-I think the best way to use the new Emacs is to have it running inside
-a disconnected GNU screen session, and always use emacsclient for
-normal work.  One advantage of this is that not a single keystroke of
-your work will be lost if the display device that you are using
-crashes, or the network connection times out, or whatever.  (I had an
-extremely unstable X server for some time while I was developing these
-patches, and running Emacs this way has saved me a number of M-x
-recover-session invocations.)
-
-I use the following two bash scripts to handle my Emacs sessions:
-
--------------------------------------------------------connect-emacs--
-#!/bin/bash
-# Usage: connect-emacs <name> <args>...
-#
-# Connects to the Emacs instance called NAME.  Starts up the instance
-# if it is not already running.  The rest of the arguments are passed
-# to emacsclient.
-
-name="$1"
-shift
-    
-if [ -z "$name" ]; then
-    echo "Usage: connect_emacs <name> <args>..." >&2
-    exit 1
-fi
-preload-emacs "$name" wait
-/usr/bin/emacsclient.emacs-multi-tty -s "$name" "$@"
-----------------------------------------------------------------------
-
--------------------------------------------------------preload-emacs--
-#!/bin/bash
-# Usage: preload-emacs <name> [<waitp>]
-#
-# Preloads the Emacs instance called NAME in a detached screen
-# session.  Does nothing if the instance is already running.  If WAITP
-# is non-empty, the function waits until the server starts up and
-# creates its socket; otherwise it returns immediately.
-
-name="$1"
-waitp="$2"
-screendir="/var/run/screen/S-$USER"
-serverdir="/tmp/emacs$UID"
-emacs=/usr/bin/emacs-multi-tty # Or wherever you installed your multi-tty Emacs
-
-if [ -z "$name" ]; then 
-    echo "Usage: preload_emacs <name> [<waitp>]" >&2
-    exit 1
-fi
-
-if [ ! -e "$screendir"/*."$name" ]; then
-    if [ -e "$serverdir/$name" ]; then
-	# Delete leftover socket (for the wait option)
-	rm "$serverdir/$name"
-    fi
-    screen -dmS "$name" "$emacs" -nw --eval "(setq server-name \"$name\")" -f server-start
-fi
-if [ ! -z "$waitp" ]; then
-    while [ ! -e "$serverdir/$name" ]; do sleep 0.1; done
-fi
-----------------------------------------------------------------------
-
-I have the following in my profile to have two instances automatically
-preloaded for editing and email:
-
-	preload-emacs editor
-	preload-emacs gnus
-
-It is useful to set up short aliases for connect-emacs.  I use the
-following:
-
-	alias edit="connect-emacs editor"
-	alias e=edit
-	alias et="connect-emacs editor -t"
-	alias gnus="connect-emacs gnus"
-
-
-CHANGELOG
----------
-
-See the ChangeLog.multi-tty files in the source tree.
-
-NEWS
-----
-
-For the NEWS file:  (Needs much, much work)
-
-** Support for multiple terminal devices and simultaneous graphical
-   and tty frames has been added.  You can test for the presence of
-   this feature in your Lisp code by testing for the `multi-tty'
-   feature.
-
-*** The `window-system' variable has been made frame-local. The new
-    `initial-window-system' variable contains the `window-system'
-    value for the first frame.
-
-*** You can specify a terminal device (`tty' parameter) and a terminal
-    type (`tty-type' parameter) to `make-terminal-frame'.
-
-*** The new function `make-frame-on-tty' allows you to create a new
-    frame on another tty device interactively.
-
-*** The function `make-frame-on-display' now works during a tty
-    session, and `make-frame-on-tty' works during a graphical session.
-
-*** Emacsclient has been extended to support opening a new terminal
-    frame. Its behaviour has been changed to open a new Emacs frame by
-    default.  Use the -c option to get the old behavior of opening
-    files in the currently selected Emacs frame.
-
-*** C-z now invokes `suspend-frame', C-x C-c now invokes
-    `save-buffers-kill-terminal'.
-
-*** New functions: frame-tty-name, frame-tty-type, delete-tty,
-    suspend-tty, resume-tty, terminal-id, terminal-parameters,
-    terminal-parameter, set-terminal-parameter,
-    modify-terminal-parameters, environment, let-environment
-
-*** New variables: local-key-translation-map, local-function-key-map
-
-*** New frame parameters display-environment-variable and
-    term-environment-variable. 
-
-*** The `keyboard-translate-table' variable and the terminal and
-    keyboard coding systems have been made terminal-local.
-
-*** In addition to the global key-translation-map and
-    function-key-map, Emacs has terminal-local
-    local-key-translation-map and local-function-key-map variables,
-    and uses them instead of the global keymaps to set up translations
-    and function key sequences relevant to a specific terminal device.
-
-*** talk.el has been extended for multiple tty support.
-
-* * *
-
-(The rest of this file consists of my development notes and as such it
-is probably not very interesting for anyone else.)
-
-THINGS TO DO
-------------
-
-** See if `tty-defined-color-alist' needs to be terminal-local.
-   Update: Dan says it should be, so convert it.
-
-** Mikhail Gusarov suggest to add a hook akin to
-   `after-make-frame-functions' that is called whenever Emacs connects
-   to a new terminal.  Good idea!
-
-** emacsclient -t on the console does not work after su.  You have to
-   use non-root accounts or start as root to see this.
-
-   	Login: root
-	Password:
-	# 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.
-
-   Update: we could change emacsclient to pass its open file
-   descriptor to the Emacs process.  Unfortunately, this requires a
-   new Lisp-level Emacs API, and as file descriptors are not otherwise
-   exported to Lisp, this approach seems at least as ugly as the pty
-   proxy idea.
-
-** lisp/vc.el depends on the terminal type during load time.
-   `vc-annotate-color-map' is one example that needs to be fixed.
-
-** 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
-   higher-level keymaps from binding that event to get notified of the
-   deleted frame.
-
-   Sometimes it would be useful for Lisp code to be notified of frame
-   deletions after they have happened, usually because they want to
-   clean up after the deleted frame.  Not all frame-local states can
-   be stored as a frame parameter.  For example,
-   `display-splash-screen' uses `recursive-edit' with a special keymap
-   override to create its buffer---and it leads to all kinds of
-   nastiness if Emacs stays in this recursive edit mode after the
-   frame containing the splash screen is deleted.  Basically, the
-   splash-screen implementation wants to throw out of the recursive
-   edit when the frame is deleted; however, it is not legal to throw
-   from `delete-frame-functions' because `delete-frame' must not fail.
-   (Introducing `delete-frame-after-functions' would not help either
-   because `delete-frame' may not fail at that time either.)
-
-   Currently `fancy-splash-screens' installs a
-   `delete-frame-functions' hook that sets up a timer to exit the
-   recursive edit.  This is an adequate solution, but it would perhaps
-   be better to have something like a `frame-deleted' event that could
-   be bound in the normal way.
-
-** Trouble: `setenv' doesn't actually set environment variables in the
-   Emacs process.  This defeats the purpose of the elaborate
-   `server-with-environment' magic around the `tgetent' call in
-   `init_tty'.  D'oh.
-
-** (Possibly) create hooks in struct device for creating frames on a
-   specific terminal, and eliminate the hackish terminal-related frame
-   parameters (display, tty, tty-type).
-
-   	make_terminal_frame
-		create_tty_output
-
-** Decide whether to keep the C implementation of terminal parameters,
-   or revert to the previous, purely Lisp code.  It turned out that
-   local environments do not need terminal parameters after all.
-
-** Move Fsend_string_to_terminal to term.c, and declare get_named_tty
-   as static, removing it from dispextern.h.
-   Move fatal to emacs.c and declare it somewhere.
-
-** Search for `suspend-emacs' references and replace them with
-   `suspend-frame', if necessary.  Ditto for `save-buffers-kill-emacs'
-   vs. `save-buffers-kill-display'.
-
-** Emacs crashes when a tty frame is resized so that there is no space
-   for all its windows.  (Tom Schutzer-Weissmann)
-
-** Report GTK multi-display problems to GTK maintainers.  For extra
-   credit, fix them.
-
-   Currently you can not connect to new X displays when you compile
-   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.
-   Replace static initializers using it with runtime functions.  For
-   example, custom's buttons are broken on non-initial device types.
-
-** Possibly turn off the double C-g feature when there is an X frame.
-   C.f. (emacs)Emergency Escape.
-
-** frames-on-display-list should also accept frames.
-
-** 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.) (Note that the byte compiler has this to say about
-   term/rxvt.el:)
-
-	term/rxvt.el:309:17:Warning: assignment to free variable
-	    `default-frame-background-mode'
-
-** I think `(set-)terminal-local-value' and the terminal parameter
-   mechanism should be integrated into a single framework.
-
-   (Update: `(set-)terminal-local-value' is now eliminated, but the
-   terminal-local variables should still be accessible as terminal
-   parameters.  This also applies to `display-name' and similar
-   functions.)
-
-** Add the following hooks: after-delete-frame-hook (for server.el,
-   instead of delete-frame-functions),
-   after-delete-terminal-functions, after-create-terminal-functions.
-
-** 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-'.
-
-   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
-   were renamed without aliases:
-
-    delete-display			delete-terminal
-    display-controlling-tty-p           controlling-tty-p
-    display-list                        terminal-list
-    display-live-p                      terminal-live-p
-    display-name                        terminal-name
-    display-tty-type                    tty-type
-    frame-display                       frame-terminal
-    selected-display			selected-terminal
-
-** The single-keyboard mode of MULTI_KBOARD is extremely confusing
-   sometimes; Emacs does not respond to stimuli from other keyboards.
-   At least a beep or a message would be important, if the single-mode
-   is still required to prevent interference.  (Reported by Dan
-   Nicolaescu.)  
-
-   Update: selecting a region with the mouse enables single_kboard
-   under X.  This is very confusing.
-
-   Update: After discussions with Richard Stallman, this will be
-   resolved by having locked displays warn the user to wait, and
-   introducing a complex protocol to remotely bail out of
-   single-kboard mode by pressing C-g.
-
-   Update: Warning the user is not trivial to implement, as Emacs has
-   only one echo area, shared by all frames.  Ideally the warning
-   should not be displayed on the display that is locking the others.
-   Perhaps the high probability of user confusion caused by
-   single_kboard mode deserves a special case in the display code.
-   Alternatively, it might be good enough to signal single_kboard mode
-   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:
-
-	#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.
-
-** rif->flush_display_optional (NULL) calls should be replaced by a
-   new global function.
-
-** The set-locale-environment hack (adding the DISPLAY option) should
-   be replaced with a clean design.
-
-** standard-display-table should be display-local.
-   standard-display-european should be display-local.
-
-** With iswitchb-default-method set to 'always-frame, only frames on
-   the current display should be considered.  This might involve
-   extending `get-buffer-window'.
-
-** Have a look at Vlocale_coding_system.  Seems like it would be a
-   tedious job to localize it, although most references use it for
-   interfacing with libc and are therefore OK with the global
-   definition.
-
-   Exceptions found so far: x-select-text and
-   x-cut-buffer-or-selection-value.
-
-** Have a look at fatal_error_hook.
-
-** Have a look at set_frame_matrix_frame.
-
-** Check if we got term-setup-hook right.
-
-** I think tip_frame should be display-local.
-
-** Check display reference count handling in x_create_tip_frame.
-
-** make-frame does not correctly handle extra parameters in its
-   argument:
-
-	(frame-parameter (make-frame (list (cons 'foobar 42))) 'foobar)
-		=> nil
-
-   (This is likely an error in the CVS trunk.)
-
-** Dan Nicolaescu suggests that -nw should be added as an alias for -t
-   in emacsclient.  Good idea.  (Alas, implementing this is not
-   trivial, getopt_long does not seem to support two-letter ``short''
-   options.  Patches are welcome.)
-
-** Mark Plaksin suggests that emacsclient should accept the same
-   X-related command-line arguments as Emacs.  Most of the X-related
-   argument-handling is done in Lisp, so this should be quite easy to
-   implement.  (For example, Samium Gromoff wants emacsclient to
-   support --geometry; implementing this would add that support.)
-
-** Gergely Nagy suggests that C-x # should only kill the current
-   frame, not any other emacsclient frame that may have the same file
-   opened for editing.  I think I agree with him.
-
-** Very strange bug: visible-bell does not work on secondary
-   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
-   an initial frame.  (The user would connect to it and open frames
-   later, with emacsclient.)
-
-** Fix Mac support (I can't do this entirely myself).  Note that the
-   current state of Mac-specific source files in the multi-tty tree
-   are not useful; before starting work on Mac support, revert to
-   pristine, pre-multi-tty versions.
-
-** Fix DOS support (I can't do this entirely myself).  Note that the
-   current state of DOS-specific source files in the multi-tty tree
-   are not useful; before starting work on DOS support, revert to
-   pristine, pre-multi-tty versions.
-
-** Fix Windows support. Currently bootstraping works on w32, but Emacs
-   crashes on startup and none of the multi-tty features are
-   implemented. Many XXX comments mark things that probably need
-   updating, ChangeLogs will help in spotting changes to X specific
-   files that may need porting.
-
-** Do a grep on XXX and ?? for more issues.
-
-** flow-ctrl.el must be updated.
-
-** Fix stuff_char for multi-tty.  Doesn't seem to be of high priority.
-
-DIARY OF CHANGES
-----------------
-
-(ex-TODO items with explanations.)
-
--- Introduce a new struct for terminal devices.
-
-   (Done, see struct tty_output.  The list of members is not yet
-   complete.)
-
--- Change the bootstrap procedure to initialize tty_list.
-
-   (Done, but needs review.)
-
--- Change make-terminal-frame to support specifying another tty.
-
-   (Done, new frame parameters: `tty' and `tty-type'.)
-
--- Implement support for reading from multiple terminals.
-
-   (Done, read_avail_input tries to read from each terminal, until one
-   succeeds.  MULTI_KBOARD is not used.  Secondary terminals don't send
-   SIGIO!)
-
-   (Update: They do, now.)
-
-   (Update2: After enabling X, they don't.)
-
--- other-frame should cycle through the frames on the `current'
-   terminal only.
-
-   (Done, by trivially modifiying next_frame and prev_frame.)
-
--- Support different terminal sizes.
-
-   (Done, no problem.)
-
--- Make sure terminal resizes are handled gracefully.  (Could be
-   problematic.)
-
-   (Done.  We don't get automatic SIGWINCH for additional ttys,
-   though.)
-
--- Extend emacsclient to automatically open a new tty when it connects
-   to Emacs.
-
-   (Done.  It's an ugly hack, needs more work.)
-
--- Redisplay must refresh the topmost frame on *all* terminals, not
-   just the initial terminal.
-
-   (Done, but introduced an ugly redisplay problems.  Ugh.)
-
--- Fix redisplay problems.
-
-   (Done; it turned out that the entire Wcm structure must be moved
-   inside tty_output.  Why didn't I catch this earlier?)
-
--- Provide a way for emacsclient to tell Emacs that the tty has been
-   resized.
-
-   (Done, simply forward the SIGWINCH signal.)
-
--- Each keypress should automatically select the frame corresponding
-   to the terminal that it was coming from.  This means that Emacs
-   must know from which terminal the last keyboard event came from.
-
-   (Done, it was quite simple, the input event system already
-   supported multiple frames.)
-
--- Fix SIGIO issue with secondary terminals.
-
-   (Done, emacsclient signals Emacs after writing to the proxy pseudo
-   terminal.  Note that this means that multi-tty does not work with
-   raw ttys!)
-
-   (Update: This is bullshit.  There is a read_input_waiting function,
-   extend that somehow.)
-
-   (Update of update: The first update was not right either, extending
-   read_input_waiting was not necessary.  Secondary ttys do seem to
-   send signals on input.)
-
-   (Update^3: Not any more.)
-
--- Make make-terminal-frame look up the `tty' and `tty-type' frame
-   parameters from the currently selected terminal before the global
-   default.
-
-   (Done.)
-
--- Put all cached terminal escape sequences into struct tty_output.
-   Currently, they are still stored in global variables, so we don't
-   really support multiple terminal types.
-
-   (Done.  It was not fun.)
-
--- Implement sane error handling after initialization.  (Currently
-   emacs exits if you specify a bad terminal type.)  The helpful error
-   messages must still be provided when Emacs starts.
-
-   (Done.)
-
--- Implement terminal deletion, i.e., deleting local frames, closing
-   the tty device and restoring its previous state without exiting
-   Emacs.
-
-   (Done, but at the moment only called when an error happens during
-   initialization.  There is a memory corruption error around this
-   somewhere.)  (Update: now it is fully enabled.)
-
--- Implement automatic deletion of terminals when the last frame on
-   that terminal is closed.
-
-   (Done.)
-
--- Restore tty screen after closing the terminal.
-
-   (Done, we do the same as Emacs 21.2 for all terminals.)
-
--- 'TERM=dumb src/emacs' does not restore the terminal state.
-
-   (Done.)
-
--- C-g should work on secondary terminals.
-
-   (Done, but the binding is not configurable.)
-
--- Deal with SIGHUP in Emacs and in emacsclient.  (After this, the
-   server-frames may be removed from server.el.)
-
-   (Done, nothing to do.  It seems that Emacs does not receive SIGHUP
-   from secondary ttys, which is actually a good thing.)  (Update: I
-   think it would be a bad idea to remove server-frames.)
-
--- Change emacsclient/server.el to support the -t argument better,
-   i.e. automatically close the socket when the frame is closed.
-
-   (Seems to be working OK.)
-
--- Fix mysterious memory corruption error with tty deletion.  To
-   trigger it, try the following shell command:
-
-	while true; do TERM=no-such-terminal-definition emacsclient -h; done
-
-   Emacs usually dumps core after a few dozen iterations.  (The bug
-   seems to be related to the xfreeing or bzeroing of
-   tty_output.Wcm.  Maybe there are outside references to struct Wcm?
-   Why were these vars collected into a struct before multi-tty
-   support?)
-
-   (Done.  Whew.  It turned out that the problem had nothing to do
-   with hypothetical external references to Wcm, or any other
-   tty_output component; it was simply that delete_tty closed the
-   filehandles of secondary ttys twice, resulting in fclose doubly
-   freeing memory.  Utterly trivial matter.  I love the C's memory
-   management, it puts hair on your chest.)
-
--- Support raw secondary terminals.  (Note that SIGIO works only on
-   the controlling terminal.) Hint: extend read_input_waiting for
-   multiple ttys and hopefully this will be fixed.
-
-   (Done, it seems to have been working already for some time.  It
-   seems F_SETOWN does work, after all.  Not sure what made it fail
-   earlier, but it seems to be fixed (there were several changes
-   around request_sigio, maybe one of them did it).
-   read_input_waiting is only used in sys_select, don't change
-   it.)  (Update: After adding X support, it's broken again.)
-   (Update^2: No it isn't.) :-)
-
--- Find out why does Emacs abort when it wants to close its
-   controlling tty.  Hint: chan_process[] array.  Hey, maybe
-   noninterrupt-IO would work, too?  Update: no, there is no process
-   for stdin/out.
-
-   (Done.  Added add/delete_keyboard_wait_descriptor to
-   term_init/delete_tty.  The hint was right, in a way.)
-
--- Issue with SIGIO: it needs to be disabled during redisplay.  See if
-   fcntl kernel behaviour could be emulated by emacsclient.
-
-   (Done.  Simply disabled the SIGIO emulation hack in emacsclient.)
-   (Update: it was added back.)  (Update^2: and removed again.)
-
--- server.el: There are issues with saving files in buffers of closed
-   clients.  Try editing a file with emacsclient -f, and (without
-   saving it) do a delete-frame.  The frame is closed without
-   question, and a surprising confirmation prompt appears in another
-   frame.
-
-   (Done.  delete-frame now asks for confirmation if it still has
-   pending buffers, and modified buffers don't seem to be deleted.)
-
--- emacsclient.el, server.el: Handle eval or file open errors when
-   doing -t.
-
-   (Done.)
-
--- Make parts of struct tty_output accessible from Lisp.  The device
-   name and the type is sufficient.
-
-   (Done, see frame-tty-name and frame-tty-type.)
-
--- Export delete_tty to the Lisp environment, for emacsclient.
-
-   (Done, see delete-tty.)
-
--- Get rid of the accessor macros in termchar.h, or define macros for
-   all members.
-
-   (Done.)
-
--- Move device-specific parameters (like costs) commonly used by
-   device backends to a common, device-dependent structure.
-
-   (Done.  See struct display_method in termhooks.h.)
-
--- Fix X support.
-
-   (Done.  Well, it seems to be working.)
-
--- Allow simultaneous X and tty frames.  (Handling input could be
-   tricky.  Or maybe not.)
-
-   (Done.  Allowed, that is.  It is currently extremely unstable, to
-   the point of being unusable.  The rif variable causes constant
-   core dumps.  Handling input is indeed tricky.)
-
--- Rewrite multi-tty input in terms of MULTI_KBOARD.
-
-   (Done.  In fact, there was no need to rewrite anything, I just
-   added a kboard member to tty_display_info, and initialized the
-   frame's kboard from there.)
-
--- Fix rif issue with X-tty combo sessions.  IMHO the best thing to do
-   is to get rid of that global variable (and use the value value in
-   display_method, which is guaranteed to be correct).
-
-   (Done, did exactly that.  Core dumps during combo sessions became
-   much rarer.  In fact, I have not yet met a single one.)
-
--- Add multi-tty support to talk.el.
-
-   (Done.)
-
--- Clean up the source of emacsclient.  It is a mess.
-
-   (Done, eliminated stupid proxy-pty kludge.)
-
--- Fix faces on tty frames during X-tty combo sessions.  There is an
-   init_frame_faces call in init_sys_modes, see if there is a problem
-   with it.
-
-   (Done, there was a stupid mistake in
-   Ftty_supports_face_attributes_p. Colors are broken, though.)
-
--- C-x 5 2, C-x 5 o, C-x 5 0 on an emacsclient frame unexpectedly
-   exits emacsclient.  This is a result of trying to be clever with
-   delete-frame-functions.
-
-   (Fixed, added delete-tty-after-functions, and changed server.el to
-   use it.)
-
--- Something with (maybe) multi-keyboard support broke function keys
-   and arrows on ttys during X+tty combo sessions.  Debug this.
-
-   (I can't reproduce it, maybe the terminal type was wrong.)
-
--- Fix input from raw ttys (again).
-
-   (Now it seems to work all right.)
-
--- During an X-tty combo session, a (message "Hello") from a tty frame
-   goes to the X frame.  Fix this.
-
-   (Done.  There was a safeguard against writing to the initial
-   terminal frame during bootstrap which prevented echo_area_display
-   from working correctly on a tty frame during a combo session.)
-
--- If there are no frames on its controlling terminal, Emacs should
-   exit if the user presses C-c there.
-
-   (Done, as far as possible.  See the SIGTERM comment in
-   interrupt_signal on why this seems to be impossible to solve this
-   in general.)
-
--- During an X session, Emacs seems to read from stdin.  Also, Emacs
-   fails to start without a controlling tty.
-
-   (Fixed by replacing the troublesome termcap display with a dummy
-   bootstrap display during bootstrap.
-
--- Do tty output through struct display, like graphical display
-   backends.
-
-   (Done.)
-
--- Define an output_initial value for output_method for the initial
-   frame that is dumped with Emacs.  Checking for this frame (e.g. in
-   cmd_error_internal) is ugly.
-
-   (Done, breaking interactive temacs.)
-
--- The command `emacsclient -t -e '(delete-frame)'' fails to exit.
-
-   (Fixed.)
-
--- frame-creation-function should always create a frame that is on the
-   same display as the selected frame.  Maybe frame-creation-function
-   should simply be removed and make-frame changed to do the right
-   thing.
-
-   (Done, with a nice hack.  frame-creation-function is now frame-local.)
-
--- Fix C-g on raw ttys.
-
-   (Done.  I disabled the interrupt/quit keys on all secondary
-   terminals, so Emacs sees C-g as normal input.  This looks like an
-   overkill, because emacsclient has extra code to pass SIGINT to
-   Emacs, so C-g should remain the interrupt/quit key on emacsclient
-   frames.  See the next entry why implementing this distinction would
-   be a bad idea.)
-
--- Make sure C-g goes to the right frame with ttys.  This is hard, as
-   SIGINT doesn't have a tty parameter. :-(
-
-   (Done, the previous change fixes this as a pleasant side effect.)
-
--- I have seen a case when Emacs with multiple ttys fell into a loop
-   eating 100% of CPU time.  Strace showed this loop:
-
-	getpid()                                = 30284
-	kill(30284, SIGIO)                      = 0
-	--- SIGIO (I/O possible) @ 0 (0) ---
-	ioctl(6, FIONREAD, [0])                 = -1 EIO (Input/output error)
-	ioctl(5, FIONREAD, [0])                 = -1 EIO (Input/output error)
-	ioctl(0, FIONREAD, [0])                 = 0
-	sigreturn()                             = ? (mask now [])
-	gettimeofday({1072842297, 747760}, NULL) = 0
-	gettimeofday({1072842297, 747806}, NULL) = 0
-	select(9, [0 3 5 6], NULL, NULL, {0, 0}) = 2 (in [5 6], left {0, 0})
-	select(9, [0 3 5 6], NULL, NULL, {0, 0}) = 2 (in [5 6], left {0, 0})
-	gettimeofday({1072842297, 748245}, NULL) = 0
-
-   I have seen something similar with a single X frame, but have not
-   been able to reproduce it for debugging.
-
-   Update: This may have been caused by checking for nread != 0
-   instead of nread > 0 after calling read_socket_hook in
-   read_avail_input.
-
-   (Fixed.  This was caused by unconditionally including stdin in
-   input_wait_mask in init_process.  The select call in
-   wait_reading_process_input always returned immediately, indicating
-   that there is pending input from stdin, which nobody read.
-
-   Note that the above strace output seems to be an unrelated but
-   similar bug.  I think that is now fixed.)
-
--- Exiting Emacs while there are emacsclient frames doesn't restore the
-   ttys to their default states.
-
-   (This seems to be fixed by some previous change.)
-
--- Allow opening an X session after -nw.
-
-   (Done.)
-
--- Fix color handling during tty+X combo sessions.  (It seems that tty
-   sessions automatically convert the face colors to terminal colors
-   when the face is loaded.  This conversion must happen instead on
-   the fly in write_glyphs, which might be problematic, as color
-   approximation is currently done in lisp (term/tty-colors.el).)
-   (Update: hm, colors seem to work fine if I start emacs with -nw and
-   then create an X frame.  Maybe it's just a small buglet somewhere.)
-
-   (Seems to be fixed.  The problem was in startup.el, it did not
-   initialize tty colors when the initial window system was
-   graphical.)
-
--- emacs -nw --eval '(y-or-n-p "Foobar")' segfaults.  (Reported by
-   Romain Francoise)
-
-   (Fixed, there was a keyboard initialization problem.)
-
--- Fix interactive use of temacs.  There are face-related SEGVs, most
-   likely because of changes in realize_default_face, realize_face.
-
-   (Fixed.)
-
--- Don't exit Emacs when the last X connection fails during a
-   multi-display session.
-
-   (Fixed.)
-
--- Dan Nicolaescu noticed that starting emacsclient on the same
-   terminal device that is the controlling tty of the Emacs process
-   gives unexpected results.
-
-   (Fixed.)
-
--- Istvan Marko reported that Emacs hang on ttys if it was started
-   from a shell script.
-
-   (Fixed.  There was a bug in the multi-tty version of
-   narrow_foreground_group.  tcsetpgrp blocks if it is called from a
-   process that is not in the same process group as the tty.)
-
--- emacsclient -t from an Emacs term buffer does not work, complains
-   about face problems.  This can even lock up Emacs (if the recursive
-   frame sets single_kboard).  Update: the face problems are caused by
-   bugs in term.el, not in multi-tty.  The lockup is caused by
-   single_kboard mode, and is not easily resolvable.  The best thing to
-   do is to simply refuse to create a tty frame of type `eterm'.
-
-   (Fixed, changed emacsclient to check for TERM=eterm.  The face
-   complaints seem to be caused by bugs in term.el; they are not
-   related to multi-tty.)
-
--- Find out the best way to support suspending Emacs with multiple
-   ttys.  My guess: disable it on the controlling tty, but from other
-   ttys pass it on to emacsclient somehow.  (It is (I hope) trivial to
-   extend emacsclient to handle suspend/resume.  A `kill -STOP' almost
-   works right now.)
-
-   (Done.  I needed to play with signal handling and the server
-   protocol a bit to make emacsclient behave as a normal UNIX program
-   wrt foreground/background process groups.)
-
--- There is a flicker during the startup of `emacs -nw'; it's as if
-   the terminal is initialized, reset and then initialialized again.
-   Debug this.  (Hint: narrow_foreground_group is called twice during
-   startup.)
-
-   (This is gone.)
-
--- Robert Chassell has found serious copy-paste bugs with the
-   multi-tty branch.  There seem to be redisplay bugs while copying
-   from X to a terminal frame.  Copying accented characters do not
-   work for me.
-
-   (Patch-124 should fix this, by changing the interprogram-*-function
-   variables to be frame-local, as suggested by Mark Plaksin
-   (thanks!).  I think that the redisplay bugs are in fact not bugs,
-   but delays caused by single_kboard --> perhaps MULTI_KBOARD should
-   be removed.)
-
--- frame-creation-function was removed, which might be a bad idea.
-   Think up a compatible solution.
-
-   (It was an internal interface that may be changed when necessary.)
-
--- Change Lisp code not to (getenv "TERM"); use the `tty-type' frame
-   parameter or the frame-tty-type function instead.  (M-x tags-search
-   "TERM" helps with this.)  Update: Actually, all getenv invocations
-   should be checked for multi-tty compatibility, and an interface
-   must be implemented to get the remote client's environment.
-
-   (Done.  Only getenv calls in lisp/term/*.el were changed; other
-   calls should be mostly left as they are.)
-
--- Add an elaborate mechanism for display-local variables.  (There are
-   already a few of these; search for `terminal-local' in the Elisp
-   manual.)
-
-   (Not needed.  Display-local variables could be emulated by
-   frame-local variables.)
-
--- Emacs assumes that all terminal frames have the same locale
-   settings as Emacs itself.  This may lead to bogus results in a
-   multi-locale setup. (E.g., while logging in from a remote client
-   with a different locale.)
-   (Update after new bugreport by Friedrich Delgado Friedrichs: 
-   (at least) the structs terminal_coding and keyboard_coding in
-   coding.c must be moved to struct display, and the Lisp interface
-   [set-]keyboard-coding-system must be adapted for the change.)
-
-   (Fixed.  Emacs now uses the locale settings as seen by the
-   emacsclient process for server tty frames.)
-   (Update: Not really; Vlocale_coding_system is still global.)
-
--- Make `struct display' accessible to Lisp programs.  Accessor functions:
-
-	(displayp OBJECT):  Returns t if OBJECT is a display.
-		=> Implemented as display-live-p.
-
-	(display-list):  Returns list of currently active displays.
-		=> Implemented.
-
-	(selected-display):  Returns the display object of the selected frame.
-		=> Not strictly necessary, but implemented anyway.
-
-	(frame-display FRAME):  Returns the display object of FRAME.
-	        => Implemented.
-
-	(display-frames DISPLAY):  Returns a list of frames on DISPLAY.
-		=> Already implemented, see frames-on-display-list.
-
-	(display-type DISPLAY):  Returns the type of DISPLAY, as a
-		symbol.  (See `framep'.)
-		=> Implemented as display-live-p.
-
-	(display-device DISPLAY): Returns the name of the device that
-		DISPLAY uses, as a string.  (E.g: "/dev/pts/16", or
-		":0.0")
-		=> Implemented as display-name.
-
-	etc.
-
-   See next issue why this is necessary.
-
-   (Update: The consensus on emacs-devel seems to be to do this via
-   integer identifiers.  That's fine by me.)
-
-   (Done.)
-
--- The following needs to be supported:
-
-	$ emacsclient -t
-		C-z
-	$ emacsclient -t
-		(This fails now.)
-
-   The cleanest way to solve this is to allow multiple displays on the
-   same terminal device; each new emacsclient process should create
-   its own display.  As displays are currently identified by their
-   device names, this is not possible until struct display becomes
-   accessible as a Lisp-level object.
-
-   (Done.)
-
--- Miles Bader suggests that C-x C-c on an emacsclient frame should
-   only close the frame, not exit the entire Emacs session.  Update:
-   see above for a function that does this.  Maybe this should be the
-   new default?  
-
-   (Done.  This is the new default.  No complaints so far.)
-
--- Clean up the frame-local variable system.  I think it's ugly and
-   error-prone.  But maybe I just haven't yet fully understood it.
-
-   (Nothing to do.  It doesn't seem ugly any more.  It's rather clever.)
-
--- Support multiple character locales.  A version of
-   `set-locale-environment' needs to be written for setting up
-   display-local settings on ttys.  I think calling
-   set-display-table-and-terminal-coding-system and
-   set-keyboard-coding-system would be enough.  The language
-   environment itself should remain a global setting.
-
-   (Done, by an ugly hack.)
-
--- The terminal customization files in term/*.el tend to change global
-   parameters, which may confuse Emacs with multiple displays.  Change
-   them to tweak only frame-local settings, if possible.  (They tend
-   to call define-key to set function key sequences a lot.)
-
-   (Done, by making `function-key-map' terminal-local (i.e., part of
-   struct kboard).  This has probably covered all the remaining problems.)
-
--- Make `function-key-map' and `key-translation-map' terminal-local.
-
-   (Done.)
-
--- Implement `terminal-local-value' and `set-terminal-local-value' to
-   allow deterministic access to terminal local bindings.  The
-   encode-kb package can not set up `key-translation-map' without
-   these.  The terminal-local bindings seem to be independent of what
-   frame is selected.
-
-   (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.)  
-
-   (Update: this bug was fixed for good in patch-449.  It was tracked
-   down to a bug in `read_key_sequence': it failed to reinitialize its
-   local function-key-map/key-translation-map references when it
-   switched keyboards.  I don't understand why did this bug only
-   appear on brand new frames, though!)
-
--- Disable connecting to a new X display when we use the GTK toolkit.
-
-   (Disabled in patch-450.)
-
--- Implement automatic forwarding of client environment variables to
-   forked processes, as discussed on the multi-tty list.  Terminal
-   parameters are now accessible in C code, so the biggest obstacle is
-   gone.  The `getenv_internal' and `child_setup' functions in
-   callproc.c must be changed to support the following variable:
-
-	terminal-local-environment-variables is a variable defined in ...
-
-	Enable or disable terminal-local environment variables.
-
-	If set to t, `getenv', `setenv' and subprocess creation
-	functions use the environment variables of the emacsclient
-	process that created the selected frame, ignoring
-	`process-environment'.
-
-	If set to nil, Emacs uses `process-environment' and ignores
-	the client environment.
-
-	Otherwise, `terminal-local-environment-variables' should be a
-	list of variable names (represented by Lisp strings) to look
-	up in the client environment.  The rest will come from
-	`process-environment'.
-
-   (Implemented in patch-461; `terminal-getenv', `terminal-setenv' and
-   `with-terminal-environment' are now replaced by extensions to
-   `getenv' and `setenv', and the new `local-environment-variables'
-   facility.  Yay!)
-
-   (Updated in patch-465 to fix the semantics of let-binding
-   `process-environment'.  `process-environment' was changed to
-   override all local/global environment variables, and a new variable
-   `global-environment' was introduced to have `process-environment's
-   old meaning.)
-
-   (Updated in patch-466 to fix the case when two emacsclient sessions
-   share the same terminal, but have different environment.  The local
-   environment lists are now stored as frame parameters, so the
-   C-level terminal parameters are not strictly necessary any more.)
-
--- `Fdelete_frame' is called from various critical places where it is
-   not acceptable for the frame deletion to fail, e.g. from
-   x_connection_closed after an X error.  `Fdelete_frame' now protects
-   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.)
-
--- `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.
-
-   (Done in patch-537.)
-
--- The `default-directory' variable should somehow be set to the
-   cwd of the emacsclient process when the user runs emacsclient
-   without file arguments.  Perhaps it is OK to just override the
-   directory of the *scratch* buffer.
-
-   (Done in patch-539.)
-
--- The borders on tooltip frames on X are messed up.  More
-   specifically, the frame's internal border (internal-border-width
-   frame parameter) is not filled with the correct background color.
-
-   It seems the border contents are drawn onto by the
-   update_single_window call in `x-show-tip'.  After some debugging, I
-   think the window's background color is not set up
-   correctly---calling `x_clear_area' fills the specified area with
-   black, not light yellow.
-
-   (Done in patch-544.  A background_pixel field was defined both in
-   struct frame and struct x_output, and Emacs got confused between
-   them.)
-
-;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
-