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.
HOW TO COMPILE AND TEST
-----------------------
-To try it out, compile and run the multi-tty branch with the following
-commands:
+To try out the multi-tty branch, compile and run the multi-tty branch
+with the following commands:
mkdir +build
cd +build
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.
to the project by testing, bug reports, and suggestions. Thanks!
Robert J. Chassel <bob at rattlesnake dot com>
-Romain Francoise <romain at orekobech 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
------------
-** Dan Nicolaescu (dann at ics dot uci dot edu) 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.)
-
-** Robert J. Chassell reports:
-
- > * 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.
-** Very strange bug: visible-bell does not work on secondary
- terminals. This might be something xterm (konsole) specific.
+** 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.)
-** 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.)
+** 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.)
-** 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.
+** 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.) 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.)
+-- 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
HCoop / bpt / emacs.git / blobdiff