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

[Kenichi Handa <handa@m17n.org>]

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