sbaugh@catern.com writes: > Po Lu writes: >> sbaugh@catern.com writes: >> >>> Po Lu writes: >>> >>>> Spencer Baugh writes: >>>> >>>>> When you do that, you interrupt the operation which is trying to add a >>>>> new kill. If you interrupt it and try again, you'll just get the same >>>>> long delay again. There's no way to mitigate this from within Emacs, >>>>> other than by turning off save-interprogram-paste-before-kill. >>>> >>>> Then I guess the solution is to temporarily disable >>>> `save-interprogram-paste-before-kill' if a quit arrives while it is >>>> reading selection data. >>> >>> That would be a decent solution. Although I'm not sure how we'd >>> implement it. We want to, somehow, know that after a selection-transfer >>> has been aborted, we should not try to transfer that selection again. >>> Is that something we can check? Whether the selection has changed, >>> without transferring it? >> >> Emacs will probably assert ownership of the selection after the kill >> takes place, anyway, so there is no need. > > Good point! So maybe if a quit arrives while we're reading the > selection in kill-new, we should immediately take ownership of the > selection. With an condition-case, perhaps. > > Or... just ignore the quit. If we're reading the selection in kill-new > and there's a quit, just proceed to doing the kill. Here is an implementation of that. I think this is the right strategy and I'm glad we discussed this, I think this will behave better for users than my original suggestion, and this way doesn't require any configuration.