- -*- coding: utf-8; -*-
+ -*- coding: utf-8; mode: text; -*-
GOAL
----
-The ultimate 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.
+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.
Some use cases:
-
Emacs is notoriously slow at startup, so most people use another
editor or emacsclient for quick editing jobs from the console.
Unfortunately, emacsclient was very awkward to use, because it did not
and check their messages without opening a remote X frame or resorting
to gnus-slave.
-
WHO IS DOING IT
---------------
I'm Károly Lőrentey. My address: lorentey@elte.hu.
-Patches or suggestions are welcome!
+Comments, bug reports, suggestions and patches are welcome!
Retrieving the latest version of the branch:
http://lorentey.web.elte.hu/project/emacs.html
+If you want to be notified of new revisions, sign up to the
+multi-tty@listbox.elte.hu mailing list by visiting the
+below homepage and following its instructions.
+
+ https://listbox.elte.hu/mailman/listinfo/multi-tty
+
+Please note that the multi-tty mailing list is read-only, and is
+reserved for automatic commit messages. Discussion about the branch
+and bug reports should be sent directly to me (lorentey@elte.hu), or
+to the emacs-devel@gnu.org mailing list. (I hope to merge my branch
+into CVS HEAD reasonably soon, so I don't want to set up an elaborate
+development infrastructure for the multi-tty branch.)
+
STATUS
------
-Multi-tty support is stable, I think most of the problems were fixed.
-(It still needs testing on other architectures, though.) Please let
-me know if you find any bugs in it. Emacsclient has been extended to
-support opening a new terminal frame.
+The branch is now very stable and almost full-featured. I hope the
+major problems were fixed. (It still needs testing on other
+architectures, though.) Both multiple tty device support and
+simultaneous X and tty frame support works fine. Emacsclient has been
+extended to support opening new tty and X frames. It has been changed
+open new Emacs frames by default.
+
+Please let me know if you find any bugs in this branch.
-To try it out, compile and run the multi-tty branch with the following
-commands:
+HOW TO COMPILE AND TEST
+-----------------------
+
+To try out the multi-tty branch, compile and run the multi-tty branch
+with the following commands:
mkdir +build
cd +build
- ../configure
+ ../configure <your favourite options>
make bootstrap
- src/emacs -nw
+ src/emacs -nw # You can also try without -nw
M-x server-start
and then (from a shell prompt on another terminal) start emacsclient
with
-
+ lib-src/emacsclient /optional/file/names...
+or
lib-src/emacsclient -t /optional/file/names...
You'll hopefully have two fully working, independent frames on
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 your reports.
+debug if something goes wrong. Please send me your bug reports.
+
+I think the best way to use the new Emacs is to have it running inside
+a disconnected GNU screen session, and always use emacsclient for
+normal work. This way not a single keystroke of your work will be
+lost if the display device that you are using crashes, or the network
+connection times out, or whatever. As long as the server that runs
+your Emacs remains up, all your buffers remain exactly as they were
+before the crash, and you can continue working as if nothing had
+happened. (I had an extremely unstable X server for some time while I
+was developing these patches, and running Emacs this way has saved me
+a number of M-x recover-session invocations.)
+
+(I am thinking about introducing a --daemon option to get rid of the
+above screen dependency.)
Problems:
- * Suspending Emacs is disabled if there are multiple tty
- devices. Also, there is no way to suspend emacsclient. This
- will be fixed.
-
- * X support is (I hope) working, but at the moment there are
- problems with simultaneous X and tty devices, so don't do
- that - start a separate Emacs with -nw and run the server
- there.
-
* Mac, Windows and DOS support is broken, probably doesn't
even compile -- this will be solved later.
- * Only tested on my GNU/Linux box.
+ * Only tested on my GNU/Linux box, Solaris 8 and FreeBSD.
NEWS
----
For the NEWS file:
-** Support for multiple terminal devices has been added. You can
- specify a terminal device (`tty' parameter) and a terminal type
- (`tty-type' parameter) to `make-terminal-frame'. `tty' must be a
- terminal device created by the updated emacsclient, or there will
- be problems with terminal input and window resizes.
+** Support for multiple terminal devices has been added.
- You can test for the presence of multiple terminal support by
- testing for the `multi-tty' feature.
+*** You can specify a terminal device (`tty' parameter) and a terminal
+ type (`tty-type' parameter) to `make-terminal-frame'.
-** A make-frame-on-tty function has been added to make it easier to
- create frames on new terminals.
+*** You can test for the presence of multiple terminal support by
+ testing for the `multi-tty' feature.
-** New functions: frame-tty-name, frame-tty-type for accessing
- terminal parameters, and delete-tty for closing the terminal
- device.
+*** Emacsclient has been extended to support opening a new terminal
+ frame. Its behaviour has been changed to open a new Emacs frame by
+ default. Use the -c option to get the old behavior of opening
+ files in the currently selected Emacs frame.
-** Emacsclient has been extended to support opening a new terminal
- frame.
+*** A make-frame-on-tty function has been added to make it easier to
+ create frames on new terminals.
+
+*** New functions: frame-tty-name, frame-tty-type for accessing
+ terminal parameters, and delete-tty for closing the terminal
+ device.
+
+*** talk.el has been extended for multiple tty support.
+
+
+** Support for simultaneous graphical and terminal frames has been
+ added.
+
+*** The function `make-frame-on-display' now works during a terminal
+ session, and `make-frame-on-tty' works during a graphical session.
+
+*** The `window-system' variable has been made frame-local.
+
+*** The new `initial-window-system' variable contains the
+ `window-system' value for the first frame.
+
+THANKS
+------
+
+The following is an (incomplete) list of people who have contributed
+to the project by testing, bug reports, and suggestions. Thanks!
+
+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 an earlier version of my
+patches.
CHANGELOG
---------
THINGS TO DO
------------
-** Something with (maybe) multi-keyboard support broke function keys
- and arrows on ttys during X+tty combo sessions. Debug this.
+** 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)?
-** Fix faces on tty frames during X-tty combo sessions. There is an
- init_frame_faces call in init_sys_modes, see if there is a problem
- with it.
+** 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.)
-** During an X-tty combo session, a (message "Hello") from a tty frame
- goes to the X frame. Fix this.
+** 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.)
-** 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.)
+** 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.
-** Move baud_rate to tty_output.
+** 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.
-** Do tty output through term_hooks, like graphical display backends.
+** 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. Patches are welcome.) :-)
-** 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.
+** 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.
-** Fix input from raw ttys (again).
+** 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.
-** Fix Mac support (I can't do this myself).
+** Miles Bader suggests that C-x C-c on an emacsclient frame should
+ only close the frame, not exit the entire Emacs session.
-** Fix W32 support (I can't do this myself).
+** Make `struct display' accessible to Lisp programs. Accessor functions:
-** Fix DOS support (I can't do this myself).
+ (displayp OBJECT): Returns t if OBJECT is a display.
-** Do a grep on XXX and ?? for more issues.
+ (display-list): Returns list of currently active displays.
-** Understand Emacs's low-level input system (it seems complicated) :-)
+ (selected-display): Returns the display object of the selected frame.
-** 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.)
+ (frame-display FRAME): Returns the display object of FRAME.
-** Make sure C-g goes to the right frame. This is hard, as SIGINT
- doesn't have a tty parameter. :-(
+ (display-frames DISPLAY): Returns a list of frames on DISPLAY.
-** I have seen a case when Emacs with multiple ttys fell into a loop
- eating 100% of CPU time. Strace showed this loop:
+ (display-type DISPLAY): Returns the type of DISPLAY, as a
+ symbol. (See `framep'.)
- getpid() = 30284
- kill(30284, SIGIO) = 0
- --- SIGIO (I/O possible) @ 0 (0) ---
- ioctl(6, FIONREAD, [0]) = -1 EIO (Input/output error)
- ioctl(5, FIONREAD, [0]) = -1 EIO (Input/output error)
- ioctl(0, FIONREAD, [0]) = 0
- sigreturn() = ? (mask now [])
- gettimeofday({1072842297, 747760}, NULL) = 0
- gettimeofday({1072842297, 747806}, NULL) = 0
- select(9, [0 3 5 6], NULL, NULL, {0, 0}) = 2 (in [5 6], left {0, 0})
- select(9, [0 3 5 6], NULL, NULL, {0, 0}) = 2 (in [5 6], left {0, 0})
- gettimeofday({1072842297, 748245}, NULL) = 0
+ (display-device DISPLAY): Returns the name of the device that
+ DISPLAY uses, as a string. (E.g: "/dev/pts/16", or
+ ":0.0")
- I have seen something similar with a single X frame, but have not
- been able to reproduce it for debugging.
+ etc.
-** Define a output_initial value for output_method for the initial
- frame that is dumped with Emacs. Checking for this frame (e.g. in
- cmd_error_internal) is ugly.
+ See next issue why this is necessary.
-** 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).
+** The following needs to be supported:
-** Clean up the source of emacsclient. It is a mess.
+ $ emacsclient -t
+ C-z
+ $ bg
+ $ emacsclient -t
+ (This fails now.)
-** C-x 5 2, C-x 5 o, C-x 5 0 on an emacsclient frame unexpectedly
- exits emacsclient. This is a result of trying to be clever with
- delete-frame-functions.
+ 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.)
+
+** 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
+ useful; before starting work on Mac support, revert to pristine,
+ pre-multi-tty versions.
+
+** Fix W32 support (I can't do this myself). Note that the current
+ state of W32-specific source files in the multi-tty tree are not
+ useful; before starting work on W32 support, revert to pristine,
+ pre-multi-tty versions.
+
+** Fix DOS support (I can't do this myself). Note that the current
+ state of DOS-specific source files in the multi-tty tree are not
+ useful; before starting work on DOS support, revert to pristine,
+ pre-multi-tty versions.
+
+** Do a grep on XXX and ?? for more issues.
+
+** 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.
DIARY OF CHANGES
----------------
(ex-TODO items with explanations.)
--- Introduce a new struct for terminal devices.
+-- Introduce a new struct for terminal devices.
(Done, see struct tty_output. The list of members is not yet
complete.)
(Update2: After enabling X, they don't.)
-- other-frame should cycle through the frames on the `current'
- terminal only.
+ terminal only.
(Done, by trivially modifiying next_frame and prev_frame.)
-- Support different terminal sizes.
-
+
(Done, no problem.)
-- Make sure terminal resizes are handled gracefully. (Could be
-- Extend emacsclient to automatically open a new tty when it connects
to Emacs.
-
+
(Done. It's an ugly hack, needs more work.)
-- Redisplay must refresh the topmost frame on *all* terminals, not
just the initial terminal.
-
+
(Done, but introduced an ugly redisplay problems. Ugh.)
-- Fix redisplay problems.
(Done, we do the same as Emacs 21.2 for all terminals.)
-- 'TERM=dumb src/emacs' does not restore the terminal state.
-
+
(Done.)
-- C-g should work on secondary terminals.
while true; do TERM=no-such-terminal-definition emacsclient -h; done
Emacs usually dumps core after a few dozen iterations. (The bug
- seems to be related to the xfree()ing or bzero()ing of
+ seems to be related to the xfreeing or bzeroing of
tty_output.Wcm. Maybe there are outside references to struct Wcm?
Why were these vars collected into a struct before multi-tty
support?)
with hypothetical external references to Wcm, or any other
tty_output component; it was simply that delete_tty closed the
filehandles of secondary ttys twice, resulting in fclose doubly
- free()ing memory. Utterly trivial matter. I love the C's memory
+ freeing memory. Utterly trivial matter. I love the C's memory
management, it puts hair on your chest.)
-- Support raw secondary terminals. (Note that SIGIO works only on
- the controlling terminal.) Hint: extend read_input_waiting() for
+ the controlling terminal.) Hint: extend read_input_waiting for
multiple ttys and hopefully this will be fixed.
(Done, it seems to have been working already for some time. It
seems F_SETOWN does work, after all. Not sure what made it fail
earlier, but it seems to be fixed (there were several changes
around request_sigio, maybe one of them did it).
- read_input_waiting() is only used in sys_select(), don't change
+ 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
term_init/delete_tty. The hint was right, in a way.)
-- Issue with SIGIO: it needs to be disabled during redisplay. See if
- fcntl() kernel behaviour could be emulated by emacsclient.
+ 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
(Done, did exactly that. Core dumps during combo sessions became
much rarer. In fact, I have not yet met a single one.)
+-- Add multi-tty support to talk.el.
+
+ (Done.)
+
+-- Clean up the source of emacsclient. It is a mess.
+
+ (Done, eliminated stupid proxy-pty kludge.)
+
+-- Fix faces on tty frames during X-tty combo sessions. There is an
+ init_frame_faces call in init_sys_modes, see if there is a problem
+ with it.
+
+ (Done, there was a stupid mistake in
+ Ftty_supports_face_attributes_p. Colors are broken, though.)
+
+-- C-x 5 2, C-x 5 o, C-x 5 0 on an emacsclient frame unexpectedly
+ exits emacsclient. This is a result of trying to be clever with
+ delete-frame-functions.
+
+ (Fixed, added delete-tty-after-functions, and changed server.el to
+ use it.)
+
+-- Something with (maybe) multi-keyboard support broke function keys
+ and arrows on ttys during X+tty combo sessions. Debug this.
+
+ (I can't reproduce it, maybe the terminal type was wrong.)
+
+-- Fix input from raw ttys (again).
+
+ (Now it seems to work all right.)
+
+-- During an X-tty combo session, a (message "Hello") from a tty frame
+ goes to the X frame. Fix this.
+
+ (Done. There was a safeguard against writing to the initial
+ terminal frame during bootstrap which prevented echo_area_display
+ 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 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
+ in general.)
+
+-- During an X session, Emacs seems to read from stdin. Also, Emacs
+ fails to start without a controlling tty.
+
+ (Fixed by replacing the troublesome termcap display with a dummy
+ bootstrap display during bootstrap.
+
+-- Do tty output through struct display, like graphical display
+ backends.
+
+ (Done.)
+
+-- Define an output_initial value for output_method for the initial
+ frame that is dumped with Emacs. Checking for this frame (e.g. in
+ cmd_error_internal) is ugly.
+
+ (Done, broking interactive temacs.)
+
+-- The command `emacsclient -t -e '(delete-frame)'' fails to exit.
+
+ (Fixed.)
+
+-- frame-creation-function should always create a frame that is on the
+ same display as the selected frame. Maybe frame-creation-function
+ should simply be removed and make-frame changed to do the right
+ thing.
+
+ (Done, with a nice hack. frame-creation-function is now frame-local.)
+
+-- Fix C-g on raw ttys.
+
+ (Done. I disabled the interrupt/quit keys on all secondary
+ terminals, so Emacs sees C-g as normal input. This looks like an
+ overkill, because emacsclient has extra code to pass SIGINT to
+ Emacs, so C-g should remain the interrupt/quit key on emacsclient
+ frames. See the next entry why implementing this distinction would
+ be a bad idea.)
+
+-- Make sure C-g goes to the right frame with ttys. This is hard, as
+ SIGINT doesn't have a tty parameter. :-(
+
+ (Done, the previous change fixes this as a pleasant side effect.)
+
+-- I have seen a case when Emacs with multiple ttys fell into a loop
+ eating 100% of CPU time. Strace showed this loop:
+
+ getpid() = 30284
+ kill(30284, SIGIO) = 0
+ --- SIGIO (I/O possible) @ 0 (0) ---
+ ioctl(6, FIONREAD, [0]) = -1 EIO (Input/output error)
+ ioctl(5, FIONREAD, [0]) = -1 EIO (Input/output error)
+ ioctl(0, FIONREAD, [0]) = 0
+ sigreturn() = ? (mask now [])
+ gettimeofday({1072842297, 747760}, NULL) = 0
+ gettimeofday({1072842297, 747806}, NULL) = 0
+ select(9, [0 3 5 6], NULL, NULL, {0, 0}) = 2 (in [5 6], left {0, 0})
+ select(9, [0 3 5 6], NULL, NULL, {0, 0}) = 2 (in [5 6], left {0, 0})
+ gettimeofday({1072842297, 748245}, NULL) = 0
+
+ I have seen something similar with a single X frame, but have not
+ been able to reproduce it for debugging.
+
+ Update: This may have been caused by checking for nread != 0
+ instead of nread > 0 after calling read_socket_hook in
+ read_avail_input.
+
+ (Fixed. This was caused by unconditionally including stdin in
+ input_wait_mask in init_process. The select call in
+ wait_reading_process_input always returned immediately, indicating
+ that there is pending input from stdin, which nobody read.
+
+ Note that the above strace output seems to be an unrelated but
+ similar bug. I think that is now fixed.)
+
+-- Exiting Emacs while there are emacsclient frames doesn't restore the
+ ttys to their default states.
+
+ (This seems to be fixed by some previous change.)
+
+-- Allow opening an X session after -nw.
+
+ (Done.)
+
+-- Fix color handling during tty+X combo sessions. (It seems that tty
+ sessions automatically convert the face colors to terminal colors
+ when the face is loaded. This conversion must happen instead on
+ the fly in write_glyphs, which might be problematic, as color
+ approximation is currently done in lisp (term/tty-colors.el).)
+ (Update: hm, colors seem to work fine if I start emacs with -nw and
+ then create an X frame. Maybe it's just a small buglet somewhere.)
+
+ (Seems to be fixed. The problem was in startup.el, it did not
+ initialize tty colors when the initial window system was
+ graphical.)
+
+-- emacs -nw --eval '(y-or-n-p "Foobar")' segfaults. (Reported by
+ Romain Francoise)
+
+ (Fixed, there was a keyboard initialization problem.)
+
+-- Fix interactive use of temacs. There are face-related SEGVs, most
+ likely because of changes in realize_default_face, realize_face.
+
+ (Fixed.)
+
+-- Don't exit Emacs when the last X connection fails during a
+ multi-display session.
+
+ (Fixed.)
+
+-- Dan Nicolaescu noticed that starting emacsclient on the same
+ terminal device that is the controlling tty of the Emacs process
+ gives unexpected results.
+
+ (Fixed.)
+
+-- Istvan Marko reported that Emacs hang on ttys if it was started
+ from a shell script.
+
+ (Fixed. There was a bug in the multi-tty version of
+ 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