On 02 Jul 2002, ville.skytta(a)xemacs.org wrote: Try setting interprogram-cut-function and interprogram-paste-function to nil. -jeff

If you are using Motif then you can also try: (setq x-selection-strict-motif-ownership nil) This restores the behavior to what it was in pre-21 versions andy At 05:05 PM 7/1/02 -0600, David E Sigeti wrote:

David> Thanks for a much for the suggestion. I will try it when I David> get home this evening. I assume that setting these hooks David> to nil will make it impossible to cut and paste between David> Xemacs and other applications. No, that's not true. It depends both on the application and on the direction of the transfer. You'll just have to try it with the applications in question. If you don't use "modern" applications that depend on the clipboard (see below), you'll probably be OK. Note that you probably don't want to set `interprogram-paste-function' to nil. If you _specifically request_ a paste, presumably you're willing to wait for it, right? The problem with `interprogram-cut-function' is that XEmacs can't know whether you plan to use the killed text interprogram, so it gets invoked on every kill. David> Version 20 of Xemacs allowed cutting and pasting without David> suffering from terrible performance when killing. Under the conditions described above, it did. Setting the interprogram cut/paste functions to nil results in the same behavior as 20.4 AFAIK. David> Is this problem just a bug that we can expect to be fixed David> in a later version, or is there something fundamental about David> the way cutting and pasting are being done now that makes David> performance terrible on connections with high latencies? Basically, there are four ways to communicate interprogram via the X server: Primary selection: a transient selection that gets replaced every time a new selection is made Secondary selection: for "exchanging" with the primary selection Cut buffers: a clipboard internal to the X server (deprecated) Clipboard selection: a selection with a notification protocol that allows a separate app to manage the clipboard The cut buffers are deprecated because managing them is even more inefficient than the clipboard notification protocol. The primary selection works fine for many users and applications, but is not very robust. In Motif and MS Windows, a clipboard has become the primary means for managing cut and paste. It's not that XEmacs doesn't support the simple primary selection method, it's that more and more other applications don't. With most people running most clients and server on the same host, and many of the rest working over very fast communication, you may expect that the situation is not going to improve. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

