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.
+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
------
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 a new terminal frame.
-
+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 and run the multi-tty branch 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
+ ../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
testing for the `multi-tty' feature.
*** Emacsclient has been extended to support opening a new terminal
- frame (see -t option).
+ 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.
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@rattlesnake.com>
-Romain Francoise <romain@orekobech.com>
-Ami Fischman <ami@fischman.org>
+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
---------
THINGS TO DO
------------
-** Robert J. Chassell reports:
+** 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.)
- > * After starting the frame in the VC, I saw this message in the
- > *Message* buffer
- >
- > error in process filter: server-process-filter: \
- > Wrong type argument: sequencep,\
- > framep
- > error in process filter: Wrong type argument: sequencep, framep
- >
- > This also happens when I start a new frame in an xterm.
+** 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.)
-** Very strange bug: visible-bell does not work on secondary
- terminals. This might be something xterm (konsole) specific.
+** 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.
-** 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.)
+** Make `struct display' accessible to Lisp programs. Accessor functions:
-** 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.
+ (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.) Not necessarily a good idea.
+ 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
why raw terminal support is broken again. I really do need to
understand input.)
-** 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'.
-
** Maybe standard-display-table should be display-local.
DIARY OF CHANGES
(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 solvable. 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.)
+
+
;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d