Robert J. Chassell <bob@rattlesnake.com>
Romain Francoise <romain@orebokech.com>
Ami Fischman <ami@fischman.org>
+Noah Friedman <friedman@splode.com>
Friedrich Delgado Friedrichs <friedel@nomaden.org>
IRIE Tetsuya <irie@t.email.ne.jp>
Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp>
Bas Kok <nekkobassu@yahoo.com>
Jurej Kubelka <Juraj.Kubelka@email.cz>
David Lichteblau <david@lichteblau.com>
+Richard Lewis <rtf@jabble.com>
+mace <mace@kirjakaapeli.lib.hel.fi>
+Suresh Madhu <madhu@cs.unm.edu>
Xavier Mallard <zedek@gnu-rox.org>
Istvan Marko <mi-mtty@kismala.com>
Ted Morse <morse@ciholas.com>
THINGS TO DO
------------
+** See if `tty-defined-color-alist' needs to be terminal-local.
+
+** emacsclient -t on the console does not work after su. You have to
+ use non-root accounts or start as root to see this.
+
+ Login: root
+ Password:
+ # su lorentey
+ $ emacsclient -t
+ *ERROR*: Could not open file: /dev/tty1
+
+ The tty can be opened as /dev/tty by emacsclient, but not by Emacs.
+ This seems to be a serious problem. Currently my only idea is to
+ bring back the ugly pty proxy hack from the initial versions of
+ multi-tty. Suggestions would be appreciated.
+
+ Update: we could change emacsclient to pass its open file
+ descriptor to the Emacs process. Unfortunately, this requires a
+ new Lisp-level Emacs API, and as file descriptors are not otherwise
+ exported to Lisp, this approach seems at least as ugly as the pty
+ proxy idea.
+
+** lisp/vc.el depends on the terminal type during load time.
+ `vc-annotate-color-map' is one example that needs to be fixed.
+
** Understand how `quit_throw_to_read_char' works, and fix any bugs
that come to light.
-** Replace wrong_kboard_jmpbuf with a special return value of
- read_char. It is absurd that we use setjmp/longjmp just to return
- to the immediate caller.
-
** See if getcjmp can be eliminated somehow. Why does Emacs allow
asynchronous input processing while it's reading input anyway?
multidisplay (and don't mind core dumps), you can edit src/config.h
and define HAVE_GTK_MULTIDISPLAY there by hand.
+ http://bugzilla.gnome.org/show_bug.cgi?id=85715
+
Update: Han reports that GTK+ version 2.8.9 almost gets display
disconnects right. GTK will probably be fully fixed by the time
multi-tty gets into the trunk.
+ Update: I am still having problems with GTK+ 2.8.10. I have the
+ impression that the various multidisplay fixes will only get
+ released in GTK+ 2.10.
+
** Audit `face-valid-attribute-values' usage in customize and
elsewhere. Its return value depends on the current window system.
Replace static initializers using it with runtime functions. For
`getcjmp' when Emacs was waiting for input when the C-g event
arrived.)
+-- Replace wrong_kboard_jmpbuf with a special return value of
+ read_char. It is absurd that we use setjmp/longjmp just to return
+ to the immediate caller.
+
+ (Done in patch-500.)
+
+-- `tool-bar-mode', `scroll-bar-mode', `menu-bar-mode' and
+ 'fringe-mode' are modes global to the entire Emacs session, not
+ just a single frame or a single terminal. This means that their
+ status sometimes differs from what's actually displayed on the
+ screen. As a consequence, the Options | Show/Hide menu sometimes
+ shows incorrect status, and you have to select an option twice for
+ it to have any visible effect on the current frame.
+
+ Change Emacs so that the status of the items in the Options |
+ Show/Hide menu correspond to the current frame.
+
+ (Done in patch-537.)
+
+-- The `default-directory' variable should somehow be set to the
+ cwd of the emacsclient process when the user runs emacsclient
+ without file arguments. Perhaps it is OK to just override the
+ directory of the *scratch* buffer.
+
+ (Done in patch-539.)
+
+-- The borders on tooltip frames on X are messed up. More
+ specifically, the frame's internal border (internal-border-width
+ frame parameter) is not filled with the correct background color.
+
+ It seems the border contents are drawn onto by the
+ update_single_window call in `x-show-tip'. After some debugging, I
+ think the window's background color is not set up
+ correctly---calling `x_clear_area' fills the specified area with
+ black, not light yellow.
+
+ (Done in patch-544. A background_pixel field was defined both in
+ struct frame and struct x_output, and Emacs got confused between
+ them.)
;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
HCoop / bpt / emacs.git / blobdiff