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
and check their messages without opening a remote X frame or resorting
to gnus-slave.
-
WHO IS DOING IT
---------------
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
------
-Multi-tty support is stable, I think most of the problems were fixed.
-(It still needs testing on other architectures, though.) Simultaneous
-X and tty frame support works fine, although there are some small
-issues. 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 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
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.
-Problems:
+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.)
- * Suspending Emacs is disabled if there are multiple tty
- devices. Also, there is no way to suspend emacsclient. This
- will be fixed.
+Problems:
* 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).
+ 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. 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 an earlier version of my
+patches.
CHANGELOG
---------
THINGS TO DO
------------
-** Robert J. Chassell reports:
+** 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)?
- > * 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.
+** 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.)
-** emacs -nw --eval '(y-or-n-p "Foobar")' segfaults.
+** 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.)
-** Fix interactive use of temacs. There are face-related SEGVs, most
- likely because of changes in realize_default_face, realize_face.
+** 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.
+
+** 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.
+
+** 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. This might be something xterm (konsole) specific.
+ terminals in xterm and konsole. The screen does flicker a bit,
+ but it's so quick it isn't noticable.
-** 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.)
+** 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
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.)
+
+
+
;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
HCoop / bpt / emacs.git / blobdiff