* bug#6774: Cut and paste with C-w/mouse-2 not working? @ 2010-08-01 22:04 Angelo Graziosi 2010-08-02 4:12 ` David De La Harpe Golden 2010-08-02 13:33 ` Angelo Graziosi 0 siblings, 2 replies; 74+ messages in thread From: Angelo Graziosi @ 2010-08-01 22:04 UTC (permalink / raw) To: 6774 It seems that with recent trunk sources (also with the last, rev.100958), cutting with C-w and then pasting with mouse-2 does not work. To reproduce: 1. emacs -Q & 2. In the 'scratch' buffer double click on some text, 'buffer', for example. 3. Now cut it: C-w 4. Go to the bottom of the buffer and paste with mouse-2: empty! I can paste only with C-y. If at step 3. I use M-w (Copy), then pasting with mouse-2 works. The above occurs with GNU/Linux Kubuntu 10.04 and Cygwin builds (GTK) of Emacs. For example, on Kubuntu, one can cut with C-x and the paste with mouse-2 (Konqueror, Kate,...) Ciao, Angelo. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-01 22:04 bug#6774: Cut and paste with C-w/mouse-2 not working? Angelo Graziosi @ 2010-08-02 4:12 ` David De La Harpe Golden [not found] ` <4C56C8F0.2010104@alice.it> 2010-08-02 19:41 ` Chong Yidong 2010-08-02 13:33 ` Angelo Graziosi 1 sibling, 2 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-02 4:12 UTC (permalink / raw) To: Angelo Graziosi; +Cc: 6774, Chong Yidong On 01/08/10 23:04, Angelo Graziosi wrote: > It seems that with recent trunk sources (also with the last, > rev.100958), cutting with C-w and then pasting with mouse-2 does not > work. To reproduce: > > 1. emacs -Q & > > 2. In the 'scratch' buffer double click on some text, 'buffer', for > example. > > 3. Now cut it: C-w > > 4. Go to the bottom of the buffer and paste with mouse-2: empty! > > I can paste only with C-y. If at step 3. I use M-w (Copy), then pasting > with mouse-2 works. > Yes, there's a problem here - I guess emacs is keeping primary bound to a span that's become zero-length. Again. N.B. your case ideally would work in emacs much like in KDE - but emacs still has teething problems and sometimes manages to make primary a zero-length string.[this is already "fixed" in the horrible selx branch] > For example, on Kubuntu, one can cut with C-x and the paste with mouse-2 > (Konqueror, Kate,...) Not exactly - not quite what's really going on. There's a spec for how this is supposed to work, and KDE follows it.* When you have _selected_ the text in KDE before hitting C-x, it is made available as the "primary" x11 selection (referred to as "the selection" in klipper*) C-x makes the text available as the CLIPBOARD x11 selection while removing it from the body of the document. (and it's still available on PRIMARY too, where emacs fails). mouse-2 inserts what's in PRIMARY in KDE. So in KDE, try selecting more/different text, _without_ hitting C-x or C-c. This will change only PRIMARY. Hitting mouse-2 again will insert the _new_ PRIMARY. Then hitting C-v will insert the old CLIPBOARD. To update the clipboard you always have to C-x or C-c. (* though the situation is further complicated by klipper, the KDE clipboard daemon, which can be configured to do various strange things in this area, I mean KDE's out-of-box defaults). ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <4C56C8F0.2010104@alice.it>]
* bug#6774: Cut and paste with C-w/mouse-2 not working? [not found] ` <4C56C8F0.2010104@alice.it> @ 2010-08-02 14:52 ` David De La Harpe Golden 0 siblings, 0 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-02 14:52 UTC (permalink / raw) To: Angelo Graziosi; +Cc: 6774, Chong Yidong On 02/08/10 14:32, Angelo Graziosi wrote: > I do not doubt that, internally, things are different. Anyway, from the > 'End User' point of view, Well, the whole area is end-user visible. > C-w/mouse-2 (in Emacs) > > should behave in the same way of > > C-X/mouse-2 (in other X applications like Konqueror, Kate etc.) > Well, beware Chong Yidong has already brought to light other recent X applications where that doesn't work - try it in GNOME gedit... That said, I think the KDE Kate type behaviour is obviously more useful, more common, and more in keeping with the intent of the spec if not the letter, and the one to aim for. > So, at the moment, Emacs, in this regard (Copy/Paste), from the 'End > User' point of view, behaves differently from other X applications. Undoubtedly. It didn't historically behave like other (recent*) X applications either though. In the specific case of C-w directly followed by mouse-2 it may have appeared to but something quite different was going on behind the scenes. This attempt to make it do so is relatively new (well what's really new is that it was switched on by default, exposing it to a greater userbase and exposing a host of problems...). If you are interested to try the experimental branch I mentioned you'll probably find it acts more sensibly in this area: bzr branch lp:~ddlhg/emacs/selx It's just not in a fit state for inclusion wholesale in emacs at time of writing, but you might be able to say if it's the behaviour you expect, and then maybe we can find a somewhat saner way to actually implement it. > BTW, if I add the step: > 1.1 I choose: Options | C-x/.../C-v Cut and Paste (CUA) > then C-x/mouse-2, in Emacs still does not work! Nor would it be expected to, until the underlying issue is addressed. All (well not all, but for our present purposes) CUA mode does is make C-x/C-c/C-v in emacs act like C-w/M-w/C-y in eamcs. Note this is THE major problem with the unhelpful "oh just turn on cua mode" response emacs newbies sometimes get to their whining about "cut and paste not working right". The problem isn't the bindings: If %(emacs' C-w/M-w/C-y) doesn't act like $(other apps' C-x/C-c/C-v), then making &(emacs' C-x/C-c/C-y) act like %(emacs' C-w/M-y/C-y) still doesn't make &(emacs' C-x/C-c/C-y) act like $(other apps' C-x/C-c/C-v) * It's worth bearing in mind that emacs has been around a _lot_ longer than these newfangled standardisations, and many long-time emacs users actively prefer the now-quirky emacs historic behaviour. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-02 4:12 ` David De La Harpe Golden [not found] ` <4C56C8F0.2010104@alice.it> @ 2010-08-02 19:41 ` Chong Yidong 2010-08-02 20:30 ` David De La Harpe Golden 1 sibling, 1 reply; 74+ messages in thread From: Chong Yidong @ 2010-08-02 19:41 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: 6774, Angelo Graziosi David De La Harpe Golden <david@harpegolden.net> writes: > Yes, there's a problem here - I guess emacs is keeping primary bound > to a span that's become zero-length. Again. After thinking about this, my opinion is that the Emacs command loop---or rather prepare_to_modify_buffer in insdel.c---should make a copy of the primary selection before running before-change-functions. Then, deactivate-mark should check if the resulting string is empty; and, if so, set the primary to that saved copy. I haven't looked at your branch; is this the approach you implemented? ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-02 19:41 ` Chong Yidong @ 2010-08-02 20:30 ` David De La Harpe Golden 2010-08-02 20:33 ` David De La Harpe Golden ` (3 more replies) 0 siblings, 4 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-02 20:30 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi On 02/08/10 20:41, Chong Yidong wrote: > David De La Harpe Golden<david@harpegolden.net> writes: > >> Yes, there's a problem here - I guess emacs is keeping primary bound >> to a span that's become zero-length. Again. > > After thinking about this, my opinion is that the Emacs command > loop---or rather prepare_to_modify_buffer in insdel.c---should make a > copy of the primary selection before running before-change-functions. > Then, deactivate-mark should check if the resulting string is empty; > and, if so, set the primary to that saved copy. > > I haven't looked at your branch; is this the approach you implemented? Not reallym, though my branch certainly ended up altering the command loop to save a copy of the primary selection before commands - doing that where you say may be more selective to commands that are going to modify, and therefore more efficient. Does your way work properly in a multi-window context on its own, though? I suspect not -that it will deactivate-mark on "boring" restored active regions (see below) and set the selection to the "boring" region, confounding user expectations, because the restored region could be non-empty. So I'll try and have a go explaining the key points of the branch, then, bearing in mind it was focussed mostly on making multi-window/frame stuff work, and the zero length fixes came along for the ride. On the whole, grabbing it locally and giving it a go may be worthwhile, might be faster than reading the below! At this stage, the sheer length of the explanation below suggests the approach is just too ugly. I may be stuck in a rut on it (the trouble is it _does_ give quite nice results...). Just doing it eagerly may be better. However, one of the non-efficiency reasons for the laziness was because certain gestures in emacs are really effectively "long running commands" that you can stop and switch to another application in the middle of (track-mouse...), and something happening purely before/after commands can leave the region stale, and the laziness skirted that. The thing is, if you use focus-follows-mouse between frames, or mouse autoselect-window between emacs windows, you select_window without going through "normal channels", so trying to do _anything_ smart in deactivate-mark tends to break - e.g. the mark is being deactivated in a window different to the last window bound to the selection. The selx branch just forces the selection to a string if it's lazy-bound to a window and emacs still owns it on deactivate mark. 1. Introduce a save/restore of mark and mark-active state as well as point on select_window window switching. The restore would be controversial, but could easily be made optional - the saving is the important bit for our purposes, the restore is a "new feature". This bit might be independently a nice feature, at least. 2. Allow selections to be lazy-bound to window rather than buffer. (this is unfinished - in both window and buffer cases should really walk the selection_alist and force the lazy selections before deletion of the window/buffer. When the selection is bound to a window, it is the span between the window-mark and window-point. 3. Introduce a x-force-lazy-selection to force a selection to a string if it is lazy-bound to a buffer. This is currently only a placeholder inefficient implementation, doing it even if unnecessary (i.e. selection is already a string), it could be made more efficient by checking if forcing is necessary - but owing to the split of the code between C and Lisp, that would probably mean moving it to C. 4. Introduce a notion of the region being "interesting" or "boring". If a region is zero-length _or_ matching the saved boring region extent, consider it boring. 6. make select_window set the region boring when it restores the region. This preserves temporal ordering of selection with respect to user explicit selection actions rather than programmatic restores. 5. If select-active-region is called, test if the region is interesting. If it isn't (boring/zero), don't select, just set a "select-active-region-maybe" flag. If it isn't boring, set it to the current window. 6. Before each command in the command loop, if select-active-region maybe, check again if the region is interesting. 7. Force the primary selection (ideally this would be more efficient as in 3), effectively freezing off a string. 8. After each command, call select-active-region again to check if the region is interesting and "thaw". 9. In deactivate mark, force the selection in case it's lazy. Since we can't actually tell if we're in the window that the selection was bound to, it's _un_safe to use buffer-substring, have to go through x-force-lazy-selection. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-02 20:30 ` David De La Harpe Golden @ 2010-08-02 20:33 ` David De La Harpe Golden 2010-08-02 20:53 ` David De La Harpe Golden ` (2 subsequent siblings) 3 siblings, 0 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-02 20:33 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi On 02/08/10 21:30, David De La Harpe Golden wrote: > Just doing it eagerly may be better. However, one of the non-efficiency > reasons for the laziness was because certain gestures in emacs are > really effectively "long running commands" that you can stop and switch > to another application in the middle of (track-mouse...), and something > happening purely before/after commands can leave the region stale, Gaah, sorry, can leave the (x11) _selection_ stale - you get strange things like the primary containing only the first letter of the active region that's visible onscreen, say. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-02 20:30 ` David De La Harpe Golden 2010-08-02 20:33 ` David De La Harpe Golden @ 2010-08-02 20:53 ` David De La Harpe Golden 2010-08-02 20:59 ` Chong Yidong [not found] ` <mailman.23.1280783288.5118.bug-gnu-emacs@gnu.org> 3 siblings, 0 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-02 20:53 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi On 02/08/10 21:30, David De La Harpe Golden wrote: > > 3. Introduce a x-force-lazy-selection to force a selection to a string > if it is lazy-bound to a buffer. [... or window or marker cons or overlay, i.e. all the lazy possibilities] Sigh. I read that more than once before hitting send. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-02 20:30 ` David De La Harpe Golden 2010-08-02 20:33 ` David De La Harpe Golden 2010-08-02 20:53 ` David De La Harpe Golden @ 2010-08-02 20:59 ` Chong Yidong 2010-08-02 21:35 ` David De La Harpe Golden [not found] ` <mailman.23.1280783288.5118.bug-gnu-emacs@gnu.org> 3 siblings, 1 reply; 74+ messages in thread From: Chong Yidong @ 2010-08-02 20:59 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: 6774, Angelo Graziosi David De La Harpe Golden <david@harpegolden.net> writes: > Does your way work properly in a multi-window context on its own, > though? I suspect not -that it will deactivate-mark on "boring" > restored active regions (see below) and set the selection to the > "boring" region, confounding user expectations, because the restored > region could be non-empty. > > The thing is, if you use focus-follows-mouse between frames, or mouse > autoselect-window between emacs windows, you select_window without > going through "normal channels", so trying to do _anything_ smart in > deactivate-mark tends to break - e.g. the mark is being deactivated in > a window different to the last window bound to the selection. The selx > branch just forces the selection to a string if it's lazy-bound to a > window and emacs still owns it on deactivate mark. You're right, the window-switching code needs to be able to change the X selection buffer if switching into a window where there is an active region. But with this change, is there any case that my proposal---i.e. saving a copy before before-change-functions, for deactivate-mark to refer to if the region ends up empty---would not handle? Assuming that the current buffer and the active region can only change as a result of a user command or window switching, those are the only cases that we have to cover. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-02 20:59 ` Chong Yidong @ 2010-08-02 21:35 ` David De La Harpe Golden 2010-08-02 22:26 ` David De La Harpe Golden 2010-08-05 2:20 ` Chong Yidong 0 siblings, 2 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-02 21:35 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi On 02/08/10 21:59, Chong Yidong wrote: > David De La Harpe Golden<david@harpegolden.net> writes: > >> Does your way work properly in a multi-window context on its own, >> though? I suspect not -that it will deactivate-mark on "boring" >> restored active regions (see below) and set the selection to the >> "boring" region, confounding user expectations, because the restored >> region could be non-empty. >> >> The thing is, if you use focus-follows-mouse between frames, or mouse >> autoselect-window between emacs windows, you select_window without >> going through "normal channels", so trying to do _anything_ smart in >> deactivate-mark tends to break - e.g. the mark is being deactivated in >> a window different to the last window bound to the selection. The selx >> branch just forces the selection to a string if it's lazy-bound to a >> window and emacs still owns it on deactivate mark. > > You're right, the window-switching code needs to be able to change the X > selection buffer if switching into a window where there is an active > region. > well, hold on - see the problem report on emacs-devel [1][2], my goal was to _not_ bind the selection to the new buffer of the restored active region on window change, but rather leave it as the old selection, and consider the restored active region "boring" until it changes again, at which point it becomes the selection. Try it between two kate windows both with selected text, say - note how the selection doesn't change depending on which window you're currently in, it depends on the last text the user actively selected. > But with this change, is there any case that my proposal---i.e. saving a > copy before before-change-functions, for deactivate-mark to refer to if > the region ends up empty---would not handle? Assuming that the current > buffer and the active region can only change as a result of a user > command or window switching, those are the only cases that we have to > cover. I'm a bit tired at this stage, sorry, I'm not sure I'm talking sense. The problem is that we may really want the selection bound to something _non-current_, if we don't want it to instantly reflect a restored boring active region as per above. And there's the two-windows-onto-the-same buffer case to consider, that means lazy-binding the selection to a buffer rather than window can't work very well, was the first reason I had for adding the lazy-binding to windows (and extending windows struct to record a per-window mark as well as point...). [1] http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01258.html [2] http://lists.gnu.org/archive/html/emacs-devel/2010-07/msg01314.html ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-02 21:35 ` David De La Harpe Golden @ 2010-08-02 22:26 ` David De La Harpe Golden 2010-08-05 2:20 ` Chong Yidong 1 sibling, 0 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-02 22:26 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774 ...Oh, guess I went round in a big circle... http://debbugs.gnu.org/cgi/bugreport.cgi?bug=902#80 > maybe it should be copying and "holding" as a string the selection before a command runs > ... > OTOH, that sounds more complex, and such cases don't seem to arise much (or at all) in practice - at least I haven't noticed them. ... d'oh! I'm certainly becoming concerned these contortions to preserve some laziness may be worse than just accepting a requirement to update a string selection where necessary and its overhead. Humph ...do we have copy-on-write buffers... ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-02 21:35 ` David De La Harpe Golden 2010-08-02 22:26 ` David De La Harpe Golden @ 2010-08-05 2:20 ` Chong Yidong 2010-08-05 23:50 ` David De La Harpe Golden 1 sibling, 1 reply; 74+ messages in thread From: Chong Yidong @ 2010-08-05 2:20 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: 6774, Angelo Graziosi David De La Harpe Golden <david@harpegolden.net> writes: > The problem is that we may really want the selection bound to > something _non-current_, if we don't want it to instantly reflect a > restored boring active region as per above. And there's the > two-windows-onto-the-same buffer case to consider It would be nice to leave boring selections alone, but it doesn't seem worth it if a lot of new infrastructure has to be added to handle this. If this problem can't be solved simply, I would prefer to tweak the behavior of select-active-regions instead. Here's an idea: When the mark is set for a temporarily active region---a region created by mouse dragging or shift selection---we keep the current behavior; i.e. (x-set-selection 'PRIMARY (current-buffer)). Otherwise, do *not* call x-set-selection when setting the mark. Before any change to the buffer, save a copy of the region if the mark is active, whether or not the region is temporary. In deactivate-mark, whether or not the region is temporary, set the primary selection to the region that we just deactivated, or to the saved copy if that region is empty. The main difference, as you see, is that non-temporary regions made with C-SPC would not affect the primary selection until deactivation (either via buffer change, or commands such as M-w). ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-05 2:20 ` Chong Yidong @ 2010-08-05 23:50 ` David De La Harpe Golden 2010-08-06 7:43 ` Eli Zaretskii 2010-08-06 15:28 ` Chong Yidong 0 siblings, 2 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-05 23:50 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi On 05/08/10 03:20, Chong Yidong wrote: > > It would be nice to leave boring selections alone, > but it doesn't seem worth it if a lot of new infrastructure > has to be added to handle this. > Well, complexity mostly arose from doing it while preserving vestiges of the existing lazy approach. Yes, the laziness seemed elegant, but I'm concerned it's a dead end - it may be easier to get everything right by starting out by setting the selection to a string when we want it set to something new, and not setting it when we don't (thereby preventing the select_window problems by not doing anything). That would also mean the w32/ns select layers would need less work. Then, [re-]reducing consing would be a desirable performance-enhancing optimization, but could still be approached via a lazy span reference into a buffer that gets stringified at pre-modification or when/if (os) selection servicing asks for it, only with the span acting as more of a drop-in replacement for the strings the selection is being set to in part 1, rather than being directly related to the mark/point. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-05 23:50 ` David De La Harpe Golden @ 2010-08-06 7:43 ` Eli Zaretskii 2010-08-06 9:13 ` Stefan Monnier 2010-08-06 15:28 ` Chong Yidong 1 sibling, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2010-08-06 7:43 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: cyd, 6774, angelo.graziosi > Date: Fri, 06 Aug 2010 00:50:00 +0100 > From: David De La Harpe Golden <david@harpegolden.net> > Cc: 6774@debbugs.gnu.org, Angelo Graziosi <angelo.graziosi@alice.it> > > Well, complexity mostly arose from doing it while preserving vestiges of > the existing lazy approach. Yes, the laziness seemed elegant, but I'm > concerned it's a dead end - it may be easier to get everything right by > starting out by setting the selection to a string when we want it set to > something new, and not setting it when we don't (thereby preventing the > select_window problems by not doing anything). But that would mean setting the selection each time the user does a C-w or M-w or any other action that pushes text on the kill ring, won't it? If so, I'm afraid it would make Emacs routine ops significantly slower, and for no good reason: most Emacs ops have nothing to do with pasting in other apps. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-06 7:43 ` Eli Zaretskii @ 2010-08-06 9:13 ` Stefan Monnier 2010-08-06 10:50 ` Eli Zaretskii 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-06 9:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 6774, angelo.graziosi > But that would mean setting the selection each time the user does a > C-w or M-w or any other action that pushes text on the kill ring, > won't it? Isn't that what Emacs has been doing for the last 10 years? Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-06 9:13 ` Stefan Monnier @ 2010-08-06 10:50 ` Eli Zaretskii 2010-08-06 12:21 ` Kenichi Handa 2010-08-06 20:17 ` David De La Harpe Golden 0 siblings, 2 replies; 74+ messages in thread From: Eli Zaretskii @ 2010-08-06 10:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: David De La Harpe Golden <david@harpegolden.net>, cyd@stupidchicken.com, 6774@debbugs.gnu.org, angelo.graziosi@alice.it > Date: Fri, 06 Aug 2010 11:13:50 +0200 > > > But that would mean setting the selection each time the user does a > > C-w or M-w or any other action that pushes text on the kill ring, > > won't it? > > Isn't that what Emacs has been doing for the last 10 years? Not as far as I know. Maybe I was living in some pipe dream, but I always thought the actual copying happened only when some other application actually requests the selection. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-06 10:50 ` Eli Zaretskii @ 2010-08-06 12:21 ` Kenichi Handa 2010-08-06 13:17 ` Jan Djärv 2010-08-06 20:17 ` David De La Harpe Golden 1 sibling, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2010-08-06 12:21 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 6774, angelo.graziosi In article <83iq3ovwv0.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes: > > > But that would mean setting the selection each time the user does a > > > C-w or M-w or any other action that pushes text on the kill ring, > > > won't it? > > > > Isn't that what Emacs has been doing for the last 10 years? > Not as far as I know. Maybe I was living in some pipe dream, but I > always thought the actual copying happened only when some other > application actually requests the selection. The following is my current understanding about Emacs 23 and the earlier. C-w or M-w leads to call of interprogram-cut-function which is usually bound to x-select-text. On X, it does rather complicated things. At first, it copies the data string to CUT_BUFFER0. Each window of X can have properties and CUT_BUFFER0 is one of them. So, the data is transferred from Emacs to X server, but it's not the inter-client copying. This is a semi-heavy process. Next, if x-select-enable-primary is non-nil (the default is t), Emacs declares to own PRIMARY selection. In this case, the data string is not copied but just saved in the internal list Vselection_alist. This is a light process. The saved data is transferred to another client later when requested. At last, if x-select-enable-clipboard is non-nil (the default is nil), Emacs declares to own CLIPBOARD selection. The treatment of the data string is the same as above, i.e. not copied. But!, if a clipboard client is also running (it seems that is the default on Ubuntu), as soon as Emacs owns CLIPBOARD selection, it requests to get CLIPBOARD selection data from Emacs, and the data is transferred from Emacs to the clipboard client. This is the inter-client copying, and a heavy process. So, Emacs had been doing some kind of copying on each C-w and M-w, but the default setting avoided the heaviest process. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-06 12:21 ` Kenichi Handa @ 2010-08-06 13:17 ` Jan Djärv 2010-08-06 20:23 ` David De La Harpe Golden 0 siblings, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-06 13:17 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi Kenichi Handa skrev 2010-08-06 14.21: > > At first, it copies the data string to CUT_BUFFER0. Each > window of X can have properties and CUT_BUFFER0 is one of > them. So, the data is transferred from Emacs to X server, > but it's not the inter-client copying. This is a semi-heavy > process. > We should get rid of all cut buffer stuff now that we are modifying selections. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-06 13:17 ` Jan Djärv @ 2010-08-06 20:23 ` David De La Harpe Golden 0 siblings, 0 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-06 20:23 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 6774, angelo.graziosi On 06/08/10 14:17, Jan Djärv wrote: > We should get rid of all cut buffer stuff now that we are modifying > selections. That definitely would be nice, they're quite thoroughly obsolete and a significant complication in the x11 code. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-06 10:50 ` Eli Zaretskii 2010-08-06 12:21 ` Kenichi Handa @ 2010-08-06 20:17 ` David De La Harpe Golden 1 sibling, 0 replies; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-06 20:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 6774, angelo.graziosi On 06/08/10 11:50, Eli Zaretskii wrote: >> From: Stefan Monnier<monnier@iro.umontreal.ca> >> Cc: David De La Harpe Golden<david@harpegolden.net>, cyd@stupidchicken.com, 6774@debbugs.gnu.org, angelo.graziosi@alice.it >> Date: Fri, 06 Aug 2010 11:13:50 +0200 >> >>> But that would mean setting the selection each time the user does a >>> C-w or M-w or any other action that pushes text on the kill ring, >>> won't it? >> >> Isn't that what Emacs has been doing for the last 10 years? > > Not as far as I know. Maybe I was living in some pipe dream, but I > always thought the actual copying happened only when some other > application actually requests the selection. I was talking about a second level of intra-emacs laziness that exists in the present select-active-regions implementation, not inter-application stuff. See, on X11 you can x-set-selection the _emacs-level_ selection (stored internally on selection_alist) to a non-string value that merely references a buffer, so that when/if another application requests the selection, it is looked up all the way back to a buffer (or cons of markers). The current select-active-regions implementation works that way, and thereby avoids an emacs-internal string copy sometimes (in cases like C-w/M-w that internal copy happens anyway). My proposal was to consider that a premature optimization, go back to basics, then re-optimise by reintroducing some emacs-internal laziness in a more controlled fashion. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-05 23:50 ` David De La Harpe Golden 2010-08-06 7:43 ` Eli Zaretskii @ 2010-08-06 15:28 ` Chong Yidong 2010-08-06 21:05 ` David De La Harpe Golden 1 sibling, 1 reply; 74+ messages in thread From: Chong Yidong @ 2010-08-06 15:28 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: 6774, Angelo Graziosi David De La Harpe Golden <david@harpegolden.net> writes: > Well, complexity mostly arose from doing it while preserving vestiges > of the existing lazy approach. Yes, the laziness seemed elegant, but > I'm concerned it's a dead end - it may be easier to get everything > right by starting out by setting the selection to a string when we > want it set to something new, and not setting it when we don't > (thereby preventing the select_window problems by not doing anything). Before discussing the underlying mechanics, let's figure out what the end result should be. The main question in my mind is this: for active regions made with C-SPC, as opposed to shift-selection or mouse dragging, do we want mere cursor motion to update the selection? (There is nothing analogous in other programs.) I think the best answer is no. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-06 15:28 ` Chong Yidong @ 2010-08-06 21:05 ` David De La Harpe Golden 2010-08-07 19:50 ` Chong Yidong 0 siblings, 1 reply; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-06 21:05 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi On 06/08/10 16:28, Chong Yidong wrote: > The main question in my mind is this: for active > regions made with C-SPC, as opposed to shift-selection or mouse > dragging, do we want mere cursor motion to update the selection? (There > is nothing analogous in other programs.) > > I think the best answer is no. Well, select-active-regions was introduced (though not made default) rather before the ^-type shift-selection appeared AFAIK. From my perspective, it would be breaking something that was largely working as initially intended and (unlike with the general defaults change) not giving the option of having it work the way it did* anymore (well, apart from patching it in locally, I'm hardly incapable of doing that). If you do choose to go that route, at least consider making c-spc active regions and shift/mouse active regions visually distinct, so the differing selection behaviour is less surprising (not how the secondary selection is presented in a different color in emacs, for example) - I mean, that was historically an annoyance with mouse selection, its interaction with x11 selection and the kill-ring was significantly different to keyboard selection, despite the similar presentation. * or at least, as it did, only with several now-known outstanding issues fixed, of course. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-06 21:05 ` David De La Harpe Golden @ 2010-08-07 19:50 ` Chong Yidong 2010-08-07 23:05 ` David De La Harpe Golden 2010-08-07 23:08 ` Angelo Graziosi 0 siblings, 2 replies; 74+ messages in thread From: Chong Yidong @ 2010-08-07 19:50 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: 6774, Angelo Graziosi David De La Harpe Golden <david@harpegolden.net> writes: > Well, select-active-regions was introduced (though not made default) > rather before the ^-type shift-selection appeared AFAIK. From my > perspective, it would be breaking something that was largely working > as initially intended and (unlike with the general defaults change) > not giving the option of having it work the way it did* anymore (well, > apart from patching it in locally, I'm hardly incapable of doing > that). I've checked in some changes that should (fingers crossed) fix the "empty selection" problem. This also eliminates the use of x-set-selection to buffer variables, as you suggested. Now, Emacs copies strings out explicitly in the command loop and in `deactivate-mark'. I added a new value to `select-active-regions', `lazy' (the default), which means to set the selection only when used, as described in an earlier email. Any other non-nil value gives something similar to the original behavior of select-active-regions. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-07 19:50 ` Chong Yidong @ 2010-08-07 23:05 ` David De La Harpe Golden 2010-08-09 2:55 ` Chong Yidong 2010-08-07 23:08 ` Angelo Graziosi 1 sibling, 1 reply; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-07 23:05 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi On 07/08/10 20:50, Chong Yidong wrote: > I've checked in some changes that should (fingers crossed) fix the > "empty selection" problem. This also eliminates the use of > x-set-selection to buffer variables, as you suggested. Well, yeah, my suggestion involved eliminating that, but you don't seem to be implementing quite what my suggestion was as such, not that you had any obligation to of course. On the plus side, I don't think I can replicate Angelo's actual reported issue anymore. Anyhow, it will take me some time to fully understand the changes, especially with the C level more involved. The multi-window problem definitely isn't fixed. > I added a new value to `select-active-regions', `lazy' (the default), > which means to set the selection only when used, Perhaps unsurprisingly, I found it near-instantly annoying. Is the primary motivation concern about out-of-box efficiency? Otherwise I really don't get why it'd be desirable. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-07 23:05 ` David De La Harpe Golden @ 2010-08-09 2:55 ` Chong Yidong 2010-08-09 11:43 ` Stefan Monnier 0 siblings, 1 reply; 74+ messages in thread From: Chong Yidong @ 2010-08-09 2:55 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: 6774, Angelo Graziosi David De La Harpe Golden <david@harpegolden.net> writes: >> I added a new value to `select-active-regions', `lazy' (the default), >> which means to set the selection only when used, > > Perhaps unsurprisingly, I found it near-instantly annoying. Is the > primary motivation concern about out-of-box efficiency? Otherwise I > really don't get why it'd be desirable. This approach is an effort to balance the expectations of other X applications, old Emacs behavior, and implementation simplicity/efficiency. There's no analogue to the Emacs's ordinary (C-SPC) active regions in other programs, and it's not even clear to me that it's good to set the primary selection under most circumstances. The original point of transient mark mode is to let you mark out a stretch of text to to operate on (e.g. comment, or search, or undo), and I don't know if it's really correct for us to set the primary selection at the same time. We can discuss the issue on emacs-devel, but first I'd like some time to think, and to see how the present behavior works in practice. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-09 2:55 ` Chong Yidong @ 2010-08-09 11:43 ` Stefan Monnier 2010-08-09 17:19 ` Jan Djärv 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-09 11:43 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi > There's no analogue to the Emacs's ordinary (C-SPC) active regions in > other programs, and it's not even clear to me that it's good to set the > primary selection under most circumstances. The original point of > transient mark mode is to let you mark out a stretch of text to to > operate on (e.g. comment, or search, or undo), and I don't know if it's > really correct for us to set the primary selection at the same time. Indeed, I don't think it's good to do so. The old behavior of setting PRIMARY only when killing the text seems like the right behavior. Why would we want to change that? Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-09 11:43 ` Stefan Monnier @ 2010-08-09 17:19 ` Jan Djärv 2010-08-10 7:29 ` Stefan Monnier 0 siblings, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-09 17:19 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, 6774, Angelo Graziosi Stefan Monnier skrev 2010-08-09 13.43: >> There's no analogue to the Emacs's ordinary (C-SPC) active regions in >> other programs, and it's not even clear to me that it's good to set the >> primary selection under most circumstances. The original point of >> transient mark mode is to let you mark out a stretch of text to to >> operate on (e.g. comment, or search, or undo), and I don't know if it's >> really correct for us to set the primary selection at the same time. > > Indeed, I don't think it's good to do so. The old behavior of setting > PRIMARY only when killing the text seems like the right behavior. > Why would we want to change that? > Because it would conflict with http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt, and most other X applications set PRIMARY without an explicit kill or copy. And because it is convinient to be able to select text and then paste with middle button in another application. Other applications do have active regions, like gedit and OpenOffice for example. Please don't change this. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-09 17:19 ` Jan Djärv @ 2010-08-10 7:29 ` Stefan Monnier 2010-08-10 14:01 ` Jan Djärv 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-10 7:29 UTC (permalink / raw) To: Jan Djärv; +Cc: Chong Yidong, 6774, Angelo Graziosi >>> There's no analogue to the Emacs's ordinary (C-SPC) active regions in >>> other programs, and it's not even clear to me that it's good to set the >>> primary selection under most circumstances. The original point of >>> transient mark mode is to let you mark out a stretch of text to to >>> operate on (e.g. comment, or search, or undo), and I don't know if it's >>> really correct for us to set the primary selection at the same time. >> >> Indeed, I don't think it's good to do so. The old behavior of setting >> PRIMARY only when killing the text seems like the right behavior. >> Why would we want to change that? > Because it would conflict with > http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt, and > most other X applications set PRIMARY without an explicit kill or copy. That doesn't mean that C-SPC C-f should set PRIMARY. It just means that some other operations should be considered as forms of copy/kill. > And because it is convinient to be able to select text and then paste > with middle button in another application. Indeed, and Emacs-23 does that fine by saying that mouse-selection performs a `copy'. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-10 7:29 ` Stefan Monnier @ 2010-08-10 14:01 ` Jan Djärv 2010-08-10 15:54 ` Stefan Monnier 0 siblings, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-10 14:01 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, 6774, Angelo Graziosi Stefan Monnier skrev 2010-08-10 09.29: >>> Indeed, I don't think it's good to do so. The old behavior of setting >>> PRIMARY only when killing the text seems like the right behavior. >>> Why would we want to change that? > >> Because it would conflict with >> http://standards.freedesktop.org/clipboards-spec/clipboards-latest.txt, and >> most other X applications set PRIMARY without an explicit kill or copy. > > That doesn't mean that C-SPC C-f should set PRIMARY. It just means that > some other operations should be considered as forms of copy/kill. I think it should and so does the applications that claim to conform. Pressing Shift-Left Arrow starts a selection in those X applications, and that sets PRIMARY. C-SPC C-f is Emacs way of doing shift-selection as I see it. > >> And because it is convinient to be able to select text and then paste >> with middle button in another application. > > Indeed, and Emacs-23 does that fine by saying that mouse-selection > performs a `copy'. But emacs 23.1 at least does not do this for shift-selection. That is unlike the other X apps. Why not take ownership of PRIMARY in this case? It is not as it is a performance issue. You don't have to copy the text until someone asks for it. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-10 14:01 ` Jan Djärv @ 2010-08-10 15:54 ` Stefan Monnier 2010-08-10 17:59 ` Jan Djärv 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-10 15:54 UTC (permalink / raw) To: Jan Djärv; +Cc: Chong Yidong, 6774, Angelo Graziosi > I think it should and so does the applications that claim to > conform. Pressing Shift-Left Arrow starts a selection in those > X applications, and that sets PRIMARY. C-SPC C-f is Emacs way of doing > shift-selection as I see it. We don't have to treat shift-selection in the same way that we treat C-SPC C-f. > But emacs 23.1 at least does not do this for shift-selection. That is > unlike the other X apps. Why not take ownership of PRIMARY in this case? > It is not as it is a performance issue. You don't have to copy the text > until someone asks for it. C-SPC may be used for other purposes (e.g. C-SPC C-SPC) Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-10 15:54 ` Stefan Monnier @ 2010-08-10 17:59 ` Jan Djärv 2010-08-11 7:46 ` Stefan Monnier 0 siblings, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-10 17:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, 6774, Angelo Graziosi Stefan Monnier skrev 2010-08-10 17.54: >> I think it should and so does the applications that claim to >> conform. Pressing Shift-Left Arrow starts a selection in those >> X applications, and that sets PRIMARY. C-SPC C-f is Emacs way of doing >> shift-selection as I see it. > > We don't have to treat shift-selection in the same way that we treat > C-SPC C-f. No, but wouldn't that be confusing? Why not treat selection the same regardless of how it was made? Is it for backwards compability? > >> But emacs 23.1 at least does not do this for shift-selection. That is >> unlike the other X apps. Why not take ownership of PRIMARY in this case? >> It is not as it is a performance issue. You don't have to copy the text >> until someone asks for it. > > C-SPC may be used for other purposes (e.g. C-SPC C-SPC) In that case the selection would be empty, one should not take ownership of PRIMARY in that case. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-10 17:59 ` Jan Djärv @ 2010-08-11 7:46 ` Stefan Monnier 2010-08-11 16:06 ` Jan Djärv 2010-08-12 3:54 ` Kenichi Handa 0 siblings, 2 replies; 74+ messages in thread From: Stefan Monnier @ 2010-08-11 7:46 UTC (permalink / raw) To: Jan Djärv; +Cc: Chong Yidong, 6774, Angelo Graziosi >> We don't have to treat shift-selection in the same way that we treat >> C-SPC C-f. > No, but wouldn't that be confusing? It's been that way in Emacs for a while and I can't remember any bug-report about it, so it doesn't seem like it's a real problem. > Why not treat selection the same regardless of how it was made? Is it > for backwards compability? Consistency is a good property, indeed. It's not always the most important one, tho. Backward compatibility is not the issue here, I think. The issue is "how do we implement it", AFAICT. > In that case the selection would be empty, one should not take ownership of > PRIMARY in that case. So the C-f (or any other movement) would cause the selection of PRIMARY? That would have to be performed in some kind of post-command-hook, which is undesirable. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-11 7:46 ` Stefan Monnier @ 2010-08-11 16:06 ` Jan Djärv 2010-08-11 20:17 ` Stefan Monnier 2010-08-12 3:54 ` Kenichi Handa 1 sibling, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-11 16:06 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, 6774, Angelo Graziosi Stefan Monnier skrev 2010-08-11 09.46: >> In that case the selection would be empty, one should not take ownership of >> PRIMARY in that case. > > So the C-f (or any other movement) would cause the selection of PRIMARY? > That would have to be performed in some kind of post-command-hook, which > is undesirable. Transient-mark mode must know when the selection is non-empty. How does it do it? It is only when the selection becomes non-empty we have to take ownership of the PRIMARY selection. Once you own selection you don't have to re-own it again just because the selection changed. You would have to disown it if the selection became empty. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-11 16:06 ` Jan Djärv @ 2010-08-11 20:17 ` Stefan Monnier 2010-08-11 21:26 ` Jan Djärv 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-11 20:17 UTC (permalink / raw) To: Jan Djärv; +Cc: Chong Yidong, 6774, Angelo Graziosi > Transient-mark mode must know when the selection is non-empty. It doesn't have to know that at all times. Only when an operation is performed on the region, at which time it's trivial to compare (point) and (mark) to figure out if it's empty. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-11 20:17 ` Stefan Monnier @ 2010-08-11 21:26 ` Jan Djärv 2010-08-11 21:32 ` Stefan Monnier 0 siblings, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-11 21:26 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, 6774@debbugs.gnu.org, Angelo Graziosi But some code must know where to put the region face. That happens at once. I thought tmm did that. Jan D. 11 aug 2010 kl. 22:17 skrev Stefan Monnier <monnier@iro.umontreal.ca>: >> Transient-mark mode must know when the selection is non-empty. > > It doesn't have to know that at all times. Only when an operation is > performed on the region, at which time it's trivial to compare (point) > and (mark) to figure out if it's empty. > > > Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-11 21:26 ` Jan Djärv @ 2010-08-11 21:32 ` Stefan Monnier 0 siblings, 0 replies; 74+ messages in thread From: Stefan Monnier @ 2010-08-11 21:32 UTC (permalink / raw) To: Jan Djärv; +Cc: Chong Yidong, 6774@debbugs.gnu.org, Angelo Graziosi > But some code must know where to put the region face. Good point, but the region face is actually handled specially by the display engine (I'm not very happy with this special case, actually and would much rather than it be handled all in Elisp). Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-11 7:46 ` Stefan Monnier 2010-08-11 16:06 ` Jan Djärv @ 2010-08-12 3:54 ` Kenichi Handa 2010-08-12 7:43 ` Jan Djärv 2010-08-12 8:29 ` Stefan Monnier 1 sibling, 2 replies; 74+ messages in thread From: Kenichi Handa @ 2010-08-12 3:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi In article <jwvlj8diok6.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: > So the C-f (or any other movement) would cause the selection of PRIMARY? When transient-mark-mode is on (including temporary one), I think yes. > That would have to be performed in some kind of post-command-hook, which > is undesirable. We can add a proper code to set_point_both like this code in init_iterator (xdisp.c). /* Non-zero if we should highlight the region. */ highlight_region_p = (!NILP (Vtransient_mark_mode) && !NILP (current_buffer->mark_active) && XMARKER (current_buffer->mark)->buffer != 0); /* Set IT->region_beg_charpos and IT->region_end_charpos to the start and end of a visible region in window IT->w. Set both to -1 to indicate no region. */ if (highlight_region_p /* Maybe highlight only in selected window. */ && (/* Either show region everywhere. */ [...] --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-12 3:54 ` Kenichi Handa @ 2010-08-12 7:43 ` Jan Djärv 2010-08-12 7:51 ` Kenichi Handa 2010-08-12 8:29 ` Stefan Monnier 1 sibling, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-12 7:43 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi Kenichi Handa skrev 2010-08-12 05.54: > We can add a proper code to set_point_both like this code in > init_iterator (xdisp.c). > > /* Non-zero if we should highlight the region. */ > highlight_region_p > = (!NILP (Vtransient_mark_mode) > && !NILP (current_buffer->mark_active) > && XMARKER (current_buffer->mark)->buffer != 0); > Don't you have to check that point != mark also? Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-12 7:43 ` Jan Djärv @ 2010-08-12 7:51 ` Kenichi Handa 0 siblings, 0 replies; 74+ messages in thread From: Kenichi Handa @ 2010-08-12 7:51 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 6774, angelo.graziosi In article <4C63A621.7020101@swipnet.se>, Jan Djärv <jan.h.d@swipnet.se> writes: > Kenichi Handa skrev 2010-08-12 05.54: > > We can add a proper code to set_point_both like this code in > > init_iterator (xdisp.c). > > > > /* Non-zero if we should highlight the region. */ > > highlight_region_p > > = (!NILP (Vtransient_mark_mode) > > && !NILP (current_buffer->mark_active) > > && XMARKER (current_buffer->mark)->buffer != 0); > > > Don't you have to check that point != mark also? Yes, of course. The above code is just an example. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-12 3:54 ` Kenichi Handa 2010-08-12 7:43 ` Jan Djärv @ 2010-08-12 8:29 ` Stefan Monnier 2010-08-12 12:14 ` Kenichi Handa 1 sibling, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-12 8:29 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi >> So the C-f (or any other movement) would cause the selection of PRIMARY? > When transient-mark-mode is on (including temporary one), I > think yes. >> That would have to be performed in some kind of post-command-hook, which >> is undesirable. > We can add a proper code to set_point_both like this code in > init_iterator (xdisp.c). Putting it in set_point_both would be much worse than on post-command-hook (set-point-both is a very low-level function, triggered in many more cases than just moving the cursor). Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-12 8:29 ` Stefan Monnier @ 2010-08-12 12:14 ` Kenichi Handa 2010-08-12 16:09 ` Stefan Monnier 0 siblings, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2010-08-12 12:14 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi In article <jwv62zgdynz.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> So the C-f (or any other movement) would cause the selection of PRIMARY? > > When transient-mark-mode is on (including temporary one), I > > think yes. >>> That would have to be performed in some kind of post-command-hook, which >>> is undesirable. > > We can add a proper code to set_point_both like this code in > > init_iterator (xdisp.c). > Putting it in set_point_both would be much worse than on > post-command-hook (set-point-both is a very low-level function, > triggered in many more cases than just moving the cursor). If a test to check if we have to newly own the PRIMARY selection is trivial, there should be no problem. Another candidate for checking that is somewher near here in command_loop_1 () (around line 1818). finalize: if (current_buffer == prev_buffer && last_point_position != PT && NILP (Vdisable_point_adjustment) && NILP (Vglobal_disable_point_adjustment)) { This place is similar to post-command-hook, but we can avoid unnecessary Lisp calls in many cases. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-12 12:14 ` Kenichi Handa @ 2010-08-12 16:09 ` Stefan Monnier 2010-08-12 17:11 ` Jan Djärv 2010-08-13 6:18 ` Kenichi Handa 0 siblings, 2 replies; 74+ messages in thread From: Stefan Monnier @ 2010-08-12 16:09 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi >> Putting it in set_point_both would be much worse than on >> post-command-hook (set-point-both is a very low-level function, >> triggered in many more cases than just moving the cursor). > If a test to check if we have to newly own the PRIMARY > selection is trivial, there should be no problem. And what do we do with the result of the check? This function too low-level to be able to perform the "set PRIMARY" from there. > Another candidate for checking that is somewher near here in > command_loop_1 () (around line 1818). > finalize: > if (current_buffer == prev_buffer > && last_point_position != PT > && NILP (Vdisable_point_adjustment) > && NILP (Vglobal_disable_point_adjustment)) > { > This place is similar to post-command-hook, but we can avoid > unnecessary Lisp calls in many cases. Yes, that's like post-command-hook. I'm more worried about the semantics than about the performance impact. Doing the "set PRIMARY" from C-w and friends is much easier and robust. Doing it in S-right is OK as well. Doing it in forward-char is not and doing it for `right' (by rebinding it to a new command) doesn't sound too attractive. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-12 16:09 ` Stefan Monnier @ 2010-08-12 17:11 ` Jan Djärv 2010-08-13 10:38 ` Stefan Monnier 2010-08-13 6:18 ` Kenichi Handa 1 sibling, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-12 17:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi Stefan Monnier skrev 2010-08-12 18.09: > I'm more worried about the semantics than about the performance impact. > Doing the "set PRIMARY" from C-w and friends is much easier and robust. How so? Just moving the cursor because of a C-f involves a lot more X calls that taking ownership of the PRIMARY selection. I don't understand how robustness is affected. If you want you can add lisp events that announce if the selection is non-empty and when it is empty and do things from lisp. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-12 17:11 ` Jan Djärv @ 2010-08-13 10:38 ` Stefan Monnier 2010-08-13 11:29 ` Eli Zaretskii 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-13 10:38 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 6774, angelo.graziosi >> I'm more worried about the semantics than about the performance impact. >> Doing the "set PRIMARY" from C-w and friends is much easier and robust. > How so? Just moving the cursor because of a C-f involves a lot more X calls > that taking ownership of the PRIMARY selection. I don't understand how > robustness is affected. The issue with robustness (when talking about post-command-hook) doesn't have much to do with heavy X calls (or performance), unless of course those calls can hang. The issue of robustness is that post-command-hook is not always run when you want or need it. E.g. you may want to run your hook if point is moved by a process-filter (or you may want to run that hook when the user is queried via y-or-n-p), but post-command-hook is not involved there. And OTOH post-command-hook may very well be run in the middle of a command (if it reads from the minibuffer, for example). These corner cases make post-command-hook brittle. I think that for select-active-region to work the way you seem to want it to work (i.e. auto-select as soon as the region is active and non-empty), the "right hook" to use would be something like a redisplay-hook (i.e. an active region is selected if/when it gets displayed). I would welcome such a hook, BTW, especially if it gets run *before* redisplay. Could be useful for reveal-mode and maybe also to move the region-face handling to Elisp. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-13 10:38 ` Stefan Monnier @ 2010-08-13 11:29 ` Eli Zaretskii 0 siblings, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2010-08-13 11:29 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Fri, 13 Aug 2010 12:38:06 +0200 > Cc: cyd@stupidchicken.com, 6774@debbugs.gnu.org, angelo.graziosi@alice.it > > I think that for select-active-region to work the way you seem to want > it to work (i.e. auto-select as soon as the region is active and > non-empty), the "right hook" to use would be something like > a redisplay-hook (i.e. an active region is selected if/when it gets > displayed). I would welcome such a hook, BTW, especially if it gets run > *before* redisplay. What exactly do you mean by "*before*" here? Is it okay to do that in redisplay_internal, as one of the first things, for example? Note that it's quite common for redisplay_internal to make a few quick checks, decide that it has nothing to do, and return without redisplaying anything. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-12 16:09 ` Stefan Monnier 2010-08-12 17:11 ` Jan Djärv @ 2010-08-13 6:18 ` Kenichi Handa 2010-08-13 10:40 ` Stefan Monnier 1 sibling, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2010-08-13 6:18 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi In article <jwvvd7fbyv0.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> Putting it in set_point_both would be much worse than on >>> post-command-hook (set-point-both is a very low-level function, >>> triggered in many more cases than just moving the cursor). > > If a test to check if we have to newly own the PRIMARY > > selection is trivial, there should be no problem. > And what do we do with the result of the check? This function too > low-level to be able to perform the "set PRIMARY" from there. I don't know your criteria for "too low-level". > > Another candidate for checking that is somewher near here in > > command_loop_1 () (around line 1818). > > finalize: > > if (current_buffer == prev_buffer > > && last_point_position != PT > > && NILP (Vdisable_point_adjustment) > > && NILP (Vglobal_disable_point_adjustment)) > > { > > This place is similar to post-command-hook, but we can avoid > > unnecessary Lisp calls in many cases. > Yes, that's like post-command-hook. > I'm more worried about the semantics than about the performance impact. > Doing the "set PRIMARY" from C-w and friends is much easier and robust. > Doing it in S-right is OK as well. Doing it in forward-char is not and > doing it for `right' (by rebinding it to a new command) doesn't sound > too attractive. I was wordering how "S-right" (and S-C-f, etc) are implemented. So, I read the code and was surprized by its complication. For every S-C-f, read_key_sequence sets this-command-keys-shift-translated to t and read_key_sequence_cmd to forward-char. Next, Fcall_interactively calls handle-shift-selection, and it sets transient-mark-mode to a special cons (only . ...). At last, command_loop_1, after execuing forward-char, does some check and eventually calls x-set-selection. The detail is more complicated. I don't claim that the code is too complicated. Perhaps, there's no other way; I don't know. Anyway, we are already doing that for forward-char. Doing a little bit more in command_loop_1 (and/or maybe in Fcall_interactively) shouldn't be a problem. It doesn't change the semantics of forward-char (as well as handling of S-C-f like above doesn't change the semantics). At least, command_loop_1 is not "too low-level" for calling x-set-selection. And, first of all, from a user point of view, as these two highlights a region exactly the same way (with the default setting), (1) S-C-n (2) C-@ C-n it's very confusing that they behave differently as to selection. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-13 6:18 ` Kenichi Handa @ 2010-08-13 10:40 ` Stefan Monnier 2010-08-16 8:16 ` Kenichi Handa 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-13 10:40 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi >>>> Putting it in set_point_both would be much worse than on >>>> post-command-hook (set-point-both is a very low-level function, >>>> triggered in many more cases than just moving the cursor). >> > If a test to check if we have to newly own the PRIMARY >> > selection is trivial, there should be no problem. >> And what do we do with the result of the check? This function too >> low-level to be able to perform the "set PRIMARY" from there. > I don't know your criteria for "too low-level". It's the same kind of level as the handling of the `intangible' property or of the various motion-hooks and those are notoriously problematic since they tend to break unrelated code which expects things like goto-char to have very few side-effects. Grep for inhibit-point-motion-hooks to have an idea of the problem. I'm sure we could make it work. But it's just a bad idea to go there. Doing it at the post-command-hook (aka command_loop_1) level is a much better alternative, although it suffers from several other problems. I.e. instead of breaking other code, it suffers from a lack of reliability because this hook has to handle many different cases, and sometimes it's not run at the time we need it (e.g. process filters, queries via read-event, ...). > I was wordering how "S-right" (and S-C-f, etc) are implemented. Pretty ugly. > So, I read the code and was surprized by its complication. For every > S-C-f, read_key_sequence sets this-command-keys-shift-translated to > t and read_key_sequence_cmd to forward-char. Important nitpick: it doesn't set it to "forward-char" but to "the command bound to the unshifted key" (i.e. same as it has always done, the only change for that S-C-f feature was to record the fact that the shift modifier had to be stripped to find the command). > Next, Fcall_interactively calls handle-shift-selection, and it sets > transient-mark-mode to a special cons (only . ...). At last, > command_loop_1, after execuing forward-char, does some check and > eventually calls x-set-selection. The detail is more complicated. The x-set-selection thingy for shift-selection should ideally be performed at the "same place" as the handle-shift-selection. But of course, if/since we do the x-set-selection for any active region (i.e. it's not specific to shift-selection), it makes sense to do it elsewhere. > Anyway, we are already doing that for forward-char. Doing a > little bit more in command_loop_1 (and/or maybe in > Fcall_interactively) shouldn't be a problem. It doesn't > change the semantics of forward-char (as well as handling of > S-C-f like above doesn't change the semantics). At least, > command_loop_1 is not "too low-level" for calling > x-set-selection. Yes, it's generally "OK" to do things in post-command-hook (aka command_loop_1), but it's brittle. > And, first of all, from a user point of view, as these two > highlights a region exactly the same way (with the default > setting), > (1) S-C-n > (2) C-@ C-n > it's very confusing that they behave differently as to > selection. I haven't seen any report indicating that users really get confused by that. But I'm not opposed to eliminating this confusion. I just really don't want to see it implemented in set_point_both, and I'm not excited to seeing it in command_loop_1 either. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-13 10:40 ` Stefan Monnier @ 2010-08-16 8:16 ` Kenichi Handa 2010-08-16 8:51 ` Jan Djärv 0 siblings, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2010-08-16 8:16 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi In article <jwvpqxmbz0i.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: > > And, first of all, from a user point of view, as these two > > highlights a region exactly the same way (with the default > > setting), > > (1) S-C-n > > (2) C-@ C-n > > it's very confusing that they behave differently as to > > selection. > I haven't seen any report indicating that users really get confused > by that. As I don't like transient-mark-mode (both the default one and the temporary one), I have not used it. But, for the discussion of this thread, I tried it and found the current behaviour is confusing. > But I'm not opposed to eliminating this confusion. I just > really don't want to see it implemented in set_point_both, and I'm not > excited to seeing it in command_loop_1 either. How about this? We own the primary selection when mark is activated by C-@ in transient-mark-mode or C-@ C-@ not in transient-mark-mode, and record somehow that selection is owned that way (i.e. selection contents is a text in the region). At that time the contents is null, but I think it's not the problem. We do nothing special for all point moving commands (except for highlighting the region). When Emacs receives selection request, it returns the text in the region if the selection is still owned as the above way. We disown the selection when mark is deactivated. And any commands that cut/copy text own the selection too but in the different way (i.e. the way done by the current code). The handling of shift-selection and selecting-by-mouse-dragging can use this mechanism which causes less internal text-copying. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-16 8:16 ` Kenichi Handa @ 2010-08-16 8:51 ` Jan Djärv 2010-08-17 1:44 ` Kenichi Handa 0 siblings, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-16 8:51 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi 2010-08-16 10:16, Kenichi Handa skrev: > In article<jwvpqxmbz0i.fsf-monnier+emacs@gnu.org>, Stefan Monnier<monnier@iro.umontreal.ca> writes: > >>> And, first of all, from a user point of view, as these two >>> highlights a region exactly the same way (with the default >>> setting), >>> (1) S-C-n >>> (2) C-@ C-n >>> it's very confusing that they behave differently as to >>> selection. > >> I haven't seen any report indicating that users really get confused >> by that. > > As I don't like transient-mark-mode (both the default one > and the temporary one), I have not used it. But, for the > discussion of this thread, I tried it and found the current > behaviour is confusing. > >> But I'm not opposed to eliminating this confusion. I just >> really don't want to see it implemented in set_point_both, and I'm not >> excited to seeing it in command_loop_1 either. > > How about this? > > We own the primary selection when mark is activated by C-@ > in transient-mark-mode or C-@ C-@ not in > transient-mark-mode, and record somehow that selection is > owned that way (i.e. selection contents is a text in the > region). At that time the contents is null, but I think > it's not the problem. We do nothing special for all point > moving commands (except for highlighting the region). When > Emacs receives selection request, it returns the text in the > region if the selection is still owned as the above way. We > disown the selection when mark is deactivated. > I though we where moving away from special cases? Anyway, empty selection do matter. Consider this case: I select a lot of code in another application. I go to Emacs and set mark, then paste the code with mouse-2 and then M-x indent-region. With your scheme, mouse-2 would fail to paste, which would be a nasty surprise. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-16 8:51 ` Jan Djärv @ 2010-08-17 1:44 ` Kenichi Handa 2010-08-17 5:52 ` Jan Djärv 0 siblings, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2010-08-17 1:44 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 6774, angelo.graziosi In article <4C68FBF7.1080104@swipnet.se>, Jan Djärv <jan.h.d@swipnet.se> writes: > > We own the primary selection when mark is activated by C-@ > > in transient-mark-mode or C-@ C-@ not in > > transient-mark-mode, and record somehow that selection is > > owned that way (i.e. selection contents is a text in the > > region). At that time the contents is null, but I think > > it's not the problem. We do nothing special for all point > > moving commands (except for highlighting the region). When > > Emacs receives selection request, it returns the text in the > > region if the selection is still owned as the above way. We > > disown the selection when mark is deactivated. > > > I though we where moving away from special cases? Anyway, empty selection do > matter. Consider this case: > I select a lot of code in another application. > I go to Emacs and set mark, then paste the code with mouse-2 and then M-x > indent-region. > With your scheme, mouse-2 would fail to paste, which would be a nasty surprise. Surely this is not good. But which is a nastier surprise for new users, your case or my case below: >>> (1) S-C-n >>> (2) C-@ C-n >>> it's very confusing that they behave differently as to >>> selection. And, once we get used to that C-@ make Emacs own selection, we'll do your task in this order: "Set mark in Emacs, select a lot of code, paste it in Emacs, ...". Or, we can have something like this single command (don't take the code itself and the key-binding seriously). (defun mouse-yank-primary-and-select (click) (interactive "e") (mouse-set-point click) (push-mark) (mouse-yank-primary click)) (global-set-key [S-C-mouse-2] 'mouse-yank-primary-and-select) Though, please note that I myself still think it's better to modify command_loop_1 than chaning C-@ to own selection. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 1:44 ` Kenichi Handa @ 2010-08-17 5:52 ` Jan Djärv 2010-08-17 7:17 ` Eli Zaretskii 2010-08-17 11:43 ` Kenichi Handa 0 siblings, 2 replies; 74+ messages in thread From: Jan Djärv @ 2010-08-17 5:52 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi Kenichi Handa skrev 2010-08-17 03.44: > In article<4C68FBF7.1080104@swipnet.se>, Jan Djärv<jan.h.d@swipnet.se> writes: > >> I though we where moving away from special cases? Anyway, empty selection do >> matter. Consider this case: > >> I select a lot of code in another application. >> I go to Emacs and set mark, then paste the code with mouse-2 and then M-x >> indent-region. > >> With your scheme, mouse-2 would fail to paste, which would be a nasty surprise. > > Surely this is not good. But which is a nastier surprise > for new users, your case or my case below: > >>>> (1) S-C-n >>>> (2) C-@ C-n >>>> it's very confusing that they behave differently as to >>>> selection. They are both equally bad. I think we should add a hook to redisplay that gets called whenever selection is non-zero. Then that hook can do the right thing. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 5:52 ` Jan Djärv @ 2010-08-17 7:17 ` Eli Zaretskii 2010-08-17 8:24 ` Jan Djärv 2010-08-17 11:43 ` Kenichi Handa 1 sibling, 1 reply; 74+ messages in thread From: Eli Zaretskii @ 2010-08-17 7:17 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 6774, angelo.graziosi > Date: Tue, 17 Aug 2010 07:52:19 +0200 > From: Jan Djärv <jan.h.d@swipnet.se> > Cc: cyd@stupidchicken.com, 6774@debbugs.gnu.org, angelo.graziosi@alice.it > > I think we should add a hook to redisplay that gets called whenever > selection is non-zero. Then that hook can do the right thing. What do you mean by "selection is non-zero"? Does it mean that region should be highlighted during this redisplay cycle? Or does it mean something else? And when do you want the hook to be called? at the end of redisplay? at the beginning? in the middle? And why a hook? do we want to do in that hook anything except set some selection, like PRIMARY? If we only want to set a selection, we can do that directly. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 7:17 ` Eli Zaretskii @ 2010-08-17 8:24 ` Jan Djärv 2010-08-17 10:26 ` Eli Zaretskii 0 siblings, 1 reply; 74+ messages in thread From: Jan Djärv @ 2010-08-17 8:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cyd, 6774, angelo.graziosi 2010-08-17 09:17, Eli Zaretskii skrev: >> Date: Tue, 17 Aug 2010 07:52:19 +0200 >> From: Jan Djärv<jan.h.d@swipnet.se> >> Cc: cyd@stupidchicken.com, 6774@debbugs.gnu.org, angelo.graziosi@alice.it >> >> I think we should add a hook to redisplay that gets called whenever >> selection is non-zero. Then that hook can do the right thing. > > What do you mean by "selection is non-zero"? Does it mean that region > should be highlighted during this redisplay cycle? Or does it mean > something else? > > And when do you want the hook to be called? at the end of redisplay? > at the beginning? in the middle? It was said that only redisplay knows if the regions is non-empty and hightlighted. Called where it is appropriate, I haven't looked at it in detail yet. I guess at the end. The conditions are something like 1. The region is different from previous redisplay. 2. The region is not empty. 3. The region is hightlighted. > > And why a hook? do we want to do in that hook anything except set some > selection, like PRIMARY? If we only want to set a selection, we can > do that directly. Yes, but given all the variables that can influence what to do, I just thought it better to hand it off out of redisplay. Jan D. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 8:24 ` Jan Djärv @ 2010-08-17 10:26 ` Eli Zaretskii 0 siblings, 0 replies; 74+ messages in thread From: Eli Zaretskii @ 2010-08-17 10:26 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 6774, angelo.graziosi > Date: Tue, 17 Aug 2010 10:24:16 +0200 > From: Jan Djärv <jan.h.d@swipnet.se> > CC: handa@m17n.org, cyd@stupidchicken.com, 6774@debbugs.gnu.org, > angelo.graziosi@alice.it > > 1. The region is different from previous redisplay. > 2. The region is not empty. > 3. The region is hightlighted. 2 and 3 are trivial, but 1 is slightly harder: we don't currently track whether region beginning and end changed. > > And why a hook? do we want to do in that hook anything except set some > > selection, like PRIMARY? If we only want to set a selection, we can > > do that directly. > > Yes, but given all the variables that can influence what to do, I just thought > it better to hand it off out of redisplay. Accessing a Lisp variable from C is hardly a concern. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 5:52 ` Jan Djärv 2010-08-17 7:17 ` Eli Zaretskii @ 2010-08-17 11:43 ` Kenichi Handa 2010-08-17 12:14 ` Stefan Monnier 1 sibling, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2010-08-17 11:43 UTC (permalink / raw) To: Jan Djärv; +Cc: cyd, 6774, angelo.graziosi In article <4C6A2393.9030309@swipnet.se>, Jan Djärv <jan.h.d@swipnet.se> writes: > They are both equally bad. I think we should add a hook to redisplay that > gets called whenever selection is non-zero. Then that hook can do the right > thing. Why should redisplay concern selection? > It was said that only redisplay knows if the regions is non-empty and > hightlighted. ??? If redisplay knows that, command_loop_1 should know that too. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 11:43 ` Kenichi Handa @ 2010-08-17 12:14 ` Stefan Monnier 2010-08-17 12:57 ` Kenichi Handa 2010-08-17 20:59 ` David De La Harpe Golden 0 siblings, 2 replies; 74+ messages in thread From: Stefan Monnier @ 2010-08-17 12:14 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi >> They are both equally bad. I think we should add a hook to redisplay >> that gets called whenever selection is non-zero. Then that hook can >> do the right thing. > Why should redisplay concern selection? Because the behavior we want is that "if the user has seen the region highlighted, then it has been selected". >> It was said that only redisplay knows if the regions is non-empty and >> hightlighted. > ??? If redisplay knows that, command_loop_1 should know that too. redisplay can happen at times when command_loop_1 is not involved (sit-for, read-event, ...). Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 12:14 ` Stefan Monnier @ 2010-08-17 12:57 ` Kenichi Handa 2010-08-18 7:24 ` Stefan Monnier 2010-08-17 20:59 ` David De La Harpe Golden 1 sibling, 1 reply; 74+ messages in thread From: Kenichi Handa @ 2010-08-17 12:57 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi In article <jwvwrrp5tfn.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> They are both equally bad. I think we should add a hook to redisplay >>> that gets called whenever selection is non-zero. Then that hook can >>> do the right thing. > > Why should redisplay concern selection? > Because the behavior we want is that "if the user has seen the region > highlighted, then it has been selected". Ah, I see. You wrote: > I just really don't want to see it implemented in > set_point_both, and I'm not excited to seeing it in > command_loop_1 either. So, are you happy with seeing that in redisplay? If so, the call of x-set-selection in command_loop_1 for handling shift-selection should also go to redisplay. At least the current place is not good because it doesn't pay attention to point-adjustment done after "finilize:" label. When it is done in redisplay, that bug is automatically fixed. --- Kenichi Handa handa@m17n.org ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 12:57 ` Kenichi Handa @ 2010-08-18 7:24 ` Stefan Monnier 0 siblings, 0 replies; 74+ messages in thread From: Stefan Monnier @ 2010-08-18 7:24 UTC (permalink / raw) To: Kenichi Handa; +Cc: cyd, 6774, angelo.graziosi >> Because the behavior we want is that "if the user has seen the region >> highlighted, then it has been selected". > Ah, I see. You wrote: >> I just really don't want to see it implemented in >> set_point_both, and I'm not excited to seeing it in >> command_loop_1 either. > So, are you happy with seeing that in redisplay? Yes. And I'd be even much happier if it is in Elisp, via a hook that can be used for other things as well (well, the x-set-selection wouldn't be on the hook, so that the hook stays nil by default, but the redisplay code could call a (before|after)-redisplay Elisp function which can do that x-set-selection as well as run a hook). > If so, the call of x-set-selection in command_loop_1 for > handling shift-selection should also go to redisplay. Yes. > At least the current place is not good because it doesn't pay > attention to point-adjustment done after "finilize:" label. When it > is done in redisplay, that bug is automatically fixed. Exactly, Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 12:14 ` Stefan Monnier 2010-08-17 12:57 ` Kenichi Handa @ 2010-08-17 20:59 ` David De La Harpe Golden 2010-08-18 7:25 ` Stefan Monnier 1 sibling, 1 reply; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-17 20:59 UTC (permalink / raw) To: Stefan Monnier; +Cc: cyd, 6774, angelo.graziosi On 17/08/10 13:14, Stefan Monnier wrote: >>> They are both equally bad. I think we should add a hook to redisplay >>> that gets called whenever selection is non-zero. Then that hook can >>> do the right thing. >> Why should redisplay concern selection? > > Because the behavior we want is that "if the user has seen the region > highlighted, then it has been selected". I'd be wary doing it in redisplay might do it "too much" just like the old buffer-lazy implementation. Chong Yidong mentioned it on emacs-devel: > It's a convincing argument, leaving the issue of efficiency aside for > the moment. The rule, however, should be something like: >If you _change_ a selected region in Emacs (no matter how it was > selected), it's available as the primary. > That's because if you make a selected region in one application, and > then select some text in a second application, the second application > grabs primary. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-17 20:59 ` David De La Harpe Golden @ 2010-08-18 7:25 ` Stefan Monnier 0 siblings, 0 replies; 74+ messages in thread From: Stefan Monnier @ 2010-08-18 7:25 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: cyd, 6774, angelo.graziosi >> Because the behavior we want is that "if the user has seen the region >> highlighted, then it has been selected". > I'd be wary doing it in redisplay might do it "too much" just like the old > buffer-lazy implementation. Indeed, we need to be careful with it. IIUC the same risk exists with command_loop_1, but in any case, I agree that it can be delicate. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-07 19:50 ` Chong Yidong 2010-08-07 23:05 ` David De La Harpe Golden @ 2010-08-07 23:08 ` Angelo Graziosi 1 sibling, 0 replies; 74+ messages in thread From: Angelo Graziosi @ 2010-08-07 23:08 UTC (permalink / raw) To: Chong Yidong; +Cc: bug-gnu-emacs For me the rev. 101018 fixes the bug I flagged. Thanks, Angelo. Il 07/08/2010 21.50, Chong Yidong ha scritto: > David De La Harpe Golden<david@harpegolden.net> writes: > >> Well, select-active-regions was introduced (though not made default) >> rather before the ^-type shift-selection appeared AFAIK. From my >> perspective, it would be breaking something that was largely working >> as initially intended and (unlike with the general defaults change) >> not giving the option of having it work the way it did* anymore (well, >> apart from patching it in locally, I'm hardly incapable of doing >> that). > > I've checked in some changes that should (fingers crossed) fix the > "empty selection" problem. This also eliminates the use of > x-set-selection to buffer variables, as you suggested. Now, Emacs > copies strings out explicitly in the command loop and in > `deactivate-mark'. > > I added a new value to `select-active-regions', `lazy' (the default), > which means to set the selection only when used, as described in an > earlier email. Any other non-nil value gives something similar to the > original behavior of select-active-regions. ^ permalink raw reply [flat|nested] 74+ messages in thread
[parent not found: <mailman.23.1280783288.5118.bug-gnu-emacs@gnu.org>]
* bug#6774: Cut and paste with C-w/mouse-2 not working? [not found] ` <mailman.23.1280783288.5118.bug-gnu-emacs@gnu.org> @ 2010-08-03 14:34 ` Miles Bader 2010-08-03 15:15 ` David De La Harpe Golden 0 siblings, 1 reply; 74+ messages in thread From: Miles Bader @ 2010-08-03 14:34 UTC (permalink / raw) To: Chong Yidong; +Cc: 6774, Angelo Graziosi So while y'all are screwing around with this, is there a simple way I can get back the original behavior? [I mean: selecting with mouse in some window, then C-y in emacs, works, as does C-w in emacs followed by center-mouse to paste in a non-emacs window] -Miles -- Inhumanity, n. One of the signal and characteristic qualities of humanity. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-03 14:34 ` Miles Bader @ 2010-08-03 15:15 ` David De La Harpe Golden 2010-08-03 15:31 ` Miles Bader 0 siblings, 1 reply; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-03 15:15 UTC (permalink / raw) To: Miles Bader; +Cc: Chong Yidong, 6774, Angelo Graziosi On 03/08/10 15:34, Miles Bader wrote: > So while y'all are screwing around with this, is there a simple way I > can get back the original behavior? > Yes, four boolean customizations and a rebinding (or just five boolean customizations on my experimental branch) ** group killing: ;; stop emacs using the clipboard for C-w/M-w/C-y x-select-enable-clipboard => nil ;; make emacs use primary for C-w/M-w/C-y x-select-enable-primary => t ;; stop emacs sending both keyboard and mouse selections to primary ;; (and right now sometimes failing at it) select-active-regions => nil ** group mouse: ;; make emacs treat the end of a mouse drag selection as an M-w. mouse-drag-copy-region => t ** rebind: ;; make emacs treat mouse middle button as a C-y operation. ;; rather than a primary-insertion-only operation. (global-set-key [mouse-2] 'mouse-yank-at-click) N.B. On the "selx" experimental branch, don't rebind mouse-2, do instead: mouse-yank-selection-only => nil [IMO such a boolean customisation is neater than requiring a rebind to revert for reasons outlined on emacs-devel last week] ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-03 15:15 ` David De La Harpe Golden @ 2010-08-03 15:31 ` Miles Bader 2010-08-03 15:45 ` David De La Harpe Golden 0 siblings, 1 reply; 74+ messages in thread From: Miles Bader @ 2010-08-03 15:31 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: Chong Yidong, 6774, Angelo Graziosi hmm... it sounds like that won't actually restore the previous behavior: previously emacs transparently worked with _both_ the selection and the clipboard -- e.g., C-y would insert either the primary selection or the clipboard (or from the emacs kill-ring), whichever was more recent. that's the behavior I want. [The new behavior is "more consistent", but also much less convenient.] -miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-03 15:31 ` Miles Bader @ 2010-08-03 15:45 ` David De La Harpe Golden 2010-08-03 16:02 ` Miles Bader 0 siblings, 1 reply; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-03 15:45 UTC (permalink / raw) To: Miles Bader; +Cc: Chong Yidong, 6774, Angelo Graziosi On 03/08/10 16:31, Miles Bader wrote: > hmm... it sounds like that won't actually restore the previous behavior: > previously emacs transparently worked with _both_ the selection and > the clipboard -- e.g., C-y would insert either the primary selection > or the clipboard (or from the emacs kill-ring), whichever was more > recent. > > that's the behavior I want. > Um, you're thinking of certain of your own customisations that you yourself mentioned a few days back on emacs-devel. The old defaults didn't do that either. So you need to (notionally) revert to the old defaults as given, then reapply your customisations, which shouldn't be hard in this case: I believe the difference is kust that you operated with both x-select-enable-primary and x-select-enable-clipboard turned on at once, which causes x-cut-buffer-or-selection-value to try to be "clever". (Note I wanted the settings all boolean customisations was because it would become possible to use an "old x11 defaults" customization theme with them - bindings aren't included in customization themes). ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-03 15:45 ` David De La Harpe Golden @ 2010-08-03 16:02 ` Miles Bader 2010-08-04 18:02 ` Stefan Monnier 0 siblings, 1 reply; 74+ messages in thread From: Miles Bader @ 2010-08-03 16:02 UTC (permalink / raw) To: David De La Harpe Golden; +Cc: Chong Yidong, 6774, Angelo Graziosi Ok, I just did (setq x-select-enable-primary t) and now things work much better. Thanks, -Miles -- Do not taunt Happy Fun Ball. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-03 16:02 ` Miles Bader @ 2010-08-04 18:02 ` Stefan Monnier 2010-08-04 18:25 ` Drew Adams 0 siblings, 1 reply; 74+ messages in thread From: Stefan Monnier @ 2010-08-04 18:02 UTC (permalink / raw) To: Miles Bader; +Cc: Chong Yidong, 6774, Angelo Graziosi > Ok, I just did (setq x-select-enable-primary t) and now things work > much better. It's important to include such instructions in etc/NEWS. The current text is "too close to the code", i.e. it documents the code changes more than the resulting behavior changes. I also noticed another change wrt selection: double-click and then drag only does "word-chunked selection" on the initial double-click but not on the susequent drag. Stefan ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-04 18:02 ` Stefan Monnier @ 2010-08-04 18:25 ` Drew Adams 2010-08-04 21:10 ` David De La Harpe Golden 0 siblings, 1 reply; 74+ messages in thread From: Drew Adams @ 2010-08-04 18:25 UTC (permalink / raw) To: 'Stefan Monnier', 'Miles Bader' Cc: 'Chong Yidong', 6774, 'Angelo Graziosi' > > Ok, I just did (setq x-select-enable-primary t) and now things work > > much better. > > It's important to include such instructions in etc/NEWS. > The current text is "too close to the code", i.e. it > documents the code changes more than the resulting behavior changes. > > I also noticed another change wrt selection: double-click and > then drag only does "word-chunked selection" on the initial > double-click but not on the susequent drag. Why change the default behavior (esp. with no emacs-devel proposal and discussion)? Why not implement your changes ("improvements") as a new, optional alternative behavior? And then document _that_ in NEWS etc. IOW document whatever options you need to change to get the new behavior, instead of documenting what you need to do to get back the old behavior. If enough people like it and use it over time then we can consider changing the default behavior to it. That's the normal way to proceed for any significant behavior change. This seems to be a fundamental change to Emacs selection etc. It merits discussion, experimentation, and time trial. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-04 18:25 ` Drew Adams @ 2010-08-04 21:10 ` David De La Harpe Golden 2010-08-04 21:36 ` Drew Adams 0 siblings, 1 reply; 74+ messages in thread From: David De La Harpe Golden @ 2010-08-04 21:10 UTC (permalink / raw) To: Drew Adams Cc: 'Chong Yidong', 'Miles Bader', 6774, 'Angelo Graziosi' On 04/08/10 19:25, Drew Adams wrote: > Why not implement your changes ("improvements") as a new, optional alternative > behavior? While changing the defaults is certainly a new thing*, I'm sorry, but if you think the _option_ for the behaviour itself is new, then you have just been completely tuning it (and sometimes heated threads around it) out for some years now. Maybe you thought it didn't matter to your platform or something (which would be a perhaps understandable assumption, though a naive one given the way the w32 and ns ports work). select-active-regions and x-select-enable-primary were first added to emacs in late 2007 (rev 83308). They're in NEWS.23 mouse-drag-copy-region was apparently added in 2004 (rev 55223)), it's in NEWS.22 Using them to produce the desired behaviour has also been documented on EmacsWiki/CopyAndPaste since early '08 too, not that that's official documentation, just illustrating this is not new (people choosing to switch it on are rather less likely to do things that break it, though). ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-04 21:10 ` David De La Harpe Golden @ 2010-08-04 21:36 ` Drew Adams 2010-08-05 0:17 ` Chong Yidong 0 siblings, 1 reply; 74+ messages in thread From: Drew Adams @ 2010-08-04 21:36 UTC (permalink / raw) To: 'David De La Harpe Golden' Cc: 'Chong Yidong', 'Miles Bader', 6774, 'Angelo Graziosi' > > Why not implement your changes ("improvements") as a new, > > optional alternative behavior? > > While changing the defaults is certainly a new thing*, I'm > sorry, but if you think the _option_ for the behaviour itself > is new, then you have just been completely tuning it (and > sometimes heated threads around it) out for some years now. > Maybe you thought it didn't matter to your > platform or something (which would be a perhaps understandable > assumption, though a naive one given the way the w32 and ns > ports work). > > select-active-regions and x-select-enable-primary were first > added to emacs in late 2007 (rev 83308). They're in NEWS.23 > > mouse-drag-copy-region was apparently added in 2004 (rev > 55223)), it's in NEWS.22 > > Using them to produce the desired behaviour has also been > documented on EmacsWiki/CopyAndPaste since early '08 too, not > that that's official documentation, just illustrating this is > not new (people choosing to switch it on are rather less likely > to do things that break it, though). I admit that I do not understand well all that you wrote or why you wrote it. You seem to be trying to show that the behavior you promote is not new, that it has been available optionally for some time. OK. I _thought_ that you were just fixing some real _bugs_. (And that those fixes were inappropriate for Windows according to Eli, so they would be reverted.) This is a _bug_ thread. Likewise for the other bugs filed wrt the recent selection changes. If you were _not_ adding any new behavior, because as you say now the alternative behaviors in question have long been available optionally, then are you _only_ trying to change the default behavior to be a previously optional one? If so then I have the same objection. A bug thread is not the place to monkey with the default behavior of Emacs. If you want to propose that the default behavior be changed to ABCDE, then propose that clearly on emacs-devel. Include a complete description of all of the behavior changes (consequences) involved, so people can understand clearly what you're proposing and discuss it. If the behavior that you want to propose as the new default has been around for a while and is familiar to people on emacs-devel, then so much the better for you. Those who are familiar with it will need less time experimenting with it and thinking about it in order to decide what they think about it becoming the default behavior. But just because someone might be aware of the existence of an optional behavior does not mean that they have tried it much or thought about it much. In any case, if you want to change the default behavior, then please make a clear proposal on emacs-devel. Thx. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-04 21:36 ` Drew Adams @ 2010-08-05 0:17 ` Chong Yidong 2010-08-05 0:24 ` Drew Adams 0 siblings, 1 reply; 74+ messages in thread From: Chong Yidong @ 2010-08-05 0:17 UTC (permalink / raw) To: Drew Adams; +Cc: 6774, 'Angelo Graziosi', 'Miles Bader' "Drew Adams" <drew.adams@oracle.com> writes: > I admit that I do not understand well all that you wrote or why you > wrote it... In any case, if you want to change the default behavior, > then please make a clear proposal on emacs-devel. Please stop belaboring the point. The reason for the changes has been explained to you, more than once. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-05 0:17 ` Chong Yidong @ 2010-08-05 0:24 ` Drew Adams 2010-08-05 0:33 ` Chong Yidong 0 siblings, 1 reply; 74+ messages in thread From: Drew Adams @ 2010-08-05 0:24 UTC (permalink / raw) To: 'Chong Yidong' Cc: 6774, 'Angelo Graziosi', 'Miles Bader' > > I admit that I do not understand well all that you wrote or why you > > wrote it... In any case, if you want to change the default > > behavior, then please make a clear proposal on emacs-devel. > > Please stop belaboring the point. The reason for the changes has been > explained to you, more than once. I'm not concerned about the reason for the changes on Posix (although I am a bit curious). And AFAIK _no_ reason has been given for changing the default behavior on Windows. The only explanation I saw for the changes I've seen on Windows was that these were temporary bugs introduced accidentally and that would soon be corrected. Eli too asked that the previous default behavior be restored on Windows, IIUC. I thought that was going to happen, and I still hope that it will. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-05 0:24 ` Drew Adams @ 2010-08-05 0:33 ` Chong Yidong 2010-08-05 0:40 ` Drew Adams 0 siblings, 1 reply; 74+ messages in thread From: Chong Yidong @ 2010-08-05 0:33 UTC (permalink / raw) To: Drew Adams; +Cc: 6774, 'Angelo Graziosi', 'Miles Bader' "Drew Adams" <drew.adams@oracle.com> writes: > I'm not concerned about the reason for the changes on Posix (although > I am a bit curious). And AFAIK _no_ reason has been given for > changing the default behavior on Windows. > > The only explanation I saw for the changes I've seen on Windows was > that these were temporary bugs introduced accidentally and that would > soon be corrected. Eli too asked that the previous default behavior > be restored on Windows, IIUC. I thought that was going to happen, and > I still hope that it will. The behavior on Windows will be fixed; in the meantime, there is no point adding hacks into the code to back out the changes just for Windows, which would have to be taken out later. The development sources are for development. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-05 0:33 ` Chong Yidong @ 2010-08-05 0:40 ` Drew Adams 0 siblings, 0 replies; 74+ messages in thread From: Drew Adams @ 2010-08-05 0:40 UTC (permalink / raw) To: 'Chong Yidong' Cc: 6774, 'Angelo Graziosi', 'Miles Bader' > > I'm not concerned about the reason for the changes on Posix > > (although I am a bit curious). And AFAIK _no_ reason has > > been given for changing the default behavior on Windows. > > > > The only explanation I saw for the changes I've seen on Windows was > > that these were temporary bugs introduced accidentally and > > that would soon be corrected. Eli too asked that the previous > > default behavior be restored on Windows, IIUC. I thought that > > was going to happen, and I still hope that it will. > > The behavior on Windows will be fixed; in the meantime, there is no > point adding hacks into the code to back out the changes just for > Windows, which would have to be taken out later. The development > sources are for development. That all sounds good to me. Thanks. ^ permalink raw reply [flat|nested] 74+ messages in thread
* bug#6774: Cut and paste with C-w/mouse-2 not working? 2010-08-01 22:04 bug#6774: Cut and paste with C-w/mouse-2 not working? Angelo Graziosi 2010-08-02 4:12 ` David De La Harpe Golden @ 2010-08-02 13:33 ` Angelo Graziosi 1 sibling, 0 replies; 74+ messages in thread From: Angelo Graziosi @ 2010-08-02 13:33 UTC (permalink / raw) To: bug-gnu-emacs Il 02/08/2010 6.12, David De La Harpe Golden ha scritto: > On 01/08/10 23:04, Angelo Graziosi wrote: >> It seems that with recent trunk sources (also with the last, >> rev.100958), cutting with C-w and then pasting with mouse-2 does not >> work. To reproduce: >> >> 1. emacs -Q & >> >> 2. In the 'scratch' buffer double click on some text, 'buffer', for >> example. >> >> 3. Now cut it: C-w >> >> 4. Go to the bottom of the buffer and paste with mouse-2: empty! >> >> I can paste only with C-y. If at step 3. I use M-w (Copy), then pasting >> with mouse-2 works. >> > > Yes, there's a problem here - I guess emacs is keeping primary bound to > a span that's become zero-length. Again. > > N.B. your case ideally would work in emacs much like in KDE - but emacs > still has teething problems and sometimes manages to make primary a > zero-length string.[this is already "fixed" in the horrible selx branch] > >> For example, on Kubuntu, one can cut with C-x and the paste with mouse-2 >> (Konqueror, Kate,...) > > Not exactly - not quite what's really going on. There's a spec for how > this is supposed to work, and KDE follows it.* > > When you have _selected_ the text in KDE before hitting C-x, it is made > available as the "primary" x11 selection (referred to as "the selection" > in klipper*) > > C-x makes the text available as the CLIPBOARD x11 selection while > removing it from the body of the document. (and it's still available on > PRIMARY too, where emacs fails). > > mouse-2 inserts what's in PRIMARY in KDE. > > So in KDE, try selecting more/different text, _without_ hitting C-x or > C-c. This will change only PRIMARY. > > Hitting mouse-2 again will insert the _new_ PRIMARY. > > Then hitting C-v will insert the old CLIPBOARD. To update the clipboard > you always have to C-x or C-c. > > (* though the situation is further complicated by klipper, the KDE > clipboard daemon, which can be configured to do various strange things > in this area, I mean KDE's out-of-box defaults). I do not doubt that, internally, things are different. Anyway, from the 'End User' point of view, C-w/mouse-2 (in Emacs) should behave in the same way of C-X/mouse-2 (in other X applications like Konqueror, Kate etc.) BTW, if I add the step: 1.1 I choose: Options | C-x/.../C-v Cut and Paste (CUA) then C-x/mouse-2, in Emacs still does not work! So, at the moment, Emacs, in this regard (Copy/Paste), from the 'End User' point of view, behaves differently from other X applications. Ciao, Angelo. ^ permalink raw reply [flat|nested] 74+ messages in thread
end of thread, other threads:[~2010-08-18 7:25 UTC | newest] Thread overview: 74+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-08-01 22:04 bug#6774: Cut and paste with C-w/mouse-2 not working? Angelo Graziosi 2010-08-02 4:12 ` David De La Harpe Golden [not found] ` <4C56C8F0.2010104@alice.it> 2010-08-02 14:52 ` David De La Harpe Golden 2010-08-02 19:41 ` Chong Yidong 2010-08-02 20:30 ` David De La Harpe Golden 2010-08-02 20:33 ` David De La Harpe Golden 2010-08-02 20:53 ` David De La Harpe Golden 2010-08-02 20:59 ` Chong Yidong 2010-08-02 21:35 ` David De La Harpe Golden 2010-08-02 22:26 ` David De La Harpe Golden 2010-08-05 2:20 ` Chong Yidong 2010-08-05 23:50 ` David De La Harpe Golden 2010-08-06 7:43 ` Eli Zaretskii 2010-08-06 9:13 ` Stefan Monnier 2010-08-06 10:50 ` Eli Zaretskii 2010-08-06 12:21 ` Kenichi Handa 2010-08-06 13:17 ` Jan Djärv 2010-08-06 20:23 ` David De La Harpe Golden 2010-08-06 20:17 ` David De La Harpe Golden 2010-08-06 15:28 ` Chong Yidong 2010-08-06 21:05 ` David De La Harpe Golden 2010-08-07 19:50 ` Chong Yidong 2010-08-07 23:05 ` David De La Harpe Golden 2010-08-09 2:55 ` Chong Yidong 2010-08-09 11:43 ` Stefan Monnier 2010-08-09 17:19 ` Jan Djärv 2010-08-10 7:29 ` Stefan Monnier 2010-08-10 14:01 ` Jan Djärv 2010-08-10 15:54 ` Stefan Monnier 2010-08-10 17:59 ` Jan Djärv 2010-08-11 7:46 ` Stefan Monnier 2010-08-11 16:06 ` Jan Djärv 2010-08-11 20:17 ` Stefan Monnier 2010-08-11 21:26 ` Jan Djärv 2010-08-11 21:32 ` Stefan Monnier 2010-08-12 3:54 ` Kenichi Handa 2010-08-12 7:43 ` Jan Djärv 2010-08-12 7:51 ` Kenichi Handa 2010-08-12 8:29 ` Stefan Monnier 2010-08-12 12:14 ` Kenichi Handa 2010-08-12 16:09 ` Stefan Monnier 2010-08-12 17:11 ` Jan Djärv 2010-08-13 10:38 ` Stefan Monnier 2010-08-13 11:29 ` Eli Zaretskii 2010-08-13 6:18 ` Kenichi Handa 2010-08-13 10:40 ` Stefan Monnier 2010-08-16 8:16 ` Kenichi Handa 2010-08-16 8:51 ` Jan Djärv 2010-08-17 1:44 ` Kenichi Handa 2010-08-17 5:52 ` Jan Djärv 2010-08-17 7:17 ` Eli Zaretskii 2010-08-17 8:24 ` Jan Djärv 2010-08-17 10:26 ` Eli Zaretskii 2010-08-17 11:43 ` Kenichi Handa 2010-08-17 12:14 ` Stefan Monnier 2010-08-17 12:57 ` Kenichi Handa 2010-08-18 7:24 ` Stefan Monnier 2010-08-17 20:59 ` David De La Harpe Golden 2010-08-18 7:25 ` Stefan Monnier 2010-08-07 23:08 ` Angelo Graziosi [not found] ` <mailman.23.1280783288.5118.bug-gnu-emacs@gnu.org> 2010-08-03 14:34 ` Miles Bader 2010-08-03 15:15 ` David De La Harpe Golden 2010-08-03 15:31 ` Miles Bader 2010-08-03 15:45 ` David De La Harpe Golden 2010-08-03 16:02 ` Miles Bader 2010-08-04 18:02 ` Stefan Monnier 2010-08-04 18:25 ` Drew Adams 2010-08-04 21:10 ` David De La Harpe Golden 2010-08-04 21:36 ` Drew Adams 2010-08-05 0:17 ` Chong Yidong 2010-08-05 0:24 ` Drew Adams 2010-08-05 0:33 ` Chong Yidong 2010-08-05 0:40 ` Drew Adams 2010-08-02 13:33 ` Angelo Graziosi
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).