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

Previous Next

Full log

Message #178 received at 6774 <at> debbugs.gnu.org (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: cyd <at> stupidchicken.com, jan.h.d <at> swipnet.se, 6774 <at> debbugs.gnu.org,
	angelo.graziosi <at> alice.it
Subject: Re: bug#6774: Cut and paste with C-w/mouse-2 not working?
Date: Fri, 13 Aug 2010 15:18:03 +0900

In article <jwvvd7fbyv0.fsf-monnier+emacs <at> gnu.org>, Stefan Monnier <monnier <at> 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 <at> m17n.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.