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.
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.)
+** 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.)
-** 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.)
+** 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.)
-** Robert J. Chassell reports:
+** 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.
- > * 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.
+** Make `struct display' accessible to Lisp programs. Accessor functions:
-** Very strange bug: visible-bell does not work on secondary
- terminals. This might be something xterm (konsole) specific.
+ (displayp OBJECT): Returns t if OBJECT is a display.
-** 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.)
+ (display-list): Returns list of currently active displays.
-** 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.
+ (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
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
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.)
+
+-- 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.)
+
+
;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d