| 1 | -*- coding: utf-8; mode: text; -*- |
| 2 | |
| 3 | Copyright (C) 2007-2011 Free Software Foundation, Inc. |
| 4 | See the end of the file for license conditions. |
| 5 | |
| 6 | From README.multi-tty in the multi-tty branch. |
| 7 | Some of this information may be out of date. |
| 8 | |
| 9 | |
| 10 | THANKS |
| 11 | ------ |
| 12 | |
| 13 | The following is a (sadly incomplete) list of people who have |
| 14 | contributed to the project by testing, submitting patches, bug |
| 15 | reports, and suggestions. Thanks! |
| 16 | |
| 17 | Bernard Adrian <bernadrian@free.fr> |
| 18 | ARISAWA Akihiro <ari@mbf.ocn.ne.jp> |
| 19 | Vincent Bernat <bernat@luffy.cx> |
| 20 | Han Boetes <han@mijncomputer.nl> |
| 21 | Francisco Borges <borges@let.rug.nl> |
| 22 | Damien Cassou <damien.cassou@laposte.net> |
| 23 | Robert J. Chassell <bob@rattlesnake.com> |
| 24 | Romain Francoise <romain@orebokech.com> |
| 25 | Ami Fischman <ami@fischman.org> |
| 26 | Noah Friedman <friedman@splode.com> |
| 27 | Friedrich Delgado Friedrichs <friedel@nomaden.org> |
| 28 | Samium Gromoff <_deepfire@mail.ru> |
| 29 | Mikhail Gusarov <dottedmag@dottedmag.net> |
| 30 | Eric Hanchrow <offby1@blarg.net> |
| 31 | IRIE Tetsuya <irie@t.email.ne.jp> |
| 32 | Yoshiaki Kasahara <kasahara@nc.kyushu-u.ac.jp> |
| 33 | Bas Kok <nekkobassu@yahoo.com> |
| 34 | Jurej Kubelka <Juraj.Kubelka@email.cz> |
| 35 | David Lichteblau <david@lichteblau.com> |
| 36 | Richard Lewis <rtf@jabble.com> |
| 37 | mace <mace@kirjakaapeli.lib.hel.fi> |
| 38 | Suresh Madhu <madhu@cs.unm.edu> |
| 39 | Xavier Mallard <zedek@gnu-rox.org> |
| 40 | Istvan Marko <mi-mtty@kismala.com> |
| 41 | Ted Morse <morse@ciholas.com> |
| 42 | Gergely Nagy <algernon@debian.org> |
| 43 | Dan Nicolaescu <dann@ics.uci.edu> |
| 44 | Kalle Olavi Niemitalo <kon@iki.fi> |
| 45 | Mark Plaksin <happy@mcplaksin.org> |
| 46 | Frank Ruell <stoerte@dreamwarrior.net> |
| 47 | Tom Schutzer-Weissmann <trmsw@yahoo.co.uk> |
| 48 | Joakim Verona <joakim@verona.se> |
| 49 | Dan Waber <dwaber@logolalia.com> |
| 50 | and many others. |
| 51 | |
| 52 | Richard Stallman was kind enough to review an earlier version of my |
| 53 | patches. |
| 54 | |
| 55 | |
| 56 | STATUS |
| 57 | ------ |
| 58 | |
| 59 | It still needs to be ported to Windows/Mac/DOS. Both multiple |
| 60 | tty device support and simultaneous X and tty frame support works |
| 61 | fine. Emacsclient has been extended to support opening new tty and X |
| 62 | frames. It has been changed to open new Emacs frames by default. |
| 63 | |
| 64 | Tested on GNU/Linux, Solaris 8, FreeBSD and OpenBSD. |
| 65 | |
| 66 | Known problems: |
| 67 | |
| 68 | * GTK support. If you compile your Emacs with the GTK |
| 69 | toolkit, some functionality of multi-tty may be lost. In |
| 70 | particular, you may get crashes while working on multiple X |
| 71 | displays at once. Previous releases of GTK had limitations |
| 72 | and bugs that prevented full-blown multi-display support in |
| 73 | Emacs. (GTK crashed when Emacs tries to disconnect from an |
| 74 | X server.) Things are much improved in the current GTK |
| 75 | version, but if you do experience crashes in libgtk, try |
| 76 | compiling Emacs with the Lucid toolkit instead. |
| 77 | |
| 78 | * The single-kboard mode. |
| 79 | |
| 80 | If your multi-tty Emacs session seems to be frozen, you |
| 81 | probably have a recursive editing session or a pending |
| 82 | minibuffer prompt (which is a kind of recursive editing) on |
| 83 | another display. To unfreeze your session, switch to that |
| 84 | display and complete the recursive edit, for example by |
| 85 | pressing C-] (`abort-recursive-edit'). |
| 86 | |
| 87 | I am sorry to say that currently there is no way to break |
| 88 | out of this "single-kboard mode" from a frozen display. If |
| 89 | you are unable to switch to the display that locks the |
| 90 | others (for example because it is on a remote computer), |
| 91 | then you can use emacsclient to break out of all recursive |
| 92 | editing sessions: |
| 93 | |
| 94 | emacsclient -e '(top-level)' |
| 95 | |
| 96 | Note that this (perhaps) unintuitive behavior is by design. |
| 97 | Single-kboard mode is required because of an intrinsic Emacs |
| 98 | limitation that is very hard to eliminate. (This limitation |
| 99 | is related to the single-threaded nature of Emacs.) |
| 100 | |
| 101 | I plan to implement better user notification and support for |
| 102 | breaking out of single-kboard mode from locked displays. |
| 103 | |
| 104 | * Mac and DOS support is broken, doesn't even |
| 105 | compile. Multiple display support will probably not provide |
| 106 | new Emacs features on these systems, but the multi-tty |
| 107 | branch changed a few low-level interfaces, and the |
| 108 | system-dependent source files need to be adapted |
| 109 | accordingly. The changes are mostly trivial, so almost |
| 110 | anyone can help, if only by compiling the branch and |
| 111 | reporting the compiler errors. |
| 112 | |
| 113 | |
| 114 | TESTING |
| 115 | ------- |
| 116 | |
| 117 | To test the multi-tty feature, start up the Emacs server with the |
| 118 | following commands: |
| 119 | |
| 120 | emacs |
| 121 | M-x server-start |
| 122 | |
| 123 | and then (from a shell prompt on another terminal) start emacsclient |
| 124 | with |
| 125 | emacsclient -t /optional/file/names... (for a tty frame) |
| 126 | emacsclient /optional/file/names... (for an X frame) |
| 127 | |
| 128 | (Make sure both emacs and emacsclient are multi-tty versions.) |
| 129 | You'll hopefully have two fully working, independent frames on |
| 130 | separate terminals. The new frame is closed automatically when you |
| 131 | finish editing the specified files (C-x #), but delete-frame (C-x 5 0) |
| 132 | also works. Of course, you can create frames on more than two tty |
| 133 | devices. |
| 134 | |
| 135 | Creating new frames on the same tty with C-x 5 2 (make-frame-command) |
| 136 | works, and behaves the same way as in previous Emacs versions. If you |
| 137 | exit emacs, all terminals should be restored to their previous states. |
| 138 | |
| 139 | TIPS & TRICKS |
| 140 | ------------- |
| 141 | |
| 142 | I think the best way to use the new Emacs is to have it running inside |
| 143 | a disconnected GNU screen session, and always use emacsclient for |
| 144 | normal work. One advantage of this is that not a single keystroke of |
| 145 | your work will be lost if the display device that you are using |
| 146 | crashes, or the network connection times out, or whatever. (I had an |
| 147 | extremely unstable X server for some time while I was developing these |
| 148 | patches, and running Emacs this way has saved me a number of M-x |
| 149 | recover-session invocations.) |
| 150 | |
| 151 | I use the following two bash scripts to handle my Emacs sessions: |
| 152 | |
| 153 | -------------------------------------------------------connect-emacs-- |
| 154 | #!/bin/bash |
| 155 | # Usage: connect-emacs <name> <args>... |
| 156 | # |
| 157 | # Connects to the Emacs instance called NAME. Starts up the instance |
| 158 | # if it is not already running. The rest of the arguments are passed |
| 159 | # to emacsclient. |
| 160 | |
| 161 | name="$1" |
| 162 | shift |
| 163 | |
| 164 | if [ -z "$name" ]; then |
| 165 | echo "Usage: connect_emacs <name> <args>..." >&2 |
| 166 | exit 1 |
| 167 | fi |
| 168 | preload-emacs "$name" wait |
| 169 | /usr/bin/emacsclient.emacs-multi-tty -s "$name" "$@" |
| 170 | ---------------------------------------------------------------------- |
| 171 | |
| 172 | -------------------------------------------------------preload-emacs-- |
| 173 | #!/bin/bash |
| 174 | # Usage: preload-emacs <name> [<waitp>] |
| 175 | # |
| 176 | # Preloads the Emacs instance called NAME in a detached screen |
| 177 | # session. Does nothing if the instance is already running. If WAITP |
| 178 | # is non-empty, the function waits until the server starts up and |
| 179 | # creates its socket; otherwise it returns immediately. |
| 180 | |
| 181 | name="$1" |
| 182 | waitp="$2" |
| 183 | screendir="/var/run/screen/S-$USER" |
| 184 | serverdir="/tmp/emacs$UID" |
| 185 | emacs=/usr/bin/emacs-multi-tty # Or wherever you installed your multi-tty Emacs |
| 186 | |
| 187 | if [ -z "$name" ]; then |
| 188 | echo "Usage: preload_emacs <name> [<waitp>]" >&2 |
| 189 | exit 1 |
| 190 | fi |
| 191 | |
| 192 | if [ ! -e "$screendir"/*."$name" ]; then |
| 193 | if [ -e "$serverdir/$name" ]; then |
| 194 | # Delete leftover socket (for the wait option) |
| 195 | rm "$serverdir/$name" |
| 196 | fi |
| 197 | screen -dmS "$name" "$emacs" -nw --eval "(setq server-name \"$name\")" -f server-start |
| 198 | fi |
| 199 | if [ ! -z "$waitp" ]; then |
| 200 | while [ ! -e "$serverdir/$name" ]; do sleep 0.1; done |
| 201 | fi |
| 202 | ---------------------------------------------------------------------- |
| 203 | |
| 204 | I have the following in my profile to have two instances automatically |
| 205 | preloaded for editing and email: |
| 206 | |
| 207 | preload-emacs editor |
| 208 | preload-emacs gnus |
| 209 | |
| 210 | It is useful to set up short aliases for connect-emacs. I use the |
| 211 | following: |
| 212 | |
| 213 | alias edit="connect-emacs editor" |
| 214 | alias e=edit |
| 215 | alias et="connect-emacs editor -t" |
| 216 | alias gnus="connect-emacs gnus" |
| 217 | |
| 218 | |
| 219 | THINGS TO DO |
| 220 | ------------ |
| 221 | |
| 222 | ** See if `tty-defined-color-alist' needs to be terminal-local. |
| 223 | Update: Dan says it should be, so convert it. |
| 224 | |
| 225 | ** Mikhail Gusarov suggest to add a hook akin to |
| 226 | `after-make-frame-functions' that is called whenever Emacs connects |
| 227 | to a new terminal. Good idea! |
| 228 | |
| 229 | ** emacsclient -t on the console does not work after su. You have to |
| 230 | use non-root accounts or start as root to see this. |
| 231 | |
| 232 | Login: root |
| 233 | Password: |
| 234 | # su lorentey |
| 235 | $ emacsclient -t |
| 236 | *ERROR*: Could not open file: /dev/tty1 |
| 237 | |
| 238 | The tty can be opened as /dev/tty by emacsclient, but not by Emacs. |
| 239 | This seems to be a serious problem. Currently my only idea is to |
| 240 | bring back the ugly pty proxy hack from the initial versions of |
| 241 | multi-tty. Suggestions would be appreciated. |
| 242 | |
| 243 | Update: we could change emacsclient to pass its open file |
| 244 | descriptor to the Emacs process. Unfortunately, this requires a |
| 245 | new Lisp-level Emacs API, and as file descriptors are not otherwise |
| 246 | exported to Lisp, this approach seems at least as ugly as the pty |
| 247 | proxy idea. |
| 248 | |
| 249 | ** lisp/vc.el depends on the terminal type during load time. |
| 250 | `vc-annotate-color-map' is one example that needs to be fixed. |
| 251 | |
| 252 | ** Understand how `quit_throw_to_read_char' works, and fix any bugs |
| 253 | that come to light. |
| 254 | |
| 255 | ** See if getcjmp can be eliminated somehow. Why does Emacs allow |
| 256 | asynchronous input processing while it's reading input anyway? |
| 257 | |
| 258 | ** `delete-frame' events are handled by `special-event-map' |
| 259 | immediately when read by `read_char'. This is fine but it prevents |
| 260 | higher-level keymaps from binding that event to get notified of the |
| 261 | deleted frame. |
| 262 | |
| 263 | Sometimes it would be useful for Lisp code to be notified of frame |
| 264 | deletions after they have happened, usually because they want to |
| 265 | clean up after the deleted frame. Not all frame-local states can |
| 266 | be stored as a frame parameter. For example, |
| 267 | `display-splash-screen' uses `recursive-edit' with a special keymap |
| 268 | override to create its buffer---and it leads to all kinds of |
| 269 | nastiness if Emacs stays in this recursive edit mode after the |
| 270 | frame containing the splash screen is deleted. Basically, the |
| 271 | splash-screen implementation wants to throw out of the recursive |
| 272 | edit when the frame is deleted; however, it is not legal to throw |
| 273 | from `delete-frame-functions' because `delete-frame' must not fail. |
| 274 | (Introducing `delete-frame-after-functions' would not help either |
| 275 | because `delete-frame' may not fail at that time either.) |
| 276 | |
| 277 | Currently `fancy-splash-screens' installs a |
| 278 | `delete-frame-functions' hook that sets up a timer to exit the |
| 279 | recursive edit. This is an adequate solution, but it would perhaps |
| 280 | be better to have something like a `frame-deleted' event that could |
| 281 | be bound in the normal way. |
| 282 | |
| 283 | ** Trouble: `setenv' doesn't actually set environment variables in the |
| 284 | Emacs process. This defeats the purpose of the elaborate |
| 285 | `server-with-environment' magic around the `tgetent' call in |
| 286 | `init_tty'. D'oh. |
| 287 | |
| 288 | ** (Possibly) create hooks in struct device for creating frames on a |
| 289 | specific terminal, and eliminate the hackish terminal-related frame |
| 290 | parameters (display, tty, tty-type). |
| 291 | |
| 292 | make_terminal_frame |
| 293 | create_tty_output |
| 294 | |
| 295 | ** Decide whether to keep the C implementation of terminal parameters, |
| 296 | or revert to the previous, purely Lisp code. It turned out that |
| 297 | local environments do not need terminal parameters after all. |
| 298 | |
| 299 | ** Move Fsend_string_to_terminal to term.c, and declare get_named_tty |
| 300 | as static, removing it from dispextern.h. |
| 301 | Move fatal to emacs.c and declare it somewhere. |
| 302 | |
| 303 | ** Search for `suspend-emacs' references and replace them with |
| 304 | `suspend-frame', if necessary. Ditto for `save-buffers-kill-emacs' |
| 305 | vs. `save-buffers-kill-display'. |
| 306 | |
| 307 | ** Emacs crashes when a tty frame is resized so that there is no space |
| 308 | for all its windows. (Tom Schutzer-Weissmann) |
| 309 | |
| 310 | ** Report GTK multi-display problems to GTK maintainers. For extra |
| 311 | credit, fix them. |
| 312 | |
| 313 | Currently you can not connect to new X displays when you compile |
| 314 | Emacs with GTK support. If you want to play around with GTK |
| 315 | multidisplay (and don't mind core dumps), you can edit src/config.h |
| 316 | and define HAVE_GTK_MULTIDISPLAY there by hand. |
| 317 | |
| 318 | http://bugzilla.gnome.org/show_bug.cgi?id=85715 |
| 319 | |
| 320 | Update: Han reports that GTK+ version 2.8.9 almost gets display |
| 321 | disconnects right. GTK will probably be fully fixed by the time |
| 322 | multi-tty gets into the trunk. |
| 323 | |
| 324 | Update: I am still having problems with GTK+ 2.8.10. I have the |
| 325 | impression that the various multidisplay fixes will only get |
| 326 | released in GTK+ 2.10. |
| 327 | |
| 328 | ** Audit `face-valid-attribute-values' usage in customize and |
| 329 | elsewhere. Its return value depends on the current window system. |
| 330 | Replace static initializers using it with runtime functions. For |
| 331 | example, custom's buttons are broken on non-initial device types. |
| 332 | |
| 333 | ** Possibly turn off the double C-g feature when there is an X frame. |
| 334 | C.f. (emacs)Emergency Escape. |
| 335 | |
| 336 | ** frames-on-display-list should also accept frames. |
| 337 | |
| 338 | ** Consider the `tty-type' frame parameter and the `display-tty-type' |
| 339 | function. They serve the exact same purpose. I think it may be |
| 340 | a good idea to eliminate one of them, preferably `tty-type'. |
| 341 | |
| 342 | ** The handling of lisp/term/*.el, and frame creation in general, is a |
| 343 | big, big mess. How come the terminal-specific file is loaded by |
| 344 | tty-create-frame-with-faces? I don't think it is necessary to load |
| 345 | these files for each frame; once per terminal should be enough. |
| 346 | Update: lisp/term/*.el is not loaded repeatedly anymore, but |
| 347 | faces.el still needs to be cleaned up. |
| 348 | |
| 349 | ** Fix frame-set-background-mode in this branch. It was recently |
| 350 | changed in CVS, and frame.el in multi-tty has not yet been adapted |
| 351 | for the changes. (It needs to look at |
| 352 | default-frame-background-mode.) (Update: maybe it is fixed now; |
| 353 | needs testing.) (Note that the byte compiler has this to say about |
| 354 | term/rxvt.el:) |
| 355 | |
| 356 | term/rxvt.el:309:17:Warning: assignment to free variable |
| 357 | `default-frame-background-mode' |
| 358 | |
| 359 | ** I think `(set-)terminal-local-value' and the terminal parameter |
| 360 | mechanism should be integrated into a single framework. |
| 361 | |
| 362 | (Update: `(set-)terminal-local-value' is now eliminated, but the |
| 363 | terminal-local variables should still be accessible as terminal |
| 364 | parameters. This also applies to `display-name' and similar |
| 365 | functions.) |
| 366 | |
| 367 | ** Add the following hooks: after-delete-frame-hook (for server.el, |
| 368 | instead of delete-frame-functions), |
| 369 | after-delete-terminal-functions, after-create-terminal-functions. |
| 370 | |
| 371 | ** BULK RENAME: The `display-' prefix of new Lisp-level functions |
| 372 | conflicts with stuff like `display-time-mode'. Use `device-' |
| 373 | or `terminal-' instead. I think I prefer `terminal-'. |
| 374 | |
| 375 | It turns out that most of the offending Lisp functions were defined |
| 376 | in the trunk. Therefore, compatibility aliases should be defined |
| 377 | for the following names: |
| 378 | |
| 379 | display-color-cells terminal-color-cells |
| 380 | display-color-p terminal-color-p |
| 381 | display-graphic-p terminal-graphic-p |
| 382 | display-grayscale-p terminal-grayscale-p |
| 383 | display-images-p terminal-images-p |
| 384 | display-mm-height terminal-mm-height |
| 385 | display-mm-width terminal-mm-width |
| 386 | display-mouse-p terminal-mouse-p |
| 387 | display-multi-font-p terminal-multi-font-p |
| 388 | display-multi-frame-p terminal-multi-frame-p |
| 389 | display-pixel-height terminal-pixel-height |
| 390 | display-pixel-width terminal-pixel-width |
| 391 | display-pixels-per-inch terminal-pixels-per-inch |
| 392 | display-planes terminal-planes |
| 393 | display-popup-menus-p terminal-popup-menus-p |
| 394 | display-save-under terminal-save-under |
| 395 | display-screens terminal-screens |
| 396 | display-supports-face-attributes-p terminal-supports-face-attributes-p |
| 397 | display-visual-class terminal-visual-class |
| 398 | framep-on-display framep-on-terminal |
| 399 | frames-on-display-list frames-on-terminal-list |
| 400 | |
| 401 | The following functions were introduced in the multi-tty branch, and |
| 402 | were renamed without aliases: |
| 403 | |
| 404 | delete-display delete-terminal |
| 405 | display-controlling-tty-p controlling-tty-p |
| 406 | display-list terminal-list |
| 407 | display-live-p terminal-live-p |
| 408 | display-name terminal-name |
| 409 | display-tty-type tty-type |
| 410 | frame-display frame-terminal |
| 411 | selected-display selected-terminal |
| 412 | |
| 413 | ** The single-keyboard mode of MULTI_KBOARD is extremely confusing |
| 414 | sometimes; Emacs does not respond to stimuli from other keyboards. |
| 415 | At least a beep or a message would be important, if the single-mode |
| 416 | is still required to prevent interference. (Reported by Dan |
| 417 | Nicolaescu.) |
| 418 | |
| 419 | Update: selecting a region with the mouse enables single_kboard |
| 420 | under X. This is very confusing. |
| 421 | |
| 422 | Update: After discussions with Richard Stallman, this will be |
| 423 | resolved by having locked displays warn the user to wait, and |
| 424 | introducing a complex protocol to remotely bail out of |
| 425 | single-kboard mode by pressing C-g. |
| 426 | |
| 427 | Update: Warning the user is not trivial to implement, as Emacs has |
| 428 | only one echo area, shared by all frames. Ideally the warning |
| 429 | should not be displayed on the display that is locking the others. |
| 430 | Perhaps the high probability of user confusion caused by |
| 431 | single_kboard mode deserves a special case in the display code. |
| 432 | Alternatively, it might be good enough to signal single_kboard mode |
| 433 | by changing the modelines or some other frame-local display element |
| 434 | on the locked out displays. |
| 435 | |
| 436 | Update: In fact struct kboard does have an echo_string slot. |
| 437 | |
| 438 | ** The session management module is prone to crashes when the X |
| 439 | connection is closed and then later I try to connect to a new X |
| 440 | session: |
| 441 | |
| 442 | #0 0xb7ebc806 in SmcGetIceConnection () from /usr/X11R6/lib/libSM.so.6 |
| 443 | #1 0x080e6641 in x_session_check_input (bufp=0xbf86c9c0) at xsmfns.c:144 |
| 444 | #2 0x080d3bbc in XTread_socket (device=0xa722ff8, expected=1, hold_quit=0xbf86ca90) at xterm.c:7037 |
| 445 | #3 0x080fa404 in read_avail_input (expected=1) at keyboard.c:6696 |
| 446 | #4 0x080fa4ca in handle_async_input () at keyboard.c:6900 |
| 447 | #5 0x080d51fa in x_term_init (display_name=162628899, xrm_option=0x0, resource_name=0x857068c "emacs") at xterm.c:10622 |
| 448 | #6 0x080d920e in x_display_info_for_name (name=162628899) at xfns.c:3975 |
| 449 | #7 0x080d92f9 in check_x_display_info (object=1) at xfns.c:274 |
| 450 | #8 0x080d97b8 in Fx_create_frame (parms=151221485) at xfns.c:3016 |
| 451 | #9 0x0815bf72 in Ffuncall (nargs=2, args=0xbf86ceec) at eval.c:2851 |
| 452 | |
| 453 | I installed a workaround to prevent this. The X session manager is |
| 454 | only contacted when the very first display in the Emacs session is |
| 455 | an X display. Also, x_delete_display() on this display aborts |
| 456 | session management, and XTread_socket only calls |
| 457 | x_session_check_input when it is called for the display that the |
| 458 | session was opened on. While this does not really fix the bug, it |
| 459 | makes it much less frequent, because session manager support will |
| 460 | not normally be enabled when Emacs can survive the shutdown of the |
| 461 | X server. |
| 462 | |
| 463 | See if xsmfns.c should be updated. |
| 464 | |
| 465 | ** Hunt down display-related functions in frame.el and extend them all |
| 466 | to accept display ids. |
| 467 | |
| 468 | ** rif->flush_display_optional (NULL) calls should be replaced by a |
| 469 | new global function. |
| 470 | |
| 471 | ** The set-locale-environment hack (adding the DISPLAY option) should |
| 472 | be replaced with a clean design. |
| 473 | |
| 474 | ** standard-display-table should be display-local. |
| 475 | standard-display-european should be display-local. |
| 476 | |
| 477 | ** With iswitchb-default-method set to 'always-frame, only frames on |
| 478 | the current display should be considered. This might involve |
| 479 | extending `get-buffer-window'. |
| 480 | |
| 481 | ** Have a look at Vlocale_coding_system. Seems like it would be a |
| 482 | tedious job to localize it, although most references use it for |
| 483 | interfacing with libc and are therefore OK with the global |
| 484 | definition. |
| 485 | |
| 486 | Exceptions found so far: x-select-text and |
| 487 | x-cut-buffer-or-selection-value. |
| 488 | |
| 489 | ** Have a look at fatal_error_hook. |
| 490 | |
| 491 | ** Have a look at set_frame_matrix_frame. |
| 492 | |
| 493 | ** Check if we got term-setup-hook right. |
| 494 | |
| 495 | ** I think tip_frame should be display-local. |
| 496 | |
| 497 | ** Check display reference count handling in x_create_tip_frame. |
| 498 | |
| 499 | ** make-frame does not correctly handle extra parameters in its |
| 500 | argument: |
| 501 | |
| 502 | (frame-parameter (make-frame (list (cons 'foobar 42))) 'foobar) |
| 503 | => nil |
| 504 | |
| 505 | (This is likely an error in the CVS trunk.) |
| 506 | |
| 507 | ** Dan Nicolaescu suggests that -nw should be added as an alias for -t |
| 508 | in emacsclient. Good idea. (Alas, implementing this is not |
| 509 | trivial, getopt_long does not seem to support two-letter ``short'' |
| 510 | options. Patches are welcome.) |
| 511 | |
| 512 | ** Mark Plaksin suggests that emacsclient should accept the same |
| 513 | X-related command-line arguments as Emacs. Most of the X-related |
| 514 | argument-handling is done in Lisp, so this should be quite easy to |
| 515 | implement. (For example, Samium Gromoff wants emacsclient to |
| 516 | support --geometry; implementing this would add that support.) |
| 517 | |
| 518 | ** Gergely Nagy suggests that C-x # should only kill the current |
| 519 | frame, not any other emacsclient frame that may have the same file |
| 520 | opened for editing. I think I agree with him. |
| 521 | |
| 522 | ** Very strange bug: visible-bell does not work on secondary |
| 523 | terminals in xterm and konsole. The screen does flicker a bit, |
| 524 | but it's so quick it isn't noticable. |
| 525 | |
| 526 | (Update: This is probably some problem with padding or whatnot on |
| 527 | the secondary terminals.) |
| 528 | |
| 529 | ** Move baud_rate to struct display. |
| 530 | |
| 531 | ** Implement support for starting an interactive Emacs session without |
| 532 | an initial frame. (The user would connect to it and open frames |
| 533 | later, with emacsclient.) |
| 534 | |
| 535 | ** Fix Mac support (I can't do this entirely myself). Note that the |
| 536 | current state of Mac-specific source files in the multi-tty tree |
| 537 | are not useful; before starting work on Mac support, revert to |
| 538 | pristine, pre-multi-tty versions. |
| 539 | |
| 540 | ** Fix DOS support (I can't do this entirely myself). Note that the |
| 541 | current state of DOS-specific source files in the multi-tty tree |
| 542 | are not useful; before starting work on DOS support, revert to |
| 543 | pristine, pre-multi-tty versions. |
| 544 | |
| 545 | ** Fix Windows support. Currently bootstrapping works on w32, but Emacs |
| 546 | crashes on startup and none of the multi-tty features are |
| 547 | implemented. Many XXX comments mark things that probably need |
| 548 | updating, ChangeLogs will help in spotting changes to X specific |
| 549 | files that may need porting. |
| 550 | |
| 551 | ** Do a grep on XXX and ?? for more issues. |
| 552 | |
| 553 | ** flow-ctrl.el must be updated. |
| 554 | |
| 555 | ** Fix stuff_char for multi-tty. Doesn't seem to be of high priority. |
| 556 | |
| 557 | DIARY OF CHANGES |
| 558 | ---------------- |
| 559 | |
| 560 | (ex-TODO items with explanations.) |
| 561 | |
| 562 | -- Introduce a new struct for terminal devices. |
| 563 | |
| 564 | (Done, see struct tty_output. The list of members is not yet |
| 565 | complete.) |
| 566 | |
| 567 | -- Change the bootstrap procedure to initialize tty_list. |
| 568 | |
| 569 | (Done, but needs review.) |
| 570 | |
| 571 | -- Change make-terminal-frame to support specifying another tty. |
| 572 | |
| 573 | (Done, new frame parameters: `tty' and `tty-type'.) |
| 574 | |
| 575 | -- Implement support for reading from multiple terminals. |
| 576 | |
| 577 | (Done, read_avail_input tries to read from each terminal, until one |
| 578 | succeeds. MULTI_KBOARD is not used. Secondary terminals don't send |
| 579 | SIGIO!) |
| 580 | |
| 581 | (Update: They do, now.) |
| 582 | |
| 583 | (Update2: After enabling X, they don't.) |
| 584 | |
| 585 | -- other-frame should cycle through the frames on the `current' |
| 586 | terminal only. |
| 587 | |
| 588 | (Done, by trivially modifiying next_frame and prev_frame.) |
| 589 | |
| 590 | -- Support different terminal sizes. |
| 591 | |
| 592 | (Done, no problem.) |
| 593 | |
| 594 | -- Make sure terminal resizes are handled gracefully. (Could be |
| 595 | problematic.) |
| 596 | |
| 597 | (Done. We don't get automatic SIGWINCH for additional ttys, |
| 598 | though.) |
| 599 | |
| 600 | -- Extend emacsclient to automatically open a new tty when it connects |
| 601 | to Emacs. |
| 602 | |
| 603 | (Done. It's an ugly hack, needs more work.) |
| 604 | |
| 605 | -- Redisplay must refresh the topmost frame on *all* terminals, not |
| 606 | just the initial terminal. |
| 607 | |
| 608 | (Done, but introduced an ugly redisplay problems. Ugh.) |
| 609 | |
| 610 | -- Fix redisplay problems. |
| 611 | |
| 612 | (Done; it turned out that the entire Wcm structure must be moved |
| 613 | inside tty_output. Why didn't I catch this earlier?) |
| 614 | |
| 615 | -- Provide a way for emacsclient to tell Emacs that the tty has been |
| 616 | resized. |
| 617 | |
| 618 | (Done, simply forward the SIGWINCH signal.) |
| 619 | |
| 620 | -- Each keypress should automatically select the frame corresponding |
| 621 | to the terminal that it was coming from. This means that Emacs |
| 622 | must know from which terminal the last keyboard event came from. |
| 623 | |
| 624 | (Done, it was quite simple, the input event system already |
| 625 | supported multiple frames.) |
| 626 | |
| 627 | -- Fix SIGIO issue with secondary terminals. |
| 628 | |
| 629 | (Done, emacsclient signals Emacs after writing to the proxy pseudo |
| 630 | terminal. Note that this means that multi-tty does not work with |
| 631 | raw ttys!) |
| 632 | |
| 633 | (Update: This is bullshit. There is a read_input_waiting function, |
| 634 | extend that somehow.) |
| 635 | |
| 636 | (Update of update: The first update was not right either, extending |
| 637 | read_input_waiting was not necessary. Secondary ttys do seem to |
| 638 | send signals on input.) |
| 639 | |
| 640 | (Update^3: Not any more.) |
| 641 | |
| 642 | -- Make make-terminal-frame look up the `tty' and `tty-type' frame |
| 643 | parameters from the currently selected terminal before the global |
| 644 | default. |
| 645 | |
| 646 | (Done.) |
| 647 | |
| 648 | -- Put all cached terminal escape sequences into struct tty_output. |
| 649 | Currently, they are still stored in global variables, so we don't |
| 650 | really support multiple terminal types. |
| 651 | |
| 652 | (Done. It was not fun.) |
| 653 | |
| 654 | -- Implement sane error handling after initialization. (Currently |
| 655 | emacs exits if you specify a bad terminal type.) The helpful error |
| 656 | messages must still be provided when Emacs starts. |
| 657 | |
| 658 | (Done.) |
| 659 | |
| 660 | -- Implement terminal deletion, i.e., deleting local frames, closing |
| 661 | the tty device and restoring its previous state without exiting |
| 662 | Emacs. |
| 663 | |
| 664 | (Done, but at the moment only called when an error happens during |
| 665 | initialization. There is a memory corruption error around this |
| 666 | somewhere.) (Update: now it is fully enabled.) |
| 667 | |
| 668 | -- Implement automatic deletion of terminals when the last frame on |
| 669 | that terminal is closed. |
| 670 | |
| 671 | (Done.) |
| 672 | |
| 673 | -- Restore tty screen after closing the terminal. |
| 674 | |
| 675 | (Done, we do the same as Emacs 21.2 for all terminals.) |
| 676 | |
| 677 | -- 'TERM=dumb src/emacs' does not restore the terminal state. |
| 678 | |
| 679 | (Done.) |
| 680 | |
| 681 | -- C-g should work on secondary terminals. |
| 682 | |
| 683 | (Done, but the binding is not configurable.) |
| 684 | |
| 685 | -- Deal with SIGHUP in Emacs and in emacsclient. (After this, the |
| 686 | server-frames may be removed from server.el.) |
| 687 | |
| 688 | (Done, nothing to do. It seems that Emacs does not receive SIGHUP |
| 689 | from secondary ttys, which is actually a good thing.) (Update: I |
| 690 | think it would be a bad idea to remove server-frames.) |
| 691 | |
| 692 | -- Change emacsclient/server.el to support the -t argument better, |
| 693 | i.e. automatically close the socket when the frame is closed. |
| 694 | |
| 695 | (Seems to be working OK.) |
| 696 | |
| 697 | -- Fix mysterious memory corruption error with tty deletion. To |
| 698 | trigger it, try the following shell command: |
| 699 | |
| 700 | while true; do TERM=no-such-terminal-definition emacsclient -h; done |
| 701 | |
| 702 | Emacs usually dumps core after a few dozen iterations. (The bug |
| 703 | seems to be related to the xfreeing or bzeroing of |
| 704 | tty_output.Wcm. Maybe there are outside references to struct Wcm? |
| 705 | Why were these vars collected into a struct before multi-tty |
| 706 | support?) |
| 707 | |
| 708 | (Done. Whew. It turned out that the problem had nothing to do |
| 709 | with hypothetical external references to Wcm, or any other |
| 710 | tty_output component; it was simply that delete_tty closed the |
| 711 | filehandles of secondary ttys twice, resulting in fclose doubly |
| 712 | freeing memory. Utterly trivial matter. I love the C's memory |
| 713 | management, it puts hair on your chest.) |
| 714 | |
| 715 | -- Support raw secondary terminals. (Note that SIGIO works only on |
| 716 | the controlling terminal.) Hint: extend read_input_waiting for |
| 717 | multiple ttys and hopefully this will be fixed. |
| 718 | |
| 719 | (Done, it seems to have been working already for some time. It |
| 720 | seems F_SETOWN does work, after all. Not sure what made it fail |
| 721 | earlier, but it seems to be fixed (there were several changes |
| 722 | around request_sigio, maybe one of them did it). |
| 723 | read_input_waiting is only used in sys_select, don't change |
| 724 | it.) (Update: After adding X support, it's broken again.) |
| 725 | (Update^2: No it isn't.) :-) |
| 726 | |
| 727 | -- Find out why does Emacs abort when it wants to close its |
| 728 | controlling tty. Hint: chan_process[] array. Hey, maybe |
| 729 | noninterrupt-IO would work, too? Update: no, there is no process |
| 730 | for stdin/out. |
| 731 | |
| 732 | (Done. Added add/delete_keyboard_wait_descriptor to |
| 733 | term_init/delete_tty. The hint was right, in a way.) |
| 734 | |
| 735 | -- Issue with SIGIO: it needs to be disabled during redisplay. See if |
| 736 | fcntl kernel behavior could be emulated by emacsclient. |
| 737 | |
| 738 | (Done. Simply disabled the SIGIO emulation hack in emacsclient.) |
| 739 | (Update: it was added back.) (Update^2: and removed again.) |
| 740 | |
| 741 | -- server.el: There are issues with saving files in buffers of closed |
| 742 | clients. Try editing a file with emacsclient -f, and (without |
| 743 | saving it) do a delete-frame. The frame is closed without |
| 744 | question, and a surprising confirmation prompt appears in another |
| 745 | frame. |
| 746 | |
| 747 | (Done. delete-frame now asks for confirmation if it still has |
| 748 | pending buffers, and modified buffers don't seem to be deleted.) |
| 749 | |
| 750 | -- emacsclient.el, server.el: Handle eval or file open errors when |
| 751 | doing -t. |
| 752 | |
| 753 | (Done.) |
| 754 | |
| 755 | -- Make parts of struct tty_output accessible from Lisp. The device |
| 756 | name and the type is sufficient. |
| 757 | |
| 758 | (Done, see frame-tty-name and frame-tty-type.) |
| 759 | |
| 760 | -- Export delete_tty to the Lisp environment, for emacsclient. |
| 761 | |
| 762 | (Done, see delete-tty.) |
| 763 | |
| 764 | -- Get rid of the accessor macros in termchar.h, or define macros for |
| 765 | all members. |
| 766 | |
| 767 | (Done.) |
| 768 | |
| 769 | -- Move device-specific parameters (like costs) commonly used by |
| 770 | device backends to a common, device-dependent structure. |
| 771 | |
| 772 | (Done. See struct display_method in termhooks.h.) |
| 773 | |
| 774 | -- Fix X support. |
| 775 | |
| 776 | (Done. Well, it seems to be working.) |
| 777 | |
| 778 | -- Allow simultaneous X and tty frames. (Handling input could be |
| 779 | tricky. Or maybe not.) |
| 780 | |
| 781 | (Done. Allowed, that is. It is currently extremely unstable, to |
| 782 | the point of being unusable. The rif variable causes constant |
| 783 | core dumps. Handling input is indeed tricky.) |
| 784 | |
| 785 | -- Rewrite multi-tty input in terms of MULTI_KBOARD. |
| 786 | |
| 787 | (Done. In fact, there was no need to rewrite anything, I just |
| 788 | added a kboard member to tty_display_info, and initialized the |
| 789 | frame's kboard from there.) |
| 790 | |
| 791 | -- Fix rif issue with X-tty combo sessions. IMHO the best thing to do |
| 792 | is to get rid of that global variable (and use the value value in |
| 793 | display_method, which is guaranteed to be correct). |
| 794 | |
| 795 | (Done, did exactly that. Core dumps during combo sessions became |
| 796 | much rarer. In fact, I have not yet met a single one.) |
| 797 | |
| 798 | -- Add multi-tty support to talk.el. |
| 799 | |
| 800 | (Done.) |
| 801 | |
| 802 | -- Clean up the source of emacsclient. It is a mess. |
| 803 | |
| 804 | (Done, eliminated stupid proxy-pty kludge.) |
| 805 | |
| 806 | -- Fix faces on tty frames during X-tty combo sessions. There is an |
| 807 | init_frame_faces call in init_sys_modes, see if there is a problem |
| 808 | with it. |
| 809 | |
| 810 | (Done, there was a stupid mistake in |
| 811 | Ftty_supports_face_attributes_p. Colors are broken, though.) |
| 812 | |
| 813 | -- C-x 5 2, C-x 5 o, C-x 5 0 on an emacsclient frame unexpectedly |
| 814 | exits emacsclient. This is a result of trying to be clever with |
| 815 | delete-frame-functions. |
| 816 | |
| 817 | (Fixed, added delete-tty-after-functions, and changed server.el to |
| 818 | use it.) |
| 819 | |
| 820 | -- Something with (maybe) multi-keyboard support broke function keys |
| 821 | and arrows on ttys during X+tty combo sessions. Debug this. |
| 822 | |
| 823 | (I can't reproduce it, maybe the terminal type was wrong.) |
| 824 | |
| 825 | -- Fix input from raw ttys (again). |
| 826 | |
| 827 | (Now it seems to work all right.) |
| 828 | |
| 829 | -- During an X-tty combo session, a (message "Hello") from a tty frame |
| 830 | goes to the X frame. Fix this. |
| 831 | |
| 832 | (Done. There was a safeguard against writing to the initial |
| 833 | terminal frame during bootstrap which prevented echo_area_display |
| 834 | from working correctly on a tty frame during a combo session.) |
| 835 | |
| 836 | -- If there are no frames on its controlling terminal, Emacs should |
| 837 | exit if the user presses C-c there. |
| 838 | |
| 839 | (Done, as far as possible. See the SIGTERM comment in |
| 840 | interrupt_signal on why this seems to be impossible to solve this |
| 841 | in general.) |
| 842 | |
| 843 | -- During an X session, Emacs seems to read from stdin. Also, Emacs |
| 844 | fails to start without a controlling tty. |
| 845 | |
| 846 | (Fixed by replacing the troublesome termcap display with a dummy |
| 847 | bootstrap display during bootstrap. |
| 848 | |
| 849 | -- Do tty output through struct display, like graphical display |
| 850 | backends. |
| 851 | |
| 852 | (Done.) |
| 853 | |
| 854 | -- Define an output_initial value for output_method for the initial |
| 855 | frame that is dumped with Emacs. Checking for this frame (e.g. in |
| 856 | cmd_error_internal) is ugly. |
| 857 | |
| 858 | (Done, breaking interactive temacs.) |
| 859 | |
| 860 | -- The command `emacsclient -t -e '(delete-frame)'' fails to exit. |
| 861 | |
| 862 | (Fixed.) |
| 863 | |
| 864 | -- frame-creation-function should always create a frame that is on the |
| 865 | same display as the selected frame. Maybe frame-creation-function |
| 866 | should simply be removed and make-frame changed to do the right |
| 867 | thing. |
| 868 | |
| 869 | (Done, with a nice hack. frame-creation-function is now frame-local.) |
| 870 | |
| 871 | -- Fix C-g on raw ttys. |
| 872 | |
| 873 | (Done. I disabled the interrupt/quit keys on all secondary |
| 874 | terminals, so Emacs sees C-g as normal input. This looks like an |
| 875 | overkill, because emacsclient has extra code to pass SIGINT to |
| 876 | Emacs, so C-g should remain the interrupt/quit key on emacsclient |
| 877 | frames. See the next entry why implementing this distinction would |
| 878 | be a bad idea.) |
| 879 | |
| 880 | -- Make sure C-g goes to the right frame with ttys. This is hard, as |
| 881 | SIGINT doesn't have a tty parameter. :-( |
| 882 | |
| 883 | (Done, the previous change fixes this as a pleasant side effect.) |
| 884 | |
| 885 | -- I have seen a case when Emacs with multiple ttys fell into a loop |
| 886 | eating 100% of CPU time. Strace showed this loop: |
| 887 | |
| 888 | getpid() = 30284 |
| 889 | kill(30284, SIGIO) = 0 |
| 890 | --- SIGIO (I/O possible) @ 0 (0) --- |
| 891 | ioctl(6, FIONREAD, [0]) = -1 EIO (Input/output error) |
| 892 | ioctl(5, FIONREAD, [0]) = -1 EIO (Input/output error) |
| 893 | ioctl(0, FIONREAD, [0]) = 0 |
| 894 | sigreturn() = ? (mask now []) |
| 895 | gettimeofday({1072842297, 747760}, NULL) = 0 |
| 896 | gettimeofday({1072842297, 747806}, NULL) = 0 |
| 897 | select(9, [0 3 5 6], NULL, NULL, {0, 0}) = 2 (in [5 6], left {0, 0}) |
| 898 | select(9, [0 3 5 6], NULL, NULL, {0, 0}) = 2 (in [5 6], left {0, 0}) |
| 899 | gettimeofday({1072842297, 748245}, NULL) = 0 |
| 900 | |
| 901 | I have seen something similar with a single X frame, but have not |
| 902 | been able to reproduce it for debugging. |
| 903 | |
| 904 | Update: This may have been caused by checking for nread != 0 |
| 905 | instead of nread > 0 after calling read_socket_hook in |
| 906 | read_avail_input. |
| 907 | |
| 908 | (Fixed. This was caused by unconditionally including stdin in |
| 909 | input_wait_mask in init_process. The select call in |
| 910 | wait_reading_process_input always returned immediately, indicating |
| 911 | that there is pending input from stdin, which nobody read. |
| 912 | |
| 913 | Note that the above strace output seems to be an unrelated but |
| 914 | similar bug. I think that is now fixed.) |
| 915 | |
| 916 | -- Exiting Emacs while there are emacsclient frames doesn't restore the |
| 917 | ttys to their default states. |
| 918 | |
| 919 | (This seems to be fixed by some previous change.) |
| 920 | |
| 921 | -- Allow opening an X session after -nw. |
| 922 | |
| 923 | (Done.) |
| 924 | |
| 925 | -- Fix color handling during tty+X combo sessions. (It seems that tty |
| 926 | sessions automatically convert the face colors to terminal colors |
| 927 | when the face is loaded. This conversion must happen instead on |
| 928 | the fly in write_glyphs, which might be problematic, as color |
| 929 | approximation is currently done in lisp (term/tty-colors.el).) |
| 930 | (Update: hm, colors seem to work fine if I start emacs with -nw and |
| 931 | then create an X frame. Maybe it's just a small buglet somewhere.) |
| 932 | |
| 933 | (Seems to be fixed. The problem was in startup.el, it did not |
| 934 | initialize tty colors when the initial window system was |
| 935 | graphical.) |
| 936 | |
| 937 | -- emacs -nw --eval '(y-or-n-p "Foobar")' segfaults. (Reported by |
| 938 | Romain Francoise) |
| 939 | |
| 940 | (Fixed, there was a keyboard initialization problem.) |
| 941 | |
| 942 | -- Fix interactive use of temacs. There are face-related SEGVs, most |
| 943 | likely because of changes in realize_default_face, realize_face. |
| 944 | |
| 945 | (Fixed.) |
| 946 | |
| 947 | -- Don't exit Emacs when the last X connection fails during a |
| 948 | multi-display session. |
| 949 | |
| 950 | (Fixed.) |
| 951 | |
| 952 | -- Dan Nicolaescu noticed that starting emacsclient on the same |
| 953 | terminal device that is the controlling tty of the Emacs process |
| 954 | gives unexpected results. |
| 955 | |
| 956 | (Fixed.) |
| 957 | |
| 958 | -- Istvan Marko reported that Emacs hang on ttys if it was started |
| 959 | from a shell script. |
| 960 | |
| 961 | (Fixed. There was a bug in the multi-tty version of |
| 962 | narrow_foreground_group. tcsetpgrp blocks if it is called from a |
| 963 | process that is not in the same process group as the tty.) |
| 964 | |
| 965 | -- emacsclient -t from an Emacs term buffer does not work, complains |
| 966 | about face problems. This can even lock up Emacs (if the recursive |
| 967 | frame sets single_kboard). Update: the face problems are caused by |
| 968 | bugs in term.el, not in multi-tty. The lockup is caused by |
| 969 | single_kboard mode, and is not easily resolvable. The best thing to |
| 970 | do is to simply refuse to create a tty frame of type `eterm'. |
| 971 | |
| 972 | (Fixed, changed emacsclient to check for TERM=eterm. The face |
| 973 | complaints seem to be caused by bugs in term.el; they are not |
| 974 | related to multi-tty.) |
| 975 | |
| 976 | -- Find out the best way to support suspending Emacs with multiple |
| 977 | ttys. My guess: disable it on the controlling tty, but from other |
| 978 | ttys pass it on to emacsclient somehow. (It is (I hope) trivial to |
| 979 | extend emacsclient to handle suspend/resume. A `kill -STOP' almost |
| 980 | works right now.) |
| 981 | |
| 982 | (Done. I needed to play with signal handling and the server |
| 983 | protocol a bit to make emacsclient behave as a normal UNIX program |
| 984 | wrt foreground/background process groups.) |
| 985 | |
| 986 | -- There is a flicker during the startup of `emacs -nw'; it's as if |
| 987 | the terminal is initialized, reset and then initialized again. |
| 988 | Debug this. (Hint: narrow_foreground_group is called twice during |
| 989 | startup.) |
| 990 | |
| 991 | (This is gone.) |
| 992 | |
| 993 | -- Robert Chassell has found serious copy-paste bugs with the |
| 994 | multi-tty branch. There seem to be redisplay bugs while copying |
| 995 | from X to a terminal frame. Copying accented characters do not |
| 996 | work for me. |
| 997 | |
| 998 | (Patch-124 should fix this, by changing the interprogram-*-function |
| 999 | variables to be frame-local, as suggested by Mark Plaksin |
| 1000 | (thanks!). I think that the redisplay bugs are in fact not bugs, |
| 1001 | but delays caused by single_kboard --> perhaps MULTI_KBOARD should |
| 1002 | be removed.) |
| 1003 | |
| 1004 | -- frame-creation-function was removed, which might be a bad idea. |
| 1005 | Think up a compatible solution. |
| 1006 | |
| 1007 | (It was an internal interface that may be changed when necessary.) |
| 1008 | |
| 1009 | -- Change Lisp code not to (getenv "TERM"); use the `tty-type' frame |
| 1010 | parameter or the frame-tty-type function instead. (M-x tags-search |
| 1011 | "TERM" helps with this.) Update: Actually, all getenv invocations |
| 1012 | should be checked for multi-tty compatibility, and an interface |
| 1013 | must be implemented to get the remote client's environment. |
| 1014 | |
| 1015 | (Done. Only getenv calls in lisp/term/*.el were changed; other |
| 1016 | calls should be mostly left as they are.) |
| 1017 | |
| 1018 | -- Add an elaborate mechanism for display-local variables. (There are |
| 1019 | already a few of these; search for `terminal-local' in the Elisp |
| 1020 | manual.) |
| 1021 | |
| 1022 | (Not needed. Display-local variables could be emulated by |
| 1023 | frame-local variables.) |
| 1024 | |
| 1025 | -- Emacs assumes that all terminal frames have the same locale |
| 1026 | settings as Emacs itself. This may lead to bogus results in a |
| 1027 | multi-locale setup. (E.g., while logging in from a remote client |
| 1028 | with a different locale.) |
| 1029 | (Update after new bugreport by Friedrich Delgado Friedrichs: |
| 1030 | (at least) the structs terminal_coding and keyboard_coding in |
| 1031 | coding.c must be moved to struct display, and the Lisp interface |
| 1032 | [set-]keyboard-coding-system must be adapted for the change.) |
| 1033 | |
| 1034 | (Fixed. Emacs now uses the locale settings as seen by the |
| 1035 | emacsclient process for server tty frames.) |
| 1036 | (Update: Not really; Vlocale_coding_system is still global.) |
| 1037 | |
| 1038 | -- Make `struct display' accessible to Lisp programs. Accessor functions: |
| 1039 | |
| 1040 | (displayp OBJECT): Returns t if OBJECT is a display. |
| 1041 | => Implemented as display-live-p. |
| 1042 | |
| 1043 | (display-list): Returns list of currently active displays. |
| 1044 | => Implemented. |
| 1045 | |
| 1046 | (selected-display): Returns the display object of the selected frame. |
| 1047 | => Not strictly necessary, but implemented anyway. |
| 1048 | |
| 1049 | (frame-display FRAME): Returns the display object of FRAME. |
| 1050 | => Implemented. |
| 1051 | |
| 1052 | (display-frames DISPLAY): Returns a list of frames on DISPLAY. |
| 1053 | => Already implemented, see frames-on-display-list. |
| 1054 | |
| 1055 | (display-type DISPLAY): Returns the type of DISPLAY, as a |
| 1056 | symbol. (See `framep'.) |
| 1057 | => Implemented as display-live-p. |
| 1058 | |
| 1059 | (display-device DISPLAY): Returns the name of the device that |
| 1060 | DISPLAY uses, as a string. (E.g: "/dev/pts/16", or |
| 1061 | ":0.0") |
| 1062 | => Implemented as display-name. |
| 1063 | |
| 1064 | etc. |
| 1065 | |
| 1066 | See next issue why this is necessary. |
| 1067 | |
| 1068 | (Update: The consensus on emacs-devel seems to be to do this via |
| 1069 | integer identifiers. That's fine by me.) |
| 1070 | |
| 1071 | (Done.) |
| 1072 | |
| 1073 | -- The following needs to be supported: |
| 1074 | |
| 1075 | $ emacsclient -t |
| 1076 | C-z |
| 1077 | $ emacsclient -t |
| 1078 | (This fails now.) |
| 1079 | |
| 1080 | The cleanest way to solve this is to allow multiple displays on the |
| 1081 | same terminal device; each new emacsclient process should create |
| 1082 | its own display. As displays are currently identified by their |
| 1083 | device names, this is not possible until struct display becomes |
| 1084 | accessible as a Lisp-level object. |
| 1085 | |
| 1086 | (Done.) |
| 1087 | |
| 1088 | -- Miles Bader suggests that C-x C-c on an emacsclient frame should |
| 1089 | only close the frame, not exit the entire Emacs session. Update: |
| 1090 | see above for a function that does this. Maybe this should be the |
| 1091 | new default? |
| 1092 | |
| 1093 | (Done. This is the new default. No complaints so far.) |
| 1094 | |
| 1095 | -- Clean up the frame-local variable system. I think it's ugly and |
| 1096 | error-prone. But maybe I just haven't yet fully understood it. |
| 1097 | |
| 1098 | (Nothing to do. It doesn't seem ugly any more. It's rather clever.) |
| 1099 | |
| 1100 | -- Support multiple character locales. A version of |
| 1101 | `set-locale-environment' needs to be written for setting up |
| 1102 | display-local settings on ttys. I think calling |
| 1103 | set-display-table-and-terminal-coding-system and |
| 1104 | set-keyboard-coding-system would be enough. The language |
| 1105 | environment itself should remain a global setting. |
| 1106 | |
| 1107 | (Done, by an ugly hack.) |
| 1108 | |
| 1109 | -- The terminal customization files in term/*.el tend to change global |
| 1110 | parameters, which may confuse Emacs with multiple displays. Change |
| 1111 | them to tweak only frame-local settings, if possible. (They tend |
| 1112 | to call define-key to set function key sequences a lot.) |
| 1113 | |
| 1114 | (Done, by making `function-key-map' terminal-local (i.e., part of |
| 1115 | struct kboard). This has probably covered all the remaining problems.) |
| 1116 | |
| 1117 | -- Make `function-key-map' and `key-translation-map' terminal-local. |
| 1118 | |
| 1119 | (Done.) |
| 1120 | |
| 1121 | -- Implement `terminal-local-value' and `set-terminal-local-value' to |
| 1122 | allow deterministic access to terminal local bindings. The |
| 1123 | encode-kb package can not set up `key-translation-map' without |
| 1124 | these. The terminal-local bindings seem to be independent of what |
| 1125 | frame is selected. |
| 1126 | |
| 1127 | (Done.) |
| 1128 | |
| 1129 | -- xt-mouse.el needs to be adapted for multi-tty. It currently |
| 1130 | signals an error on kill-emacs under X, which prevents the user |
| 1131 | from exiting Emacs. (Reported by Mnemonikk on freenode.) |
| 1132 | |
| 1133 | (Done, I hope.) |
| 1134 | |
| 1135 | |
| 1136 | -- Having {reset,init}_all_sys_modes in set-input-mode breaks arrow |
| 1137 | keys on non-selected terminals under screen, and sometimes on other |
| 1138 | terminal types as well. The other function keys continue to work |
| 1139 | fine. Sometimes faces on these screens become garbled. |
| 1140 | |
| 1141 | This only seems to affect displays that are of the same terminfo |
| 1142 | type as the selected one. Interestingly, in screen Emacs normally |
| 1143 | reports the up arrow key as `M-o A', but after the above SNAFU, it |
| 1144 | complains about `M-[ a'. UNIX ttys are a complete mystery to me, |
| 1145 | but it seems the reset-reinitialize cycle somehow leaves the |
| 1146 | non-selected terminals in a different state than usual. I have no |
| 1147 | idea how this could happen. |
| 1148 | |
| 1149 | Currently set-input-mode resets only the currently selected |
| 1150 | terminal, which seems to somehow work around the problem. |
| 1151 | |
| 1152 | Update: |
| 1153 | |
| 1154 | Dan Nicolaescu <dann@ics.uci.edu> writes: |
| 1155 | > Some terminals have 2 modes for cursor keys: Application Mode where |
| 1156 | > the cursor keys transmit the codes defined in the terminfo entry, and |
| 1157 | > Cursor mode. Applications have to send the smkx and rmkx terminfo |
| 1158 | > strings to switch between the 2 modes. So Emacs (and emacsclient) have |
| 1159 | > to send smkx when initializing and rmkx when quitting (or on |
| 1160 | > suspend). |
| 1161 | |
| 1162 | (I think patch-370 fixed this.) |
| 1163 | |
| 1164 | -- This long-standing bug (first reported by Han Boetes) seems to come |
| 1165 | and go all the time. It is time to track it down and fix it. |
| 1166 | |
| 1167 | emacs |
| 1168 | M-x server-start |
| 1169 | |
| 1170 | # From another xterm: |
| 1171 | emacsclient -e '(y-or-n-p "Do you want me to crash? ")' |
| 1172 | # Notice how the answer ends up in the *scratch* buffer |
| 1173 | M-x garbage-collect |
| 1174 | SIGSEGV |
| 1175 | |
| 1176 | (Fixed in patch-414 after detailed analysis by Kalle Olavi Niemitalo.) |
| 1177 | |
| 1178 | -- normal-erase-is-backspace-mode in simple.el needs to be updated for |
| 1179 | multi-tty (rep. by Dan Waber). (The Delete key is broken on X |
| 1180 | because of this.) |
| 1181 | |
| 1182 | (Fixed in patch-427.) |
| 1183 | |
| 1184 | -- I think keyboard-translate-table should be made terminal-local. |
| 1185 | |
| 1186 | (Done in patch-431.) |
| 1187 | |
| 1188 | -- The semantics of terminal-local variables are confusing; it is not |
| 1189 | clear what binding is in effect in any given time. See if |
| 1190 | current_kboard (or at least the terminal-local bindings exported to |
| 1191 | Lisp) might be changed to be tied to the selected frame instead. |
| 1192 | Currently, `function-key-map' and `key-translation-map' may be |
| 1193 | accessed reliably only using the hackish |
| 1194 | `(set-)terminal-local-value' functions. |
| 1195 | |
| 1196 | Perhaps there should be a difference between `last-command' &co. |
| 1197 | and these more conventional configuration variables. |
| 1198 | (E.g. `symbol-value' would use current_kboard to access |
| 1199 | `last-command', but SELECTED_FRAME()->display->kboard to get the |
| 1200 | value of `function-key-map'. |
| 1201 | |
| 1202 | (Fixed in patch-434.) |
| 1203 | |
| 1204 | -- If the first key pressed on a new tty terminal is a function key, |
| 1205 | it is not recognized correctly. May be related to the bug below. |
| 1206 | |
| 1207 | (Seems to have been fixed as a side effect of patch-434. "The bug |
| 1208 | below" was the set-input-mode madness.) |
| 1209 | |
| 1210 | (Update: this bug was fixed for good in patch-449. It was tracked |
| 1211 | down to a bug in `read_key_sequence': it failed to reinitialize its |
| 1212 | local function-key-map/key-translation-map references when it |
| 1213 | switched keyboards. I don't understand why did this bug only |
| 1214 | appear on brand new frames, though!) |
| 1215 | |
| 1216 | -- Disable connecting to a new X display when we use the GTK toolkit. |
| 1217 | |
| 1218 | (Disabled in patch-450.) |
| 1219 | |
| 1220 | -- Implement automatic forwarding of client environment variables to |
| 1221 | forked processes, as discussed on the multi-tty list. Terminal |
| 1222 | parameters are now accessible in C code, so the biggest obstacle is |
| 1223 | gone. The `getenv_internal' and `child_setup' functions in |
| 1224 | callproc.c must be changed to support the following variable: |
| 1225 | |
| 1226 | terminal-local-environment-variables is a variable defined in ... |
| 1227 | |
| 1228 | Enable or disable terminal-local environment variables. |
| 1229 | |
| 1230 | If set to t, `getenv', `setenv' and subprocess creation |
| 1231 | functions use the environment variables of the emacsclient |
| 1232 | process that created the selected frame, ignoring |
| 1233 | `process-environment'. |
| 1234 | |
| 1235 | If set to nil, Emacs uses `process-environment' and ignores |
| 1236 | the client environment. |
| 1237 | |
| 1238 | Otherwise, `terminal-local-environment-variables' should be a |
| 1239 | list of variable names (represented by Lisp strings) to look |
| 1240 | up in the client environment. The rest will come from |
| 1241 | `process-environment'. |
| 1242 | |
| 1243 | (Implemented in patch-461; `terminal-getenv', `terminal-setenv' and |
| 1244 | `with-terminal-environment' are now replaced by extensions to |
| 1245 | `getenv' and `setenv', and the new `local-environment-variables' |
| 1246 | facility. Yay!) |
| 1247 | |
| 1248 | (Updated in patch-465 to fix the semantics of let-binding |
| 1249 | `process-environment'. `process-environment' was changed to |
| 1250 | override all local/global environment variables, and a new variable |
| 1251 | `global-environment' was introduced to have `process-environment's |
| 1252 | old meaning.) |
| 1253 | |
| 1254 | (Updated in patch-466 to fix the case when two emacsclient sessions |
| 1255 | share the same terminal, but have different environment. The local |
| 1256 | environment lists are now stored as frame parameters, so the |
| 1257 | C-level terminal parameters are not strictly necessary any more.) |
| 1258 | |
| 1259 | -- `Fdelete_frame' is called from various critical places where it is |
| 1260 | not acceptable for the frame deletion to fail, e.g. from |
| 1261 | x_connection_closed after an X error. `Fdelete_frame' now protects |
| 1262 | against `delete-frame-functions' throwing an error and preventing a |
| 1263 | frame delete. (patch-475) |
| 1264 | |
| 1265 | -- Fix set-input-mode for multi-tty. It's a truly horrible interface; |
| 1266 | what if we'd blow it up into several separate functions (with a |
| 1267 | compatibility definition)? |
| 1268 | |
| 1269 | (Done. See `set-input-interrupt-mode', `set-output-flow-control', |
| 1270 | `set-input-meta-mode' and `set-quit-char'.) (patch-457) |
| 1271 | |
| 1272 | -- Let-binding `overriding-terminal-local-map' on a brand new frame |
| 1273 | does not seem to work correctly. (See `fancy-splash-screens'.) |
| 1274 | The keymap seems to be set up right, but events go to another |
| 1275 | terminal. Or is it `unread-command-events' that gets Emacs |
| 1276 | confused? Investigate. |
| 1277 | |
| 1278 | (Emacs was confused because a process filter entered |
| 1279 | `recursive-edit' while Emacs was reading input. I added support |
| 1280 | for this in the input system.) (patch-489) |
| 1281 | |
| 1282 | -- I smell something funny around pop_kboard's "deleted kboard" case. |
| 1283 | Determine what are the circumstances of this case, and fix any |
| 1284 | bug that comes to light. |
| 1285 | |
| 1286 | (It happens simply because single_kboard's terminal is sometimes |
| 1287 | deleted while executing a command on it, for example the one that |
| 1288 | kills the terminal. There was no bug here, but I rewrote the whole |
| 1289 | single_kboard mess anyway.) (patch-489) |
| 1290 | |
| 1291 | -- Understand Emacs's low-level input system (it's black magic) :-) |
| 1292 | What exactly does interrupt_input do? I tried to disable it for |
| 1293 | raw secondary tty support, but it does not seem to do anything |
| 1294 | useful. (Update: Look again. X unconditionally enables this, maybe |
| 1295 | that's why raw terminal support is broken again. I really do need |
| 1296 | to understand input.) |
| 1297 | (Update: I am starting to understand the read_key_sequence->read-char |
| 1298 | ->kbd_buffer_get_event->read_avail_input->read_socket_hook path. Yay!) |
| 1299 | |
| 1300 | (Update: OK, it all seems so easy now (NOT). Input could be done |
| 1301 | synchronously (with wait_reading_process_input), or asynchronously |
| 1302 | by SIGIO or polling (SIGALRM). C-g either sets the Vquit_flag, |
| 1303 | signals a 'quit condition (when immediate_quit), or throws to |
| 1304 | `getcjmp' when Emacs was waiting for input when the C-g event |
| 1305 | arrived.) |
| 1306 | |
| 1307 | -- Replace wrong_kboard_jmpbuf with a special return value of |
| 1308 | read_char. It is absurd that we use setjmp/longjmp just to return |
| 1309 | to the immediate caller. |
| 1310 | |
| 1311 | (Done in patch-500.) |
| 1312 | |
| 1313 | -- `tool-bar-mode', `scroll-bar-mode', `menu-bar-mode' and |
| 1314 | 'fringe-mode' are modes global to the entire Emacs session, not |
| 1315 | just a single frame or a single terminal. This means that their |
| 1316 | status sometimes differs from what's actually displayed on the |
| 1317 | screen. As a consequence, the Options | Show/Hide menu sometimes |
| 1318 | shows incorrect status, and you have to select an option twice for |
| 1319 | it to have any visible effect on the current frame. |
| 1320 | |
| 1321 | Change Emacs so that the status of the items in the Options | |
| 1322 | Show/Hide menu correspond to the current frame. |
| 1323 | |
| 1324 | (Done in patch-537.) |
| 1325 | |
| 1326 | -- The `default-directory' variable should somehow be set to the |
| 1327 | cwd of the emacsclient process when the user runs emacsclient |
| 1328 | without file arguments. Perhaps it is OK to just override the |
| 1329 | directory of the *scratch* buffer. |
| 1330 | |
| 1331 | (Done in patch-539.) |
| 1332 | |
| 1333 | -- The borders on tooltip frames on X are messed up. More |
| 1334 | specifically, the frame's internal border (internal-border-width |
| 1335 | frame parameter) is not filled with the correct background color. |
| 1336 | |
| 1337 | It seems the border contents are drawn onto by the |
| 1338 | update_single_window call in `x-show-tip'. After some debugging, I |
| 1339 | think the window's background color is not set up |
| 1340 | correctly---calling `x_clear_area' fills the specified area with |
| 1341 | black, not light yellow. |
| 1342 | |
| 1343 | (Done in patch-544. A background_pixel field was defined both in |
| 1344 | struct frame and struct x_output, and Emacs got confused between |
| 1345 | them.) |
| 1346 | |
| 1347 | \f |
| 1348 | This file is part of GNU Emacs. |
| 1349 | |
| 1350 | GNU Emacs is free software: you can redistribute it and/or modify |
| 1351 | it under the terms of the GNU General Public License as published by |
| 1352 | the Free Software Foundation, either version 3 of the License, or |
| 1353 | (at your option) any later version. |
| 1354 | |
| 1355 | GNU Emacs is distributed in the hope that it will be useful, |
| 1356 | but WITHOUT ANY WARRANTY; without even the implied warranty of |
| 1357 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the |
| 1358 | GNU General Public License for more details. |
| 1359 | |
| 1360 | You should have received a copy of the GNU General Public License |
| 1361 | along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. |