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
----
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)?
+
+** 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.)
+
+** 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.)
+
+** 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.)
+ 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.
-** Very strange bug: visible-bell does not work on secondary
- terminals. This might be something xterm (konsole) specific.
+** 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.
-** 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.)
+** Miles Bader suggests that C-x C-c on an emacsclient frame should
+ only close the frame, not exit the entire Emacs session.
-** 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.
+** 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
** 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