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
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.
+ * Only tested on my GNU/Linux box, Solaris 8 and FreeBSD.
NEWS
----
testing for the `multi-tty' feature.
*** Emacsclient has been extended to support opening a new terminal
- frame (see -t option).
-
-*** The behaviour of Emacsclient 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.
+ 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 at rattlesnake dot com>
+Robert J. Chassell <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>
+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>
-Richard Stallman was kind enough to review my patches.
+Richard Stallman was kind enough to review an earlier version of my
+patches.
CHANGELOG
---------
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.)
+** 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)?
-** 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.)
+** 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.)
-** Robert J. Chassell reports:
+** 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.)
- > * 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.
+** 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.
-** Very strange bug: visible-bell does not work on secondary
- terminals. This might be something xterm (konsole) specific.
+** 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.
-** 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. Patches are welcome.) :-)
-** 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.
+
+** 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.
+
+** Miles Bader suggests that C-x C-c on an emacsclient frame should
+ only close the frame, not exit the entire Emacs session.
+
+** Make `struct display' accessible to Lisp programs. Accessor functions:
+
+ (displayp OBJECT): Returns t if OBJECT is a display.
+
+ (display-list): Returns list of currently active displays.
+
+ (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")
+
+ etc.
+
+ 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
** 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.)
-
-** 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'.
+** 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.
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
fcntl kernel behaviour could be emulated by emacsclient.
(Done. Simply disabled the SIGIO emulation hack in emacsclient.)
- (Update: it was added back.)
+ (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
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.
+ 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
(Fixed.)
-
-- Dan Nicolaescu noticed that starting emacsclient on the same
terminal device that is the controlling tty of the Emacs process
gives unexpected results.
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.)
+
+
+
;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
HCoop / bpt / emacs.git / blobdiff