Andy> So I don't think this is true, and we should probably come Andy> to some sort of consensus about what the various problems Andy> really are and put it in PROBLEMS. What I said is true for Xlib. For Motif, you just lose, lose, lose. I'm not worried about Motif; we can't fix it (at least not in 21.4). We can at best provide a few very unsatisfactory alternatives. The problems are known: Motif clipboard ownership _by design_ requires a lot of X protocol. If you don't do the protocol, the clipboard content doesn't change, so pasting from XEmacs doesn't work. If you do the protocol, it takes a long time if protocol is slow. Some work was done on trying to limit the amount of protocol that needs to be done by evaluating the selection lazily, but that was broken, too. Maybe somebody should go see how Mozilla does this on Motif. People using remote connections could check to see how snappy other applications are about cut and paste. If you find an open source (GPL-compatible license, s'il vous plait) app with good performance, let us know. Maybe we can use its cut code. Andy> IMO we should consider making the default nil rather than t. We've tried that, at some point in 21.2, and we got a lot of complaints about inability to paste from XEmacs to Motif apps, especially web browsers. This gets _worse_ over time, not better, as more and more apps and whole toolkits adopt the Motif/Windows clipboard approach rather than the X selection approach. And more people expect cut/paste etc to Just Work. On this, we're damned if we do, damned if we don't. Heck, we even get complaints from people who have complained about one aspect of the problem, and then don't like the alternative any better. I'm going to leave the default on "correct behavior", and work on PROBLEMS and the FAQ. Proposed FAQ follows, comments requested. Note: it's in "Section 3: Customization" because Subsection 3.10 is "Text Selections." Suggestions for a better place to put it welcome. PROBLEMS will just refer to the FAQ, both Info and a web URL. ------------------------------------------------------------------------ ＠node Q3.10.6, , Q3.10.5, Customization ＠unnumberedsubsec Q3.10.6: Why is killing so slow? This actually is an X Windows question, although you'll notice it with keyboard operations as well as while using the GUI. Basically, there are four ways to communicate interprogram via the X server: ＠c This should be an ＠table. Primary selection: a transient selection that gets replaced every time a new selection is made Secondary selection: for "exchanging" with the primary selection Cut buffers: a clipboard internal to the X server (deprecated) Clipboard selection: a selection with a notification protocol that allows a separate app to manage the clipboard The cut buffers are deprecated because managing them is even more inefficient than the clipboard notification protocol. The primary selection works fine for many users and applications, but is not very robust under intensive or sophisticated use. In Motif and MS Windows, a clipboard has become the primary means for managing cut and paste. These means that "modern" applications tend to be oriented toward a true clipboard, rather than the primary selection. (On Windows, there is nothing equivalent to the primary selection.) It's not that XEmacs doesn't support the simple primary selection method, it's that more and more other applications don't. So the slowdown occurs because XEmacs now engages in the clipboard notification protocol on ＠emph{every} kill. This is especially slow on Motif. With most people running most clients and server on the same host, and many of the rest working over very fast communication, you may expect that the situation is not going to improve. If you are communicating by cut and paste with applications that use the primary selection, then you can customize `interprogram-cut-function' to nil, restoring the XEmacs version 20 behavior. How can you tell if a program will support this? Motifly-correct programs require the clipboard; you lose. For others, only by trying it. You usually don't need to customize the complementary `interprogram-paste-function' to nil; presumably you're willing to wait for a paste from another program if delays only happen when you specifically request a paste. You can get some relief on Motif by setting `x-selection-strict-motif-ownership' to nil, but this means you will only intermittently be able to paste XEmacs kills to Motif applications. ------------------------------------------------------------------------ -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

On 02 Jul 2002, stephen(a)xemacs.org wrote: Yea. Add more words here along the lines of "people running xemacs remotely over x11 can see cut/kill operations take >5 seconds, particularly when running motif" Both interprogram-cut-function and interprogram-paste-function must be customized together. Paste is fast (for me) while cut takes ~5seconds. You can still communicate with motif correct programs by using the separate toolbar cut/copy function. Maybe suggest this before interprogram cut/paste?

On 03 Jul 2002, stephen(a)xemacs.org wrote: Great.. True, but as you said in an earlier message maybe it is negotiating with my x server (exceed). Perhaps other x servers would act differently. IWBN if there was a definitive answer, but that requires a level of understanding that I don't have. Heck, I can barely keep track of my own installation. -jeff

Glynn> the data will be automatically "pasted" on every cut. But pasting has not been expensive (at least for "small" pastes), while cuts are always expensive. I thought that (at least for Motif) this was because we always did something like a paste to the clipboard anyway. The comments in select-x.c seem to indicate that there was an attempt to implement a mere assertion of ownership, with the data being transferred only on request, and this didn't work. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN My nostalgia for Icon makes me forget about any of the bad things. I don't have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py

David E Sigeti wrote: No. You can still use C-insert and Sh-insert to (respectively) cut to and paste from the clipboard. -- Glynn Clements <glynn.clements(a)virgin.net&gt;

I was plagued w/ this problem for a long time. This seems to avoid it for me, don't remember who suggested it tho... ;; ;; disable stupid motif chit-chat when remote (slow). ;; With this change we should no longer need to ;; do a hack build of xemacs without motif support. ;; (setq x-selection-strict-motif-ownership nil) ; make kill operations internal to XEmacs; if you want ; to copy to the X clipboard, use C-insert instead (if t (progn (setq interprogram-cut-function nil) ; 'own-clipboard) (setq interprogram-paste-function nil) ; 'get-clipboard-foreign ) ) If that doesn't work, then try this patch. If you go this route, then you may want to have a special version of xemacs just for remote X. *** select-x.c~ Thu Jun 20 19:27:37 2002 --- select-x.c Mon Jan 6 15:37:32 2003 *************** *** 44,49 **** --- 44,53 ---- # define MOTIF_CLIPBOARDS #endif + // disable motif clipboards to work around horrendous behavior + // in "kill" due to slow or broken clipboard on slow X11 connections + #undef MOTIF_CLIPBOARDS + #ifdef MOTIF_CLIPBOARDS # include <Xm/CutPaste.h> static void hack_motif_clipboard_selection (Atom selection_atom, -- --tony _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

I was having alot of trouble running remotely: xemacs running on Solaris:SPARC and displayed on Mac OS X (Tiger:Intel). I tried these suggestions, but it was still crashing whenever I would delete something. So, I decided to create a version of xemacs just for remote execution with Xaw. However, I can't even get the Xaw build to run locally: uname -a: SunOS buz.biostat.mcw.edu 5.9 Generic_118558-10 sun4u sparc SUNW,Ultra-4 configure --cflags=-Os --with-dialogs=athena --with-widgets=athena --with-mule --with-xim=xlib XEmacs 21.4.20 "Double Solitaire" configured for `sparc-sun-solaris2.9'. Compilation / Installation: Source code location: /usr/local/apps/xemacs/xemacs-21.4.20 Installation prefix: /usr/local Runtime library search path: /usr/ccs/lib:/opt/sfw/lib:/usr/openwin/lib:/usr/local/lib/gcc/sparc-sun-solaris2.9/4.1.1/../../.. Operating system description file: `s/sol2.h' Machine description file: `m/sparc.h' Compiler: gcc-4.1.1 -Os Compiler version: gcc-4.1.1 (GCC) 4.1.1 Compiler specs file: specs. Relocating allocator for buffers: yes GNU version of malloc: yes libc: SUNWcsl 11.9.0,REV=2002.04.06.15.27 Window System: Compiling in support for the X window system: - X Windows headers location: /usr/openwin/include - X Windows libraries location: /usr/openwin/lib - Handling WM_COMMAND properly. Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. TTY: Compiling in support for ncurses. Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. WARNING: ----------------------------------------------------------- WARNING: Compiling without PNG image support. Reason: PNG library version and header file don't match! WARNING: You should strongly consider installing the PNG libraries. WARNING: Otherwise certain images and glyphs may not display. WARNING: (a copy may be found in ftp://ftp.xemacs.org/pub/xemacs/aux) WARNING: ----------------------------------------------------------- Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Databases: Compiling in support for Berkeley database. Compiling in support for GNU DBM. Compiling in support for LDAP. Internationalization: Compiling in support for Mule (multi-lingual Emacs). Compiling in support for XIM (X11R5+ I18N input method). - Using raw Xlib to provide XIM support. Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for ToolTalk. Compiling in support for dynamic shared object modules. buz:root:/usr/local/bin% ulimit -c unlimited buz:root:/usr/local/bin% xemacs-xaw Fatal error (11). Your files have been auto-saved. Use `M-x recover-session' to recover them. Your version of XEmacs was distributed with a PROBLEMS file that may describe your crash, and with luck a workaround. Please check it first, but do report the crash anyway. Please report this bug by invoking M-x report-emacs-bug, or by selecting `Send Bug Report' from the Help menu. If necessary, send ordinary email to `xemacs-beta(a)xemacs.org&#39;. *MAKE SURE* to include the XEmacs configuration from M-x describe-installation, or equivalently the file Installation in the top of the build tree. *Please* try *hard* to obtain a C stack backtrace; without it, we are unlikely to be able to analyze the problem. Locate the core file produced as a result of this crash (often called `core' or `core.<process-id>', and located in the directory in which you started XEmacs or your home directory), and type gdb /usr/local/bin/xemacs-xaw core then type `where' at the debugger prompt. No GDB on your system? You may have DBX, or XDB, or SDB. (Ask your system administrator if you need help.) If no core file was produced, enable them (often with `ulimit -c unlimited' in case of future recurrance of the crash. Lisp backtrace follows: # (unwind-protect ...) make-device(x nil) # bind (display) make-x-device(nil) init-x-win() # bind (debugger debug-on-error command-line-args-left) command-line() # (condition-case ... . ((t (byte-code " §" ... 1)))) # bind (error-data) normal-top-level() # (condition-case ... . error) # (catch top-level ...) zsh: segmentation fault (core dumped) xemacs-xaw buz:root:/usr/local/bin% gdb /usr/local/bin/xemacs-xaw core GNU gdb 6.2.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... warning: core file may not match specified executable file. Core was generated by `xemacs-xaw'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libXaw.so.5...done. Loaded symbols for /usr/lib/libXaw.so.5 Reading symbols from /usr/local/lib/libjpeg.so.62...done. Loaded symbols for /usr/local/lib/libjpeg.so.62 Reading symbols from /usr/lib/libz.so...done. Loaded symbols for /usr/lib/libz.so Reading symbols from /usr/lib/libXpm.so.4...done. Loaded symbols for /usr/lib/libXpm.so.4 Reading symbols from /usr/openwin/lib/libtt.so.2...done. Loaded symbols for /usr/openwin/lib/libtt.so.2 Reading symbols from /usr/lib/libXmu.so.4...done. Loaded symbols for /usr/lib/libXmu.so.4 Reading symbols from /usr/lib/libXt.so.4...done. Loaded symbols for /usr/lib/libXt.so.4 Reading symbols from /usr/lib/libXext.so.0...done. Loaded symbols for /usr/lib/libXext.so.0 Reading symbols from /usr/lib/libX11.so.4...done. Loaded symbols for /usr/lib/libX11.so.4 Reading symbols from /usr/lib/libSM.so.6...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libICE.so.6...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/local/apps/sfw/lib/libdb-4.1.so...done. Loaded symbols for /opt/sfw/lib/libdb-4.1.so Reading symbols from /usr/local/lib/libgdbm.so.2...done. Loaded symbols for /usr/local/lib/libgdbm.so.2 Reading symbols from /usr/local/lib/libncurses.so.5...done. Loaded symbols for /usr/local/lib/libncurses.so.5 Reading symbols from /usr/lib/libintl.so.1... warning: Lowest section in /usr/lib/libintl.so.1 is .hash at 00000074 done. Loaded symbols for /usr/lib/libintl.so.1 Reading symbols from /usr/local/apps/sfw/lib/libldap.so.2...done. Loaded symbols for /opt/sfw/lib/libldap.so.2 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libelf.so.1...done. Loaded symbols for /usr/lib/libelf.so.1 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/local/apps/sfw/lib/liblber.so.2...done. Loaded symbols for /opt/sfw/lib/liblber.so.2 Reading symbols from /usr/lib/libresolv.so.2...done. Loaded symbols for /usr/lib/libresolv.so.2 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-4/lib/libc_psr.so.1 #0 0xfeca01a0 in _libc_kill () from /usr/lib/libc.so.1 (gdb) where #0 0xfeca01a0 in _libc_kill () from /usr/lib/libc.so.1 #1 0x00077e2c in fatal_error_signal () #2 <signal handler called> #3 0x00000000 in ?? () #4 0xff05e4b4 in XRegisterIMInstantiateCallback () from /usr/lib/libX11.so.4 #5 0x0014d934 in x_init_device () #6 0x00069118 in Fmake_device () #7 0x0007aa78 in Ffuncall () #8 0x00056e80 in execute_optimized_program () #9 0x00058eb4 in funcall_compiled_function () #10 0x0007ac4c in Ffuncall () #11 0x00056e80 in execute_optimized_program () #12 0x00058eb4 in funcall_compiled_function () #13 0x0007ac4c in Ffuncall () #14 0x00056e80 in execute_optimized_program () #15 0x00058eb4 in funcall_compiled_function () #16 0x0007a4ac in Feval () #17 0x0007c900 in condition_case_1 () #18 0x0005656c in execute_rare_opcode () #19 0x00056ca4 in execute_optimized_program () #20 0x00058eb4 in funcall_compiled_function () #21 0x0007a4ac in Feval () #22 0x0007c900 in condition_case_1 () #23 0x00060d04 in top_level_1 () #24 0x00079b04 in internal_catch () #25 0x00060b60 in initial_command_loop () #26 0x00077a60 in xemacs_21_4_20_sparc_sun_solaris2_9 () #27 0x00077b20 in main () (gdb) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

On 1/16/07, Rodney Sparapani <rsparapa(a)mcw.edu&gt; wrote: I don't think you can build with xim on Sparc machines - at least that was my experience back when I was using Sparcs, but it's been about 2 years now. HTH, Vin _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

Rodney Sparapani wrote: OK, now I can confirm that xemacs configured for Athena widgets does not crash when you are running it on Solaris 9 (SPARC) and displaying it on Mac OS X (Tiger Intel). This is much better than xemacs configured for Motif which will crash immediately on a deletion (I know, Motif is not really a favorite among XEmacs developers, but it works so good locally on Solaris that I didn't suspect trouble with remote display; by the way Lesstif does not appear to work at all on Solaris if anyone cares; I believe that I reported this a couple of years ago; YMMV). As to another possible solution that I tried: xemacs -nw This does work, but F2-F4 are recognized as kp1-kp3. I suppose there is a simple termcap or Xmodmap explanation for that, but I hate that stuff. ESS users like their function keys so the Athena widgets seems to be the best option. This is all being done currently with Sun openssh (it seems to be very compatible with generic openssh), but I'm hoping that it also works with Cisco VPN that we will be migrating to next year. Doh, I didn't think of testing that until just now. Still more to do... Thanks, Rodney _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta