- -*- coding: utf-8; -*-
+ -*- coding: utf-8; mode: text; -*-
GOAL
----
-The ultimate goal of this branch is to implement support for opening
-multiple, different tty devices and simultaneous X and tty frames from
-a single Emacs session.
+The goal of this branch is to implement 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.
-Patches or suggestions are welcome!
+Comments, bug reports, suggestions and patches are welcome!
Retrieving the latest version of the branch:
tla register-archive lorentey@elte.hu--2004 http://lorentey.web.elte.hu/arch/2004/
- tla get lorentey@elte.hu--2004/emacs--multi-tty--0 <directory>
+ tla get lorentey@elte.hu--2004/emacs--multi-tty <directory>
+
+(I use a recent arch development snapshot, but any of the released
+versions of arch will do fine, I think.)
+
+If you don't have arch, the branch has a homepage from which you can
+download conventional patches against Emacs CVS HEAD:
+
+ http://lorentey.web.elte.hu/project/emacs.html
-(I use tla 1.1.)
+If you want to be notified of new revisions, sign up to the
+multi-tty@listbox.elte.hu mailing list by visiting the
+below homepage and following its instructions.
+ https://listbox.elte.hu/mailman/listinfo/multi-tty
+
+Please note that the multi-tty mailing list is read-only, and is
+reserved for automatic commit messages. Discussion about the branch
+and bug reports should be sent directly to me (lorentey@elte.hu), or
+to the emacs-devel@gnu.org mailing list. (I hope to merge my branch
+into CVS HEAD reasonably soon, so I don't want to set up an elaborate
+development infrastructure for the multi-tty branch.)
STATUS
------
-Basic multi-tty support is there; there are some rough edges, but it
-already seems to be usable. Emacsclient has been extended to support
-opening a new terminal frame.
+The branch is now very stable and almost full-featured. I hope the
+major problems were fixed. (It still needs testing on other
+architectures, 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.
+
+Please let me know if you find any bugs in this branch.
-To try it out, compile Emacs with the following commands
+HOW TO COMPILE AND TEST
+-----------------------
+
+To try out the multi-tty branch, compile and run the multi-tty branch
+with the following commands:
mkdir +build
cd +build
- ../configure --with-x-toolkit=no --without-x
+ ../configure <your favourite options>
make bootstrap
+ src/emacs -nw # You can also try without -nw
+ M-x server-start
+
+and then (from a shell prompt on another terminal) start emacsclient
+with
+ lib-src/emacsclient /optional/file/names...
+or
+ lib-src/emacsclient -t /optional/file/names...
+
+You'll hopefully have two fully working, independent frames on
+separate terminals. The new frame is closed automatically when you
+have finished 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. You should
+always run emacs from gdb, so that you'll have a live instance to
+debug if something goes wrong. Please send me your bug reports.
+
+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. This way 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. As long as the server that runs
+your Emacs remains up, all your buffers remain exactly as they were
+before the crash, and you can continue working as if nothing had
+happened. (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 am thinking about introducing a --daemon option to get rid of the
+above screen dependency.)
+
+Problems:
+
+ * Suspending Emacs is disabled if there are multiple tty
+ devices. Also, there is no way to suspend emacsclient. This
+ will be fixed.
+
+ * Mac, Windows and DOS support is broken, probably doesn't
+ even compile -- this will be solved later.
+
+ * Only tested on my GNU/Linux box and on Solaris 8.
+
+NEWS
+----
-then start up the emacs server (src/emacs, M-x server-start), and then
-(from a shell prompt on another terminal) start emacsclient with
+For the NEWS file:
- lib-src/emacsclient -h
+** Support for multiple terminal devices has been added.
-You'll hopefully have two fully working frames on separate terminals.
-If you exit emacs, both terminals should be restored to their previous
-states. You can close the newly opened frame and return to the shell
-without exiting Emacs with C-x 5 0, i.e., delete-frame.
+*** 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.
-X, Mac, Windows and DOS support is broken, probably doesn't even
-compile -- this will be solved later.
+*** A make-frame-on-tty function has been added to make it easier to
+ create frames on new terminals.
-Tested under GNU/Linux only.
+*** New functions: frame-tty-name, frame-tty-type for accessing
+ terminal parameters, and delete-tty for closing the terminal
+ device.
-NEWS
-----
+*** talk.el has been extended for multiple tty support.
-For the NEWS file:
-** 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'. `tty' must be a
- terminal device created by the updated emacsclient, or there will
- be problems with terminal input and window resizes. (The kernel
- notifies processes about pending input or terminal resizes only on
- the controlling terminal, so we need emacsclient to sit on the real
- terminal device, create SIGIO signals upon terminal input, and
- forward SIGWINCH signals to us.)
+** Support for simultaneous graphical and terminal frames has been
+ added.
- You can test for the presence of multiple terminal support by
- testing for the `multi-tty' feature.
+*** The function `make-frame-on-display' now works during a terminal
+ session, and `make-frame-on-tty' works during a graphical session.
-** A make-frame-on-tty function has been added to make it easier to
- create frames on new terminals.
+*** The `window-system' variable has been made frame-local.
-** Emacsclient has been extended to support opening a new terminal
- frame.
+*** The new `initial-window-system' variable contains the
+ `window-system' value for the first frame.
+
+THANKS
+------
+
+The following is an (incomplete) list of people who have contributed
+to the project by testing, bug reports, and suggestions. Thanks!
+
+Robert J. Chassel <bob at rattlesnake dot com>
+Romain Francoise <romain at orebokech dot com>
+Ami Fischman <ami at fischman dot org>
+Istvan Marko <mi-mtty ar kismala dot com>
+Dan Nicolaescu <dann at ics dot uci dot edu>
+Mark Plaksin <happy at mcplaksin dot org>
+
+Richard Stallman was kind enough to review my patches.
CHANGELOG
---------
See arch logs.
+THINGS TO DO
+------------
+
+** 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.)
+
+** 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.)
+
+** 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.
+
+** Make `struct display' accessible to Lisp programs. Accessor functions:
+
+ (displayp OBJECT): Returns t if OBJECT is a display.
+
+ (selected-display): Returns the display object of the selected frame.
+
+ (frame-display FRAME): Returns the display object of FRAME.
+
+ (display-frames DISPLAY): Returns a list of frames on DISPLAY.
+
+ (display-type DISPLAY): Returns the type of DISPLAY, as a
+ symbol. (See `framep'.)
+
+ (display-device DISPLAY): Returns the name of the device that
+ DISPLAY uses, as a string. (E.g: "/dev/pts/16", or
+ ":0.0")
+
+ See next issue why this is necessary.
+
+** The following needs to be supported:
+
+ $ emacsclient -t
+ C-z
+ $ bg
+ $ 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.
+
+** Add an elaborate mechanism for display-local variables. (There are
+ already a few of these; search for `terminal-local' in the Elisp
+ manual.)
+
+** 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 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 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 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 seems complicated) :-)
+ What 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 abstraction for terminal devices.
+-- Introduce a new struct for terminal devices.
- (Done, see struct tty_output. The abstraction is not yet
+ (Done, see struct tty_output. The list of members is not yet
complete.)
-- Change the bootstrap procedure to initialize tty_list.
-- Implement support for reading from multiple terminals.
(Done, read_avail_input tries to read from each terminal, until one
- succeeds. MULTIKBOARD is not used. Secondary terminals don't send
+ 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.
+ 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
-- 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.
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, but at the moment only called when an error happens during
initialization. There is a memory corruption error around this
- somewhere.)
+ 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.
-THINGS TO DO
-------------
+ (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.
-** Fix mysterious memory corruption error with tty deletion. To
+ (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 xfree()ing or bzero()ing of
- tty_output.Wcm or some other tty_output part. Maybe there are
- outside references to struct Wcm? Why were these vars collected
- into a struct before multi-tty support?)
+ 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.)
+
+-- 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.)
+
+-- 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.
- The bug does not seem to happen if the error occurs before terminal
- initialization or if I comment out all xfree()s in delete_frame.
- Update: yes it does, although it is much rarer. Or maybe it's
- another bug.
+ (Done. delete-frame now asks for confirmation if it still has
+ pending buffers, and modified buffers don't seem to be deleted.)
-** Change emacsclient/server.el to support the -h argument better,
- i.e. automatically close the socket when the frame is closed.
+-- emacsclient.el, server.el: Handle eval or file open errors when
+ doing -t.
-** Export delete_tty to the Lisp environment, for emacsclient.
+ (Done.)
-** Restore tty screen after closing the terminal.
+-- Make parts of struct tty_output accessible from Lisp. The device
+ name and the type is sufficient.
-** 'TERM=dumb src/emacs' does not restore the terminal state.
+ (Done, see frame-tty-name and frame-tty-type.)
-** C-g should work on secondary terminals.
+-- Export delete_tty to the Lisp environment, for emacsclient.
-** Make parts of struct tty_output accessible from Lisp. The device
- name and the type is sufficient.
+ (Done, see delete-tty.)
-** Find out why does Emacs abort when it wants to close its
- controlling tty.
+-- Get rid of the accessor macros in termchar.h, or define macros for
+ all members.
-** Implement support for starting an interactive Emacs session without
- an initial frame. (The user would connect to it and open frames
- later, with emacsclient.) Not necessarily a good idea.
+ (Done.)
-** Support raw secondary terminals. (This one is tricky, SIGIO works
- only on the controlling terminal. The emacsclient solution works
- nicely, so this is not that important anyway.)
+-- Move device-specific parameters (like costs) commonly used by
+ device backends to a common, device-dependent structure.
-** What does interrupt_input do? I tried to disable it for raw
- secondary tty support, but it does not seem to do anything useful.
+ (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 uses 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.)
-** Move optimalization parameters (costs) from union output_data to
- a backend-neutral per-device structure.
-** Find out the best way to support suspending Emacs with multiple
- ttys.
+-- Dan Nicolaescu noticed that starting emacsclient on the same
+ terminal device that is the controlling tty of the Emacs process
+ gives unexpected results.
-** Do tty output through term_hooks, like all other display backends.
+ (Fixed.)
-** Fix X support.
+-- Istvan Marko reported that Emacs hang on ttys if it was started
+ from a shell script.
-** Allow simultaneous X and tty frames.
+ (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.)
-** Fix Mac support (I can't do this myself).
+-- 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 solvable. The best thing to
+ do is to simply refuse to create a tty frame of type `eterm'.
-** Fix W32 support (I can't do this myself).
+ (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.)
-** Fix DOS support (I can't do this myself).
+-- 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.)
;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
HCoop / bpt / emacs.git / blobdiff