Mercurial > emacs
changeset 83230:d8738586aaec
Remove remaining references to updating_frame.
* src/dispextern.h (updated_window): Remove comment reference to
updating_frame.
* src/dispnew.c (update_window): Remove bogus xassert.
* src/xterm.c: (x_clear_frame): Update comment.
(x_draw_window_cursor): Remove reference to updating_frame.
git-archimport-id: lorentey@elte.hu--2004/emacs--multi-tty--0--patch-270
author | Karoly Lorentey <lorentey@elte.hu> |
---|---|
date | Sun, 28 Nov 2004 14:39:06 +0000 |
parents | b8f2149f9c3d |
children | 549734260e34 |
files | README.multi-tty src/dispextern.h src/dispnew.c src/xterm.c |
diffstat | 4 files changed, 115 insertions(+), 75 deletions(-) [+] |
line wrap: on
line diff
--- a/README.multi-tty Sun Nov 28 00:48:30 2004 +0000 +++ b/README.multi-tty Sun Nov 28 14:39:06 2004 +0000 @@ -2,9 +2,8 @@ GOAL ---- -The goal of this branch is to implement support for opening multiple, -different tty devices and simultaneous X and tty frames from a single -Emacs session. +This branch implements support for opening multiple, different tty +devices and simultaneous X and tty frames from a single Emacs session. Some use cases: Emacs is notoriously slow at startup, so most people use another @@ -28,6 +27,34 @@ Comments, bug reports, suggestions and patches are welcome; send them to multi-tty@lists.fnord.hu. +The following is a (sadly incomplete) list of people who have +contributed to the project by testing, submitting patches, bug +reports, and suggestions. Thanks! + +ARISAWA Akihiro <ari at mbf dot ocn dot ne dot jp> +Han Boetes <han at mijncomputer dot nl> +Robert J. Chassell <bob at rattlesnake dot com> +Romain Francoise <romain at orebokech dot com> +Ami Fischman <ami at fischman dot org> +Friedrich Delgado Friedrichs <friedel at nomaden dot org> +IRIE Tetsuya <irie at t dot email dot ne dot jp> +Yoshiaki Kasahara <kasahara at nc dot kyushu-u dot ac dot jp> +Jurej Kubelka <Juraj dot Kubelka at email dot cz> +David Lichteblau <david at lichteblau dot com> +Istvan Marko <mi-mtty at kismala dot com> +Ted Morse <morse at ciholas 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> +Dan Waber <dwaber at logolalia dot com> +and many others. + +Richard Stallman was kind enough to review an earlier version of my +patches. + + MAILING LISTS ------------- @@ -64,8 +91,42 @@ Known problems: - * Mac, Windows and DOS support is broken, probably doesn't - even compile -- this will be solved later. + * The single-kboard mode. + + If your multi-tty Emacs session seems to be frozen, you + probably have a recursive editing session or a pending + minibuffer prompt (which is a kind of recursive editing) on + another display. To unfreeze your session, switch to that + display and complete the recursive edit, for example by + pressing C-] (`abort-recursive-edit'). + + I am sorry to say that currently there is no way to break + out of this "single-kboard mode" from a frozen display. If + you are unable to switch to the display that locks the + others (for example because it is on a remote computer), + then you can use emacsclient to break out of all recursive + editing sessions: + + emacsclient -e '(top-level)' + + Note that this (perhaps) unintuitive behaviour is by design. + Single-kboard mode is required because of an intrinsic Emacs + limitation that is very hard to eliminate. (This limitation + is related to the single-threaded nature of Emacs.) + + I plan to implement better user notification and support for + breaking out of single-kboard mode from locked displays. + + * Mac, Windows and DOS support is broken, doesn't even + compile. Multiple display support will probably not provide + new Emacs features on these systems, but the multi-tty + branch changed a few low-level interfaces, and the + system-dependent source files need to be adapted + accordingly. The changes are mostly trivial, so almost + anyone can help, if only by compiling the branch and + reporting the compiler errors. (It is not worth to do this + yet, though.) + HOW TO GET THE BRANCH --------------------- @@ -86,17 +147,17 @@ (I use a recent tla development snapshot, but any of the released versions of arch will do fine, I think.) My GPG key id is 0FB27A3F; -it is available from hkp://wwwkeys.eu.pgp.net/, or my homepage at +it is available from hkp://wwwkeys.eu.pgp.net/, or from my homepage at http://lorentey.hu/rolam/gpg.html) -To update your source tree to the latest revision after the first -checkout, simply use the following command: +Don't worry if the above checkout takes a few minutes to complete; +once you have a source tree, updating it to the latest revision will +be _much_ faster. Use the following command for the update: - tla replay lorentey@elte.hu--2004/emacs--multi-tty--0 + tla replay -If you are interested, you can find more information about Arch on -http://wiki.gnuarch.org/. It's a wonderful source control system, I -highly recommend it. +You can find more information about Arch on http://wiki.gnuarch.org/. +It's a wonderful source control system, I highly recommend it. If you don't have tla, the branch has a homepage from which you can download conventional patches against Emacs CVS HEAD: @@ -146,10 +207,10 @@ behave the same way as in previous Emacs versions. If you exit emacs, all terminals should be restored to their previous states. -This is work in progress, and probably full of bugs. You should -always run emacs from gdb, so that you'll have a live instance to -debug if something goes wrong. Please send me -(multi-tty@lists.fnord.hu) your bug reports. +This is work in progress, and probably full of bugs. It is a good +idea to run emacs from gdb, so that you'll have a live instance to +debug if something goes wrong. Please send me your bug reports on our +mailing list: multi-tty@lists.fnord.hu TIPS & TRICKS ------------- @@ -267,36 +328,6 @@ *** The new `initial-window-system' variable contains the `window-system' value for the first frame. -THANKS ------- - -The following is a (sadly incomplete) list of people who have -contributed to the project by testing, submitting patches, bug -reports, and suggestions. Thanks! - -ARISAWA Akihiro <ari at mbf dot ocn dot ne dot jp> -Han Boetes <han at mijncomputer dot nl> -Robert J. Chassell <bob at rattlesnake dot com> -Romain Francoise <romain at orebokech dot com> -Ami Fischman <ami at fischman dot org> -Friedrich Delgado Friedrichs <friedel at nomaden dot org> -IRIE Tetsuya <irie at t dot email dot ne dot jp> -Yoshiaki Kasahara <kasahara at nc dot kyushu-u dot ac dot jp> -Jurej Kubelka <Juraj dot Kubelka at email dot cz> -David Lichteblau <david at lichteblau dot com> -Istvan Marko <mi-mtty at kismala dot com> -Ted Morse <morse at ciholas 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> -Dan Waber <dwaber at logolalia dot com> -and many others. - -Richard Stallman was kind enough to review an earlier version of my -patches. - CHANGELOG --------- @@ -310,12 +341,37 @@ THINGS TO DO ------------ -** rif->flush_display_optional (NULL) calls should be replaced by a - new global function. +** 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. + + Update: After discussions with Richard, this will be resolved by + having locked displays warn the user to wait, and introducing a + complex protocol to remotely bail out of single-kboard mode by + pressing C-g. + + Update: Warning the user is not trivial to implement, as Emacs has + only one echo area. Ideally the warning should not be displayed on + the display that is locking the others. Perhaps the high + probability of user confusion caused by single_kboard mode deserves + a special case in the display code. Alternatively, it might be + good enough to signal single_kboard mode by changing the modelines + or some other frame-local display element on the locked out displays. + +** normal-erase-is-backspace-mode in simple.el needs to be updated for + multi-tty (rep. by Dan Waber). ** Hunt down display-related functions in frame.el and extend them all to accept display ids. +** rif->flush_display_optional (NULL) calls should be replaced by a + new global function. + ** Have a look at fatal_error_hook. ** Check if we got term-setup-hook right. @@ -332,21 +388,6 @@ what if we'd blow it up into several separate functions (with a compatibility definition)? -** Lisp-level stuff that needs to be updated for multi-tty: - - - normal-erase-is-backspace-mode (simple.el) (rep. by Dan Waber) - - -** 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.) Update: - After discussions with Richard, this will be resolved by having - locked displays warn the user to wait, and introducing a complex - protocol to remotely bail out of single-kboard mode by pressing C-g. - ** 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. @@ -365,11 +406,6 @@ frame, not any other emacsclient frame that may have the same file opened for editing. I think I agree with him. -** Miles Bader suggests that C-x C-c on an emacsclient frame should - only close the frame, not exit the entire Emacs session. Update: - see above for a function that does this. Maybe this should be the - new default? - ** 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. @@ -940,4 +976,12 @@ (Done.) +-- Miles Bader suggests that C-x C-c on an emacsclient frame should + only close the frame, not exit the entire Emacs session. Update: + see above for a function that does this. Maybe this should be the + new default? + + (Done. This is the new default. No complaints so far.) + + ;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
--- a/src/dispextern.h Sun Nov 28 00:48:30 2004 +0000 +++ b/src/dispextern.h Sun Nov 28 14:39:06 2004 +0000 @@ -1013,8 +1013,7 @@ extern struct glyph space_glyph; /* Window being updated by update_window. This is non-null as long as - update_window has not finished, and null otherwise. It's role is - analogous to updating_frame. */ + update_window has not finished, and null otherwise. */ extern struct window *updated_window;
--- a/src/dispnew.c Sun Nov 28 00:48:30 2004 +0000 +++ b/src/dispnew.c Sun Nov 28 14:39:06 2004 +0000 @@ -4071,7 +4071,6 @@ /* Check that W's frame doesn't have glyph matrices. */ xassert (FRAME_WINDOW_P (f)); - xassert (updating_frame != NULL); /* Check pending input the first time so that we can quickly return. */ if (redisplay_dont_pause)
--- a/src/xterm.c Sun Nov 28 00:48:30 2004 +0000 +++ b/src/xterm.c Sun Nov 28 14:39:06 2004 +0000 @@ -2796,8 +2796,7 @@ } -/* Clear entire frame. If updating_frame is non-null, clear that - frame. Otherwise clear the selected frame. */ +/* Clear an entire frame. */ static void x_clear_frame (struct frame *f) @@ -7390,8 +7389,7 @@ } #ifndef XFlush - if (updating_frame != f) - XFlush (FRAME_X_DISPLAY (f)); + XFlush (FRAME_X_DISPLAY (f)); #endif }