* Strange slowness when killing words interactively @ 2011-04-27 1:30 Taylor Venable 2011-05-02 0:22 ` Taylor Venable 0 siblings, 1 reply; 19+ messages in thread From: Taylor Venable @ 2011-04-27 1:30 UTC (permalink / raw) To: help-gnu-emacs Hi, I'm having a strange problem with C-<backspace> (backward-kill-word) and looking for some help in trying to debug it. When I use this keystroke, the CPU usage spikes. The same goes for C-<delete> (forward-kill-word) or any other key that I bind to either of these functions. Other functions, such as backward-kill-sexp and backward-kill-sentence, are similarly problematic. As a result, when I hold the key down, my high repeat rate makes Emacs unresponsive for a second until whatever is slowing down catches up. It happens with the GTK GUI, but not with the text user interface. None of my other machines have this behaviour with the same version of Emacs (that includes one machine which is running the same distribution [Arch Linux] with the same packages). No other programs on this system are affected by performance problems when deleting words of text from a block. The problem occurs with and without using -q. There does not seem to be the same problem if I run the kill function itself with C-u; for example, C-u 1000 backward-kill-word is instant. What's the best way to profile this and figure out where my CPU cycles are being eaten? Thanks for any help, my version information is below. I built from fully updated bzr trunk tonight. M-x emacs-version GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.1) of 2011-04-26 gcc --version gcc (GCC) 4.6.0 20110415 (prerelease) uname -a Linux system76 2.6.38-ARCH #1 SMP PREEMPT Sun Apr 17 15:18:58 CEST 2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel GNU/Linux -- Taylor C. Venable http://metasyntax.net/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-04-27 1:30 Strange slowness when killing words interactively Taylor Venable @ 2011-05-02 0:22 ` Taylor Venable 2011-05-02 1:13 ` Chong Yidong 0 siblings, 1 reply; 19+ messages in thread From: Taylor Venable @ 2011-05-02 0:22 UTC (permalink / raw) To: help-gnu-emacs, emacs-devel On Tue, Apr 26, 2011 at 21:30, Taylor Venable <taylor@metasyntax.net> wrote: > Hi, I'm having a strange problem with C-<backspace> > (backward-kill-word) and looking for some help in trying to debug it. > When I use this keystroke, the CPU usage spikes. The same goes for > C-<delete> (forward-kill-word) or any other key that I bind to either > of these functions. Other functions, such as backward-kill-sexp and > backward-kill-sentence, are similarly problematic. As a result, when I > hold the key down, my high repeat rate makes Emacs unresponsive for a > second until whatever is slowing down catches up. It happens with the > GTK GUI, but not with the text user interface. None of my other > machines have this behaviour with the same version of Emacs (that > includes one machine which is running the same distribution [Arch > Linux] with the same packages). No other programs on this system are > affected by performance problems when deleting words of text from a > block. The problem occurs with and without using -q. There does not > seem to be the same problem if I run the kill function itself with > C-u; for example, C-u 1000 backward-kill-word is instant. What's the > best way to profile this and figure out where my CPU cycles are being > eaten? Thanks for any help, my version information is below. I built > from fully updated bzr trunk tonight. > > M-x emacs-version > GNU Emacs 24.0.50.1 (x86_64-unknown-linux-gnu, GTK+ Version 2.22.1) of > 2011-04-26 > > gcc --version > gcc (GCC) 4.6.0 20110415 (prerelease) > > uname -a > Linux system76 2.6.38-ARCH #1 SMP PREEMPT Sun Apr 17 15:18:58 CEST > 2011 x86_64 Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz GenuineIntel > GNU/Linux (Adding emacs-devel since I've started looking at the source code.) I've found the location where the slowness creeps into kill-word and friends. Looking at kill-region in simple.el, the part that is very slow for my system is adding to the kill ring. If I comment those lines out (as shown in http://paste.lisp.org/+2LWP) then the sluggish response disappears. It's odd to me that I don't see this behaviour when I start Emacs with -nw as I would (perhaps naively) think that slowness in kill-region would be independent of what user interface is active. -- Taylor C. Venable http://metasyntax.net/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-02 0:22 ` Taylor Venable @ 2011-05-02 1:13 ` Chong Yidong 2011-05-02 4:25 ` Taylor Venable 0 siblings, 1 reply; 19+ messages in thread From: Chong Yidong @ 2011-05-02 1:13 UTC (permalink / raw) To: Taylor Venable; +Cc: help-gnu-emacs, emacs-devel Taylor Venable <taylor@metasyntax.net> writes: > I've found the location where the slowness creeps into kill-word and > friends. Looking at kill-region in simple.el, the part that is very > slow for my system is adding to the kill ring. If I comment those > lines out (as shown in http://paste.lisp.org/+2LWP) then the sluggish > response disappears. It's odd to me that I don't see this behaviour > when I start Emacs with -nw as I would (perhaps naively) think that > slowness in kill-region would be independent of what user interface is > active. On a graphical terminal, kill-new calls interprogram-cut-function to set the clipboard (or the X selection, for Emacs 23). That may be causing the slowdown. Could you set interprogram-cut-function to nil and see if it makes any difference? If so, we need to figure out why interprogram-cut-function is slow on your computer. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-02 1:13 ` Chong Yidong @ 2011-05-02 4:25 ` Taylor Venable 2011-05-02 16:32 ` David De La Harpe Golden 0 siblings, 1 reply; 19+ messages in thread From: Taylor Venable @ 2011-05-02 4:25 UTC (permalink / raw) To: Chong Yidong; +Cc: help-gnu-emacs, emacs-devel On Sun, May 1, 2011 at 21:13, Chong Yidong <cyd@stupidchicken.com> wrote: > Taylor Venable <taylor@metasyntax.net> writes: > >> I've found the location where the slowness creeps into kill-word and >> friends. Looking at kill-region in simple.el, the part that is very >> slow for my system is adding to the kill ring. If I comment those >> lines out (as shown in http://paste.lisp.org/+2LWP) then the sluggish >> response disappears. It's odd to me that I don't see this behaviour >> when I start Emacs with -nw as I would (perhaps naively) think that >> slowness in kill-region would be independent of what user interface is >> active. > > On a graphical terminal, kill-new calls interprogram-cut-function to set > the clipboard (or the X selection, for Emacs 23). That may be causing > the slowdown. Could you set interprogram-cut-function to nil and see if > it makes any difference? If so, we need to figure out why > interprogram-cut-function is slow on your computer. Indeed, setting interprogram-cut-function to nil improves the speed dramatically to the normal levels that I see on other machines and in the console. The default value is x-select-text. The problem is also fixed by setting x-select-enable-clipboard to nil. I put my xorg log file on my website if it can be of any help: http://metasyntax.net/Xorg.0.log Thanks, -- Taylor C. Venable http://metasyntax.net/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-02 4:25 ` Taylor Venable @ 2011-05-02 16:32 ` David De La Harpe Golden 2011-05-03 1:14 ` Taylor Venable 0 siblings, 1 reply; 19+ messages in thread From: David De La Harpe Golden @ 2011-05-02 16:32 UTC (permalink / raw) To: emacs-devel; +Cc: Taylor Venable On 02/05/11 05:25, Taylor Venable wrote: > Indeed, setting interprogram-cut-function to nil improves the speed > dramatically to the normal levels that I see on other machines and in > the console. The default value is x-select-text. The problem is also > fixed by setting x-select-enable-clipboard to nil. Just in case: Is your emacs running on the same machine as the x11 server, or remotely? Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in your desktop environment? Typically such a thing shows up as a little clipboard icon in the system tray, with a click on it maybe showing a history of previous clipboard contents, a bit like a system-wide kill-ring. They can in theory cause some slowness by eagerly grabbing clipboard contents (and sometimes primary selection too) for history keeping purposes. It's not usually perceptible when everything's local, though. If you find such a daemon running, please try temporarily disabling it and retesting (you'll still have basic clipboard functionality without the daemon). Probably you'd have already mentioned if you were seeing similar symptoms in non-emacs applications that interact with the x11 clipboard, but if you have the "xclip" command line tool available (arch extra package xclip, apparently), you also could see if the following is near instantaneous (it really should be): $ echo 'Hello, World.' | xclip -selection clipboard $ xclip -selection clipboard -o Hello, World. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-02 16:32 ` David De La Harpe Golden @ 2011-05-03 1:14 ` Taylor Venable 2011-05-03 4:30 ` David De La Harpe Golden 0 siblings, 1 reply; 19+ messages in thread From: Taylor Venable @ 2011-05-03 1:14 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: emacs-devel On Mon, May 2, 2011 at 12:32, David De La Harpe Golden <david@harpegolden.net> wrote: > Is your emacs running on the same machine as the x11 server, or > remotely? Same machine. > Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in > your desktop environment? Nope. > Probably you'd have already mentioned if you were seeing similar > symptoms in non-emacs applications that interact with the x11 > clipboard, but if you have the "xclip" command line tool available > (arch extra package xclip, apparently), you also could see if the > following is near instantaneous (it really should be): I haven't noticed it, but it's more difficult to do such a rapid succession of copy-to-clipboard operations in any other program I can think of. Using xclip 1000 times in a tight loop in bash takes 2.2 seconds on the machine in question (where Emacs is slow, Core i7) and 6.4 seconds on my laptop (where Emacs works as expected, Core 2 Duo). Both machines run updated Arch installations, so same version of X11 and whatnot. Thanks, -- Taylor C. Venable http://metasyntax.net/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-03 1:14 ` Taylor Venable @ 2011-05-03 4:30 ` David De La Harpe Golden 2011-05-03 5:12 ` Stephen J. Turnbull 0 siblings, 1 reply; 19+ messages in thread From: David De La Harpe Golden @ 2011-05-03 4:30 UTC (permalink / raw) To: Taylor Venable; +Cc: emacs-devel On 03/05/11 02:14, Taylor Venable wrote: >> Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in >> your desktop environment? > > Nope. I'm actually kinda out of ideas if it's not a rogue daemon. > Both machines run updated Arch installations, so same version of X11 > and whatnot. Unless someone else has a better idea, one thing that might be worth a shot if you have the time is to do a emacs build from source with: ./configure CFLAGS="-DTRACE_SELECTION" and then launch emacs -Q 2>/tmp/selection.log and do one or two clipboard-hitting operations. This is liable to produce voluminous output, but the log might reveal some shenanigans afoot. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-03 4:30 ` David De La Harpe Golden @ 2011-05-03 5:12 ` Stephen J. Turnbull 2011-05-03 11:51 ` Taylor Venable 0 siblings, 1 reply; 19+ messages in thread From: Stephen J. Turnbull @ 2011-05-03 5:12 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: Taylor Venable, emacs-devel David De La Harpe Golden writes: > On 03/05/11 02:14, Taylor Venable wrote: > > >> Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in > >> your desktop environment? > > > > Nope. > > I'm actually kinda out of ideas if it's not a rogue daemon. Is there any chance he's using Motif? The Motif clipboard protocol is capable of producing delays that even the US immigration service would envy. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-03 5:12 ` Stephen J. Turnbull @ 2011-05-03 11:51 ` Taylor Venable 2011-05-04 5:36 ` David De La Harpe Golden 0 siblings, 1 reply; 19+ messages in thread From: Taylor Venable @ 2011-05-03 11:51 UTC (permalink / raw) To: Stephen J. Turnbull; +Cc: emacs-devel, David De La Harpe Golden On Tue, May 3, 2011 at 01:12, Stephen J. Turnbull <stephen@xemacs.org> wrote: > David De La Harpe Golden writes: > > On 03/05/11 02:14, Taylor Venable wrote: > > > > >> Are you running a clipboard daemon (e.g. kde klipper, xfce4-clipman) in > > >> your desktop environment? > > > > > > Nope. > > > > I'm actually kinda out of ideas if it's not a rogue daemon. > > Is there any chance he's using Motif? The Motif clipboard protocol is > capable of producing delays that even the US immigration service would > envy. No, this is using the GTK interface. :-) -- Taylor C. Venable http://metasyntax.net/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-03 11:51 ` Taylor Venable @ 2011-05-04 5:36 ` David De La Harpe Golden 2011-05-07 2:52 ` Taylor Venable 0 siblings, 1 reply; 19+ messages in thread From: David De La Harpe Golden @ 2011-05-04 5:36 UTC (permalink / raw) To: Taylor Venable; +Cc: Emacs developers On 03/05/11 12:51, Taylor Venable wrote: > >> Is there any chance he's using Motif? The Motif clipboard protocol is >> capable of producing delays that even the US immigration service would >> envy. > > No, this is using the GTK interface. :-) You mean emacs itself? It's more if you were running emacs on a motif/cde desktop (or maybe just one with an xclipboard hanging about). ** What desktop environment (KDE, GNOME, XFCE, etc.), if any, are you using? ** Come to think of it, what does this: (x-selection-exists-p 'CLIPBOARD_MANAGER) return in your emacs? GNOME - and apparently now recent XFCE - do actually have tiny clipboard managers by default (embedded in gnome-settings-daemon and xfce4-settings-helper respectively), but AFAIUI they shouldn't be problematic like motif-era ones: Nowadays there is a protocol [1] for clients to ask a clipboard manager only at client exit time to copy the clipboard content and take over clipboard ownership from the client, to persist the clipboard after client exit, and those managers are about supporting those clients. I only recently learned of the XFCE one and haven't really looked at it yet, though. Actually, I think emacs is not doing its part of [1], though it shouldn't typically have negative effects except when you try to paste after copying in emacs and then quitting, so not directly related to your problem. But I'm now looking at that "Clipboard managers are encouraged to use this information to support legacy clients" line in [1] - maybe there might be a clipboard manager out there that grabs clipboard contents from "legacy clients" eagerly but avoids pestering the clients that indicate their support of the spec. That would mean even "legacy client" clipboard contents wouldn't lost when they exit ...but "legacy client" performance would be degraded. [1] http://www.freedesktop.org/wiki/ClipboardManager ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-04 5:36 ` David De La Harpe Golden @ 2011-05-07 2:52 ` Taylor Venable 2011-05-09 1:18 ` David De La Harpe Golden 0 siblings, 1 reply; 19+ messages in thread From: Taylor Venable @ 2011-05-07 2:52 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: Emacs developers On Wed, May 4, 2011 at 01:36, David De La Harpe Golden <david@harpegolden.net> wrote: > On 03/05/11 12:51, Taylor Venable wrote: >> No, this is using the GTK interface. :-) > > You mean emacs itself? It's more if you were running emacs on a motif/cde > desktop (or maybe just one with an xclipboard hanging about). Ah, yes; I meant that I'm using the Emacs GTK GUI. > ** What desktop environment (KDE, GNOME, XFCE, etc.), if any, are you using? XFCE 4.8.0 > ** Come to think of it, what does this: > (x-selection-exists-p 'CLIPBOARD_MANAGER) > return in your emacs? t > GNOME - and apparently now recent XFCE - do actually have tiny clipboard > managers by default (embedded in gnome-settings-daemon and > xfce4-settings-helper respectively), but AFAIUI they shouldn't be > problematic like motif-era ones: Nowadays there is a protocol [1] for > clients to ask a clipboard manager only at client exit time to copy the > clipboard content and take over clipboard ownership from the client, to > persist the clipboard after client exit, and those managers are about > supporting those clients. I only recently learned of the XFCE one and > haven't really looked at it yet, though. That appears to be the case here, the sort-of hidden clipboard manager in XFCE, because there do not appear to be any separate processes running that are related to clipboard management. > Actually, I think emacs is not doing its part of [1], though it shouldn't > typically have negative effects except when you try to paste after copying > in emacs and then quitting, so not directly related to your problem. But > I'm now looking at that "Clipboard managers are encouraged to use this > information to support legacy clients" line in [1] - maybe there might be a > clipboard manager out there that grabs clipboard contents from "legacy > clients" eagerly but avoids pestering the clients that indicate their > support of the spec. That would mean even "legacy client" clipboard contents > wouldn't lost when they exit ...but "legacy client" performance would be > degraded. I did just try firing up FVWM to check it out, and Emacs performs at high speed there, no problems. So the problem may very well be related to XFCE, or how Emacs interacts with XFCE. -- Taylor C. Venable http://metasyntax.net/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-07 2:52 ` Taylor Venable @ 2011-05-09 1:18 ` David De La Harpe Golden 2011-05-09 3:08 ` David De La Harpe Golden 0 siblings, 1 reply; 19+ messages in thread From: David De La Harpe Golden @ 2011-05-09 1:18 UTC (permalink / raw) To: Taylor Venable; +Cc: Emacs developers [-- Attachment #1: Type: text/plain, Size: 4051 bytes --] On 07/05/11 03:52, Taylor Venable wrote: > > XFCE 4.8.0 > > That appears to be the case here, the sort-of hidden clipboard manager > in XFCE, because there do not appear to be any separate processes > running that are related to clipboard management. Now running XFCE 4.8.0 from debian unstable here. So much for "shouldn't be problematic". xfce4-settings-helper's embedded clipboard manager is indeed eagerly making a copy on every change. At least it's not eagerly nabbing clipboard ownership, like something from the motifozoic. But it seems to convert nearly every target every time. o_O (See attached emacs_xfce_clipboard_1.log, jut killing the word "This" and then "buffer" from *scratch* with two consecutive M-d presses). ** As an immediate workaround, you could pause (kill -STOP/-CONT) or kill outright the problem xfce4-settings-helper daemon when using emacs, though that's hardly a good solution. And it looks like it is somewhat eagerly doing it for primary too - though it seems to only go after UTF8_STRING in that case, and may have some band-aid idle timer. (See attached emacs_xfce_primary_1.log, just a C-SPC and then sedately moving right to select the word "notes" in *scratch*) (The spec is currently silent on primary - although it seems very reasonable to me to expect a PRIMARY_MANAGER and even SECONDARY_MANAGER by the obvious analogy with CLIPBOARD_MANAGER, that doesn't seem to be actually written down anywhere, nor implemented) For emacs' part, it is doing the right thing by reacquiring on each change.[1] Though emacs needs to do more to comply fully with the spec, I suspect it won't help - Still, it might be worth checking to see if XFCE stops its nasty behaviour if emacs is patched to support (or claim to support) SAVE_TARGETS, just in case XFCE is only doing it for spec-unaware clients as previously speculated about (actually, XFCE has sources available, I suppose I could just go look). ** But after checking that, really only remains raising a bug report for XFCE. This won't really be affecting emacs only, it's just relatively noticeable in the emacs case. The GNOME one is not actually completely free of overhead, but it's much more minor. gnome-settings-daemon from GNOME 2.30 on my system is repeatedly asking emacs for TARGETS (perhaps it's worried about the metadata change as per [1] even if it knows better than to grab the entire clipboard content each change), but that is a small constant overhead, not a problem compared to the large increasing overheard xfce4-settings-helper can generate, certainly low enough that I didn't notice until just now when I logged it. (see attached emacs_gnome_clipboard_1.log, killing "This" and then "buffer" from *scratch* with two consecutive M-d presses). So I guess XFCE's xfce4-settings-helper implementation was not actually based on GNOME's example and there was some slight misunderstanding on the XFCE side. Though I suppose they could have made a deliberate decision to work that way, so that even spec-unaware clients' clipboards (and primaries) got persisted after exit as previously discussed, even if it's at IMO rather too high a price. But if that's so, maybe they would still be willing to at least not do it for obviously spec-aware clients (if they're not already not doing it in that case, as above I haven't checked yet), and then, um, we'd just have to modify emacs to comply with the client-side of the spec, which would be a good thing anyway. Of course under either desktop environment, if you instead run a full history-keeping clipboard manager, it will end up eagerly making copies, but that's a tradeoff a user usually chooses to make by running such a thing. (I have some vague ideas for making them more efficient, but that would have to wait until I have a /lot/ of free time...) [1] http://www.freedesktop.org/wiki/ClipboardManager """clipboard owners should reacquire the clipboard whenever the content or metadata (e.g the list of supported targets) changes.""" [-- Attachment #2: emacs_xfce_clipboard_1.log --] [-- Type: text/x-log, Size: 6165 bytes --] 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728809 8577: XInternAtom LENGTH 8577: XInternAtom FILE_NAME 8577: XInternAtom CHARACTER_POSITION 8577: XInternAtom LINE_NUMBER 8577: XInternAtom COLUMN_NUMBER 8577: XInternAtom OWNER_OS 8577: XInternAtom HOST_NAME 8577: XInternAtom USER 8577: XInternAtom CLASS 8577: XInternAtom NAME 8577: CLIPBOARD, target TARGETS (1) 8577: Sending all 76 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728828 8577: CLIPBOARD, target TIMESTAMP (2) 8577: Sending all 4 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728831 8577: CLIPBOARD, target TEXT (3) 8577: Sending all 4 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728832 8577: CLIPBOARD, target COMPOUND_TEXT (4) 8577: Sending all 4 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728833 8577: CLIPBOARD, target STRING (5) 8577: Sending all 4 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728835 8577: CLIPBOARD, target UTF8_STRING (6) 8577: Sending all 4 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728836 8577: XGetAtomName --> LENGTH 8577: CLIPBOARD, target LENGTH (7) 8577: Sending all 4 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728837 8577: XGetAtomName --> FILE_NAME 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728838 8577: XGetAtomName --> CHARACTER_POSITION 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728840 8577: XGetAtomName --> LINE_NUMBER 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728841 8577: XGetAtomName --> COLUMN_NUMBER 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728842 8577: XGetAtomName --> OWNER_OS 8577: CLIPBOARD, target OWNER_OS (8) 8577: Sending all 9 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728843 8577: XGetAtomName --> HOST_NAME 8577: CLIPBOARD, target HOST_NAME (9) 8577: Sending all 23 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728845 8577: XGetAtomName --> USER 8577: CLIPBOARD, target USER (10) 8577: Sending all 24 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728846 8577: XGetAtomName --> CLASS 8577: CLIPBOARD, target CLASS (11) 8577: Sending all 5 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728847 8577: XGetAtomName --> NAME 8577: CLIPBOARD, target NAME (12) 8577: Sending all 5 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728849 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30728850 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729910 8577: XInternAtom LENGTH 8577: XInternAtom FILE_NAME 8577: XInternAtom CHARACTER_POSITION 8577: XInternAtom LINE_NUMBER 8577: XInternAtom COLUMN_NUMBER 8577: XInternAtom OWNER_OS 8577: XInternAtom HOST_NAME 8577: XInternAtom USER 8577: XInternAtom CLASS 8577: XInternAtom NAME 8577: CLIPBOARD, target TARGETS (13) 8577: Sending all 76 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729913 8577: CLIPBOARD, target TIMESTAMP (14) 8577: Sending all 4 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729914 8577: CLIPBOARD, target TEXT (15) 8577: Sending all 11 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729914 8577: CLIPBOARD, target COMPOUND_TEXT (16) 8577: Sending all 11 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729915 8577: CLIPBOARD, target STRING (17) 8577: Sending all 11 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729917 8577: CLIPBOARD, target UTF8_STRING (18) 8577: Sending all 11 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729918 8577: XGetAtomName --> LENGTH 8577: CLIPBOARD, target LENGTH (19) 8577: Sending all 4 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729919 8577: XGetAtomName --> FILE_NAME 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729920 8577: XGetAtomName --> CHARACTER_POSITION 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729922 8577: XGetAtomName --> LINE_NUMBER 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729923 8577: XGetAtomName --> COLUMN_NUMBER 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729924 8577: XGetAtomName --> OWNER_OS 8577: CLIPBOARD, target OWNER_OS (20) 8577: Sending all 9 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729925 8577: XGetAtomName --> HOST_NAME 8577: CLIPBOARD, target HOST_NAME (21) 8577: Sending all 23 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729927 8577: XGetAtomName --> USER 8577: CLIPBOARD, target USER (22) 8577: Sending all 24 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729928 8577: XGetAtomName --> CLASS 8577: CLIPBOARD, target CLASS (23) 8577: Sending all 5 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729929 8577: XGetAtomName --> NAME 8577: CLIPBOARD, target NAME (24) 8577: Sending all 5 bytes 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729930 8577: x_handle_selection_event 8577: x_handle_selection_request, from=0x01c0001f time=30729932 [-- Attachment #3: emacs_xfce_primary_1.log --] [-- Type: text/x-log, Size: 795 bytes --] 8653: x_handle_selection_event 8653: x_handle_selection_request, from=0x01c0001f time=31171410 8653: PRIMARY, target UTF8_STRING (1) 8653: Sending all 1 bytes 8653: x_handle_selection_event 8653: x_handle_selection_request, from=0x01c0001f time=31172636 8653: PRIMARY, target UTF8_STRING (2) 8653: Sending all 2 bytes 8653: x_handle_selection_event 8653: x_handle_selection_request, from=0x01c0001f time=31173630 8653: PRIMARY, target UTF8_STRING (3) 8653: Sending all 3 bytes 8653: x_handle_selection_event 8653: x_handle_selection_request, from=0x01c0001f time=31174518 8653: PRIMARY, target UTF8_STRING (4) 8653: Sending all 4 bytes 8653: x_handle_selection_event 8653: x_handle_selection_request, from=0x01c0001f time=31175091 8653: PRIMARY, target UTF8_STRING (5) 8653: Sending all 5 bytes [-- Attachment #4: emacs_gnome_clipboard_1.log --] [-- Type: text/x-log, Size: 890 bytes --] 9892: x_handle_selection_event 9892: x_handle_selection_request, from=0x012000bb time=33907182 9892: XInternAtom LENGTH 9892: XInternAtom FILE_NAME 9892: XInternAtom CHARACTER_POSITION 9892: XInternAtom LINE_NUMBER 9892: XInternAtom COLUMN_NUMBER 9892: XInternAtom OWNER_OS 9892: XInternAtom HOST_NAME 9892: XInternAtom USER 9892: XInternAtom CLASS 9892: XInternAtom NAME 9892: CLIPBOARD, target TARGETS (1) 9892: Sending all 76 bytes 9892: x_handle_selection_event 9892: x_handle_selection_request, from=0x012000bb time=33908020 9892: XInternAtom LENGTH 9892: XInternAtom FILE_NAME 9892: XInternAtom CHARACTER_POSITION 9892: XInternAtom LINE_NUMBER 9892: XInternAtom COLUMN_NUMBER 9892: XInternAtom OWNER_OS 9892: XInternAtom HOST_NAME 9892: XInternAtom USER 9892: XInternAtom CLASS 9892: XInternAtom NAME 9892: CLIPBOARD, target TARGETS (2) 9892: Sending all 76 bytes [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #5: emacs_gnome_primary_1.log --] [-- Type: text/x-log; name="emacs_gnome_primary_1.log", Size: 0 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-09 1:18 ` David De La Harpe Golden @ 2011-05-09 3:08 ` David De La Harpe Golden 2011-05-14 12:59 ` Taylor Venable 0 siblings, 1 reply; 19+ messages in thread From: David De La Harpe Golden @ 2011-05-09 3:08 UTC (permalink / raw) To: Taylor Venable; +Cc: Emacs developers On 09/05/11 02:18, David De La Harpe Golden wrote: > modify emacs to comply with the client-side of the spec, > which would be a good thing anyway. I've filed this part taken on its own as emacs bug #8641 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8641 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-09 3:08 ` David De La Harpe Golden @ 2011-05-14 12:59 ` Taylor Venable 2011-05-16 22:32 ` Chong Yidong 0 siblings, 1 reply; 19+ messages in thread From: Taylor Venable @ 2011-05-14 12:59 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: Emacs developers On Sun, May 8, 2011 at 23:08, David De La Harpe Golden <david@harpegolden.net> wrote: > On 09/05/11 02:18, David De La Harpe Golden wrote: >> >> modify emacs to comply with the client-side of the spec, >> which would be a good thing anyway. > > I've filed this part taken on its own as emacs bug #8641 > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8641 Great thanks for all your time and investigation into this; I have to admit that I don't fully understand it all, but I do have a much clearer picture. Just let me know if you come up with any possible fixes or workarounds and I'll be more than happy to test them. In the mean time, I just made delete-word and backward-delete-word functions and bound them to C-<delete> and C-<backspace>. Rarely did I ever really want words thus removed put into the kill ring anyway, especially when I used them in the minibuffer e.g. editing a file name. -- Taylor C. Venable http://metasyntax.net/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-14 12:59 ` Taylor Venable @ 2011-05-16 22:32 ` Chong Yidong 2011-05-16 23:01 ` David De La Harpe Golden 0 siblings, 1 reply; 19+ messages in thread From: Chong Yidong @ 2011-05-16 22:32 UTC (permalink / raw) To: Taylor Venable; +Cc: Emacs developers, David De La Harpe Golden Taylor Venable <taylor@metasyntax.net> writes: > Just let me know if you come up with any possible fixes or workarounds > and I'll be more than happy to test them. I'd like to find out if implementing the client side of the clipboard manager spec, as David suggests, will reduce the slowness. Could you apply this patch (with the clipboard manager enabled and all other parts of Emacs as per default) and see if it makes any performance difference? *** lisp/select.el 2011-04-19 13:44:55 +0000 --- lisp/select.el 2011-05-16 22:25:40 +0000 *************** *** 384,389 **** --- 384,392 ---- (NAME . xselect-convert-to-name) (ATOM . xselect-convert-to-atom) (INTEGER . xselect-convert-to-integer) + ;; From freedesktop.org Clipboard Manager spec: used to tell + ;; clipboard manager that we support SAVE_TARGETS. + (SAVE_TARGETS . ignore) (_EMACS_INTERNAL . xselect-convert-to-identity))) (provide 'select) ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-16 22:32 ` Chong Yidong @ 2011-05-16 23:01 ` David De La Harpe Golden 2011-05-17 17:31 ` Chong Yidong 0 siblings, 1 reply; 19+ messages in thread From: David De La Harpe Golden @ 2011-05-16 23:01 UTC (permalink / raw) To: Chong Yidong; +Cc: Taylor Venable, Emacs developers On 16/05/11 23:32, Chong Yidong wrote: > Taylor Venable<taylor@metasyntax.net> writes: > >> Just let me know if you come up with any possible fixes or workarounds >> and I'll be more than happy to test them. > > I'd like to find out if implementing the client side of the clipboard > manager spec, as David suggests, will reduce the slowness. Heh, I just tried essentially that a few minutes ago ...it doesn't. I was about to open an XFCE bug about the issue - will I go ahead and do so? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-16 23:01 ` David De La Harpe Golden @ 2011-05-17 17:31 ` Chong Yidong 2011-05-17 17:48 ` David De La Harpe Golden 0 siblings, 1 reply; 19+ messages in thread From: Chong Yidong @ 2011-05-17 17:31 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: Taylor Venable, Emacs developers David De La Harpe Golden <david@harpegolden.net> writes: > On 16/05/11 23:32, Chong Yidong wrote: >> Taylor Venable<taylor@metasyntax.net> writes: >> >>> Just let me know if you come up with any possible fixes or >>> workarounds and I'll be more than happy to test them. >> >> I'd like to find out if implementing the client side of the clipboard >> manager spec, as David suggests, will reduce the slowness. > > Heh, I just tried essentially that a few minutes ago ...it doesn't. > > I was about to open an XFCE bug about the issue - will I go ahead and > do so? Yes, please. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-17 17:31 ` Chong Yidong @ 2011-05-17 17:48 ` David De La Harpe Golden 2011-05-17 19:05 ` David De La Harpe Golden 0 siblings, 1 reply; 19+ messages in thread From: David De La Harpe Golden @ 2011-05-17 17:48 UTC (permalink / raw) To: Chong Yidong; +Cc: Taylor Venable, Emacs developers On 17/05/11 18:31, Chong Yidong wrote: > David De La Harpe Golden<david@harpegolden.net> writes: >> I was about to open an XFCE bug about the issue - will I go ahead and >> do so? > > Yes, please. right so. filed as XFCE bug #7633 https://bugzilla.xfce.org/show_bug.cgi?id=7633 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: Strange slowness when killing words interactively 2011-05-17 17:48 ` David De La Harpe Golden @ 2011-05-17 19:05 ` David De La Harpe Golden 0 siblings, 0 replies; 19+ messages in thread From: David De La Harpe Golden @ 2011-05-17 19:05 UTC (permalink / raw) To: Taylor Venable; +Cc: Chong Yidong, Emacs developers On 17/05/11 18:48, David De La Harpe Golden wrote: > right so. filed as XFCE bug #7633 > > https://bugzilla.xfce.org/show_bug.cgi?id=7633 ...and in reply at that link, Nick Schermer says that it had already been fixed in xfce's master branch. So, good news, problem should just go away when there is a new XFCE release with the changes and you upgrade to it. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2011-05-17 19:05 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-04-27 1:30 Strange slowness when killing words interactively Taylor Venable 2011-05-02 0:22 ` Taylor Venable 2011-05-02 1:13 ` Chong Yidong 2011-05-02 4:25 ` Taylor Venable 2011-05-02 16:32 ` David De La Harpe Golden 2011-05-03 1:14 ` Taylor Venable 2011-05-03 4:30 ` David De La Harpe Golden 2011-05-03 5:12 ` Stephen J. Turnbull 2011-05-03 11:51 ` Taylor Venable 2011-05-04 5:36 ` David De La Harpe Golden 2011-05-07 2:52 ` Taylor Venable 2011-05-09 1:18 ` David De La Harpe Golden 2011-05-09 3:08 ` David De La Harpe Golden 2011-05-14 12:59 ` Taylor Venable 2011-05-16 22:32 ` Chong Yidong 2011-05-16 23:01 ` David De La Harpe Golden 2011-05-17 17:31 ` Chong Yidong 2011-05-17 17:48 ` David De La Harpe Golden 2011-05-17 19:05 ` David De La Harpe Golden
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.