diff options
Diffstat (limited to 'README.multi-tty')
| -rw-r--r-- | README.multi-tty | 993 |
1 files changed, 993 insertions, 0 deletions
diff --git a/README.multi-tty b/README.multi-tty new file mode 100644 index 00000000000..1e698f3eb82 --- /dev/null +++ b/README.multi-tty @@ -0,0 +1,993 @@ + -*- 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 at mbf dot ocn dot ne dot jp> +Han Boetes <han at mijncomputer dot nl> +Robert J. Chassell <bob at rattlesnake dot com> +Romain Francoise <romain at orebokech dot com> +Ami Fischman <ami at fischman dot org> +Friedrich Delgado Friedrichs <friedel at nomaden dot org> +IRIE Tetsuya <irie at t dot email dot ne dot jp> +Yoshiaki Kasahara <kasahara at nc dot kyushu-u dot ac dot jp> +Jurej Kubelka <Juraj dot Kubelka at email dot cz> +David Lichteblau <david at lichteblau dot com> +Istvan Marko <mi-mtty at kismala dot com> +Ted Morse <morse at ciholas dot com> +Dan Nicolaescu <dann at ics dot uci dot edu> +Gergely Nagy <algernon at debian dot org> +Mark Plaksin <happy at mcplaksin dot org> +Francisco Borges <borges at let dot rug dot nl> +Frank Ruell <stoerte at dreamwarrior dot net> +Dan Waber <dwaber at logolalia dot com> +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 22). 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: + + * 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 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 the Arch supermirror instead: + + tla register-archive http://mirrors.gnuarch.org/lorentey@elte.hu--2004/ + tla get lorentey@elte.hu--2004/emacs--multi-tty <directory> + +(I use a recent tla development snapshot, but any of the released +versions of arch will do fine, I think.) 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 + + +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 functions to handle my Emacs sessions: + +,----[ ~/.bash_profile +| # 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. +| function preload-emacs { +| local name="$1" +| local waitp="$2" +| local screendir="/var/run/screen/S-$USER" +| local serverdir="/tmp/emacs$UID" +| local emacs=emacs # Or wherever you installed your multi-tty Emacs +| +| if [ -z "$name" ]; then +| echo "Usage: preload-emacs <name> [<waitp>]" >&2 +| return 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 +| return 0 +| } +| +| # 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. +| function connect-emacs { +| local name="$1" +| shift +| +| if [ -z "$name" ]; then +| echo "Usage: connect-emacs <name> <args>..." >&2 +| fi +| preload-emacs "$name" wait +| emacsclient -s "$name" "$@" +| } +| +| export -f preload-emacs connect-emacs +| +| # Preload editor and gnus sessions for speedy initial connects. +| preload-emacs editor +| preload-emacs gnus +`---- + +,----[ ~/.bashrc +| alias gnus="connect-emacs gnus" +| alias edit="connect-emacs editor" +| alias et="connect-emacs editor -t" +| alias e=edit +`---- + + +NEWS +---- + +For the NEWS file: (Needs 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 for accessing + terminal parameters, and delete-tty for closing the terminal + device. + +*** talk.el has been extended for multiple tty support. + + +** 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. + +CHANGELOG +--------- + +See arch logs. + +* * * + +(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 +------------ + +** 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, 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. 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. + +** normal-erase-is-backspace-mode in simple.el needs to be updated for + multi-tty (rep. by Dan Waber). + +** 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. + +** 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.) + +** 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)? + +** 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. + +** 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. + +** 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. + +** 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.) + +** Maybe standard-display-table should be display-local. + +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.) + + +-- 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.) + + +;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d |