diff options
Diffstat (limited to 'README.multi-tty')
| -rw-r--r-- | README.multi-tty | 1265 |
1 files changed, 1265 insertions, 0 deletions
diff --git a/README.multi-tty b/README.multi-tty new file mode 100644 index 00000000000..2bba1b9bcb5 --- /dev/null +++ b/README.multi-tty @@ -0,0 +1,1265 @@ + -*- 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 console. +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. + +WHO IS DOING IT +--------------- + +I'm Károly Lőrentey. My address: lorentey@elte.hu. + +Comments, bug reports, suggestions and patches are welcome; send them +to multi-tty@lists.fnord.hu. + +The following is a (sadly incomplete) list of people who have +contributed to the project by testing, submitting patches, bug +reports, and suggestions. Thanks! + +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 +patches. + + +MAILING LISTS +------------- + +The multi-tty mailing list (discussion & bug reports): + + Address: multi-tty@lists.fnord.hu + Signup: http://lists.fnord.hu/mailman/listinfo/multi-tty + Archive: http://news.gmane.org/gmane.emacs.multi-tty/ + +Commit notifications (read-only): + + Address: multi-tty-commits@lists.fnord.hu + Signup: http://lists.fnord.hu/mailman/listinfo/multi-tty-commits + + +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 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 (2005), 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 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. + + * 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, Windows 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. (It is not worth to do this + yet, though.) + + +HOW TO GET THE BRANCH +--------------------- + +The branch uses GNU Arch (http://www.gnuarch.org) for version control. + +Retrieving the latest version of the branch: + + tla register-archive -f http://lorentey.hu/arch/2004/ + tla get lorentey@elte.hu--2004/emacs--multi-tty <directory> + +This incantation uses my private archive mirror that is hosted on a +relatively low-bandwidth site; if you are outside Hungary, you will +probably want to you use my secondary mirror: (Note that the -f option +will overwrite the archive location if you have previously registered +the Hungarian one.) + + tla register-archive -f http://aszt.inf.elte.hu/~lorentey/mirror/arch/2004 + tla get lorentey@elte.hu--2004/emacs--multi-tty <directory> + + http://aszt.inf.elte.hu/~lorentey/mirror/arch/2004 + +The Arch supermirror provides mirroring services for all public Arch +repositories. We have a mirror there, too, if you prefer. + + tla register-archive -f http://mirrors.sourcecontrol.net/lorentey%40elte.hu--2004 + tla get lorentey@elte.hu--2004/emacs--multi-tty <directory> + +My GPG key id is 0FB27A3F; it is available from +hkp://wwwkeys.eu.pgp.net/, or from my homepage at +http://lorentey.hu/rolam/gpg.html) + +Don't worry if the above checkout takes a few minutes to complete; +once you have a source tree, updating it to the latest revision will +be _much_ faster. Use the following command for the update: + + tla replay + +You can find more information about Arch on http://wiki.gnuarch.org/. +It's a wonderful source control system, I highly recommend it. + +If you don't have tla, the branch has a homepage from which you can +download conventional patches against Emacs CVS HEAD: + + http://lorentey.hu/project/emacs.html + +DEBIAN PACKAGES +--------------- + +If you run Debian, or a distribution based on Debian, you are welcome +to use our binary packages; put these lines in your /etc/apt/sources.list: + + # Multi-tty Emacs + deb http://aszt.inf.elte.hu/~lorentey/mirror/apt ./ + deb-src http://aszt.inf.elte.hu/~lorentey/mirror/apt ./ + +Note that these packages are intended solely to provide an easy way to +test the new multi-tty features. They are not to be taken as Emacs +releases, and it's a mistake to expect robust operation or any kind of +timely support for them. Do not install them, unless you'd like to +have your editor crash on you. + + +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 works, and they +behave 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 me your bug reports on our +mailing list: multi-tty@lists.fnord.hu + +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 arch logs. + + +NEWS +---- + +For the NEWS file: (Needs much, much work) + +** Support for multiple terminal devices has been added. + +*** You can specify a terminal device (`tty' parameter) and a terminal + type (`tty-type' parameter) to `make-terminal-frame'. + +*** You can test for the presence of multiple terminal support by + testing for the `multi-tty' feature. + +*** 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. + +*** A make-frame-on-tty function has been added to make it easier to + create frames on new terminals. + +*** 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 + terminal-local. + +** Support for simultaneous graphical and terminal frames has been + added. + +*** The function `make-frame-on-display' now works during a terminal + session, and `make-frame-on-tty' works during a graphical session. + +*** The `window-system' variable has been made frame-local. + +*** The new `initial-window-system' variable contains the + `window-system' value for the first frame. + +*** 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 +------------ + +** Report GTK multi-display problems to GTK maintainers. For extra + credit, fix them. + +** 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. + +** 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. + +** 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. + +** 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-'. + + 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 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'. + +** 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. + +** 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. + +** 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. + +** 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 W32 support (I can't do this entirely myself). Note that the + current state of W32-specific source files in the multi-tty tree + are not useful; before starting work on W32 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. + +** 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.) + +** 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, broking 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.) + +;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d + |