From 9b62c83fe0e382be404036cbfff6bdebbc025130 Mon Sep 17 00:00:00 2001 From: Glenn Morris Date: Thu, 30 Aug 2007 05:12:25 +0000 Subject: [PATCH] Move here from top-level README.multi-tty, with some edits for information made out-of-date by merge to trunk. --- admin/notes/multi-tty | 1362 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1362 insertions(+) create mode 100644 admin/notes/multi-tty diff --git a/admin/notes/multi-tty b/admin/notes/multi-tty new file mode 100644 index 00000000000..5895f59bddc --- /dev/null +++ b/admin/notes/multi-tty @@ -0,0 +1,1362 @@ +-*- coding: utf-8; mode: text; -*- + +From README.multi-tty in the multi-tty branch. +Some of this information may be out of date. + + +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 +ARISAWA Akihiro +Vincent Bernat +Han Boetes +Francisco Borges +Damien Cassou +Robert J. Chassell +Romain Francoise +Ami Fischman +Noah Friedman +Friedrich Delgado Friedrichs +Samium Gromoff <_deepfire@mail.ru> +Mikhail Gusarov +Eric Hanchrow +IRIE Tetsuya +Yoshiaki Kasahara +Bas Kok +Jurej Kubelka +David Lichteblau +Richard Lewis +mace +Suresh Madhu +Xavier Mallard +Istvan Marko +Ted Morse +Gergely Nagy +Dan Nicolaescu +Kalle Olavi Niemitalo +Mark Plaksin +Frank Ruell +Tom Schutzer-Weissmann +Joakim Verona +Dan Waber +and many others. + +Richard Stallman was kind enough to review an earlier version of my +patches. + + +STATUS +------ + +It still needs to be ported to Windows/Mac/DOS. 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. + +Tested on GNU/Linux, Solaris 8, FreeBSD and OpenBSD. + +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. + + +TESTING +------- + +To test the multi-tty feature, 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. + +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 ... +# +# 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 ..." >&2 + exit 1 +fi +preload-emacs "$name" wait +/usr/bin/emacsclient.emacs-multi-tty -s "$name" "$@" +---------------------------------------------------------------------- + +-------------------------------------------------------preload-emacs-- +#!/bin/bash +# Usage: preload-emacs [] +# +# 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 []" >&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" + + +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 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.) + + +This file is part of GNU Emacs. + +GNU Emacs is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 3, or (at your option) +any later version. + +GNU Emacs is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with GNU Emacs; see the file COPYING. If not, write to the +Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, +Boston, MA 02110-1301, USA. + +;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d -- 2.39.2