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
---------------
http://lorentey.web.elte.hu/project/emacs.html
+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
------
-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.
+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
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 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
---------
THINGS TO DO
------------
-** 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.)
+** 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 interactive use of temacs. There are face-related SEGVs, most
- likely because of changes in realize_default_face, realize_face.
+** 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. 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
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
(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.)
+
+
+-- 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
HCoop / bpt / emacs.git / blobdiff