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

Previous Next

Full log

View this message in rfc822 format

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

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

Previous Next

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