Suggestion for mouse-based cut/copy/yank

Suggestion for mouse-based cut/copy/yank

[David Kastrup]

Hi,

I often mark material with the mouse using triple clicks (whole
lines).  The double click right on the last line for deletion works
fine and intuitively and makes it easy to deal with whole lines.

However, when yanking with a click, material is yanked right at point
rather than at the start of line.

That is a nuisance.  So I think it would be nice to store the
"granularity" of a mouse click/mark away and use it to move to begin
of word/line before yanking.  Maybe the best way would be to use a
yank-handler property on the string in question.  It is likely that it
is ok to have this work with keyboard-controlled yanks from
mouse-collected kill material, too.

For what it is worth, vi has "p" and "P" commands for inserting
material after and before the cursor (which perversely is not between,
but _on_ characters and lines conceptually), and those also heed the
"line-basedness" of the commands putting the stuff in the kill buffer.

It is actually quite convenient.

-- 
David Kastrup

RE: Suggestion for mouse-based cut/copy/yank

[Drew Adams]

> I often mark material with the mouse using triple clicks (whole
> lines).  The double click right on the last line for deletion works
> fine and intuitively and makes it easy to deal with whole lines.
>
> However, when yanking with a click, material is yanked right at point
> rather than at the start of line.
>
> That is a nuisance.  So I think it would be nice to store the
> "granularity" of a mouse click/mark away and use it to move to begin
> of word/line before yanking.  Maybe the best way would be to use a
> yank-handler property on the string in question.

I disagree. Yank by mouse should occur at the pointer position. You should
always be able to point and shoot. Direct access to any (visible) position
is what a pointer device is all about.

It is not always the case when you insert one or more whole lines that you
want to insert the text at bol. You need to be able to specify the exact
location using the mouse, and that location should not be limited by either
what it is that was selected (e.g. whole lines) or how it was selected (e.g.
triple clicks).

Although I disagree that your suggestion is a good idea for either of these
cases, it might help for discussion to separate whole-line selections into
those that are selected in the manner you described (triple-click), and
those that are selected in some other way. Your suggestion makes more sense
for the former situation than for the latter (though I disagree with it in
both cases).

You might propose that a `mouse-2' triple-click would yank at bol (and a
double-click would yank at beginning of word), but I still think that this
kind of thing is a bad idea.

> It is likely that it
> is ok to have this work with keyboard-controlled yanks from
> mouse-collected kill material, too.

If you use the keyboard, then `C-a C-y' does what you want, no? Am I missing
something, or would this just save you a `C-a'?

Re: Suggestion for mouse-based cut/copy/yank

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

>> I often mark material with the mouse using triple clicks (whole
>> lines).  The double click right on the last line for deletion works
>> fine and intuitively and makes it easy to deal with whole lines.
>>
>> However, when yanking with a click, material is yanked right at point
>> rather than at the start of line.
>>
>> That is a nuisance.  So I think it would be nice to store the
>> "granularity" of a mouse click/mark away and use it to move to begin
>> of word/line before yanking.  Maybe the best way would be to use a
>> yank-handler property on the string in question.
>
> I disagree. Yank by mouse should occur at the pointer position. You
> should always be able to point and shoot.

So you are for disabling double and triple clicks for marking since
the don't require exact point and shoot?

> Direct access to any (visible) position is what a pointer device is
> all about.

Why do we then have triple clicks for marking?

> It is not always the case when you insert one or more whole lines
> that you want to insert the text at bol.

Then you could easily refrain from triple-clicks in order to mark your
text.

> You need to be able to specify the exact location using the mouse,
> and that location should not be limited by either what it is that
> was selected (e.g. whole lines) or how it was selected (e.g.  triple
> clicks).

We violate that rule already for right mouse clicks: if you have
marked a region with triple clicks, you can extend the region by
clicking once anywhere with the right mouse key.  According to your
logic, the right mouse key should only mark a partial line, then.

> You might propose that a `mouse-2' triple-click would yank at bol
> (and a double-click would yank at beginning of word), but I still
> think that this kind of thing is a bad idea.

Double click action must be an extension of single-click, since the
single click gets executed anyway.

>> It is likely that it is ok to have this work with
>> keyboard-controlled yanks from mouse-collected kill material, too.
>
> If you use the keyboard, then `C-a C-y' does what you want, no? Am I
> missing something, or would this just save you a `C-a'?

Correct, which is why this is less interesting for keyboard yanks.  So
one could well restrict this functionality to mouse-yank-at-click.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggestion for mouse-based cut/copy/yank

[Richard Stallman]

    However, when yanking with a click, material is yanked right at point
    rather than at the start of line.

    That is a nuisance.  So I think it would be nice to store the
    "granularity" of a mouse click/mark away and use it to move to begin
    of word/line before yanking.

I think that would be a bug.  You can change this yourself, but I don't
think we should change Emacs' normal behavior.

Re: Suggestion for mouse-based cut/copy/yank

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     However, when yanking with a click, material is yanked right at point
>     rather than at the start of line.
>
>     That is a nuisance.  So I think it would be nice to store the
>     "granularity" of a mouse click/mark away and use it to move to begin
>     of word/line before yanking.
>
> I think that would be a bug.

Intentional behavior is never a bug.  It may at worst be stupid or
annoying.

> You can change this yourself, but I don't think we should change
> Emacs' normal behavior.

So it would be ok to provide this as an optional feature?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggestion for mouse-based cut/copy/yank

[Richard Stallman]

    > You can change this yourself, but I don't think we should change
    > Emacs' normal behavior.

    So it would be ok to provide this as an optional feature?

I don't think it is useful enough to provide even as an option.
However, I would change my mind about that if it gets support
from several others.

Re: Suggestion for mouse-based cut/copy/yank

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > You can change this yourself, but I don't think we should change
>     > Emacs' normal behavior.
>
>     So it would be ok to provide this as an optional feature?
>
> I don't think it is useful enough to provide even as an option.
> However, I would change my mind about that if it gets support
> from several others.

At least in the immediate workflow of triple-click line, right-click
some other line (the highlighted area is line-based on both ends),
middle click a destination line, it would make sense to act
line-based: if the right mouse button is line-aligned for convenience,
doing the same with middle seems appropriate.

Whether to actually record something in the killring in that situation
rather than take the clue from the current situation like mouse-3
does, is the question.  Probably I'll first implement this based on
the mouse-3 code.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Suggestion for mouse-based cut/copy/yank

[Stefan Monnier]

>> You can change this yourself, but I don't think we should change
>> Emacs' normal behavior.

>     So it would be ok to provide this as an optional feature?

> I don't think it is useful enough to provide even as an option.
> However, I would change my mind about that if it gets support
> from several others.

I never kill by line, so I don't have a strong opinion, but I think the
proposed behavior makes a lot of sense.


        Stefan