bug#6774: Cut and paste with C-w/mouse-2 not working?

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Angelo Graziosi]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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).

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Angelo Graziosi]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Chong Yidong]

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?

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Chong Yidong]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

...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...

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Miles Bader]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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]

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Miles Bader]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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).

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Miles Bader]

Ok, I just did (setq x-select-enable-primary t) and now things work much better.

Thanks,

-Miles

-- 
Do not taunt Happy Fun Ball.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Drew Adams]

> > 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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).

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Drew Adams]

> > 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Chong Yidong]

"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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Drew Adams]

> > 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Chong Yidong]

"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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Drew Adams]

> > 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Chong Yidong]

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).

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Eli Zaretskii]

> 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Eli Zaretskii]

> 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Chong Yidong]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Chong Yidong]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Angelo Graziosi]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Chong Yidong]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>>> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>>>> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Eli Zaretskii]

> 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Eli Zaretskii]

> 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Jan Djärv]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Eli Zaretskii]

> 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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Kenichi Handa]

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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[David De La Harpe Golden]

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.

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>> 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

bug#6774: Cut and paste with C-w/mouse-2 not working?

[Stefan Monnier]

>> 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