bug#9810: cw in viper mode clobbers clipboard

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

As the title says, in viper command mode typing cw (ie change word)
causes the emacs clipboard (not sure the proper name for it, but the
thing I expect a middle mouse button to paste into the buffer) to get
clobbered. This is a regression over all previous versions (actually I
remember this bug occurring a long time ago and getting fixed so
something must have broken it again). To replicate:

emacs -Q
M-x viper
i (ie, go into insert mode)
asdf hjkl (type a few words)
<escape> (ie, go into command mode)
click on the 'a' (or move there any way you want)
double click to put 'asdf' into emacs clipboard (ie X11 clipboard,
primary, whatever)
click on the 'h' (or move there any way you want)
cw (ie viper command to change word)j
<middle mouse click> (to paste the clipboard, or yank or whatever
emacs calls it :-)
hjkl is pasted in

But 'asdf' should have been pasted in. This also occurs with other
commands like 'ct', etc. This is very annoying and I cannot imagine
using the new version if this is not fixed.

Thanks much,
Bob

In GNU Emacs 24.0.90.1 (x86_64-apple-darwin10.8.0, X toolkit, Xaw3d scroll bars)
 of 2011-10-04 on where.i.am
Windowing system distributor `The X.Org Foundation', version 11.0.11003000
configured using `configure
'--prefix=/Users/name/local-emacs-24.0.90' '--with-x-toolkit=athena''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x v i p e r - o <backspace> <backspace> <return>
i a s d f SPC h j k l <escape> 0 <down-mouse-1> <mouse-1>
<double-down-mouse-1> <double-mouse-1> <down-mouse-1>
<mouse-1> c w <down-mouse-2> <mouse-2> <escape> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <menu-bar>
<help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Loading viper...
Loading /Users/name/.viper...done
Loading viper...done

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr message format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mailabbrev mail-utils gmm-utils mailheader
emacsbug tabify viper viper-ex viper-macs viper-mous viper-cmd
viper-keym ring viper-util viper-init advice help-fns advice-preload
time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image fringe lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty emacs)

bug#9810: cw in viper mode clobbers clipboard

[Lennart Borgman]

On Thu, Oct 20, 2011 at 18:18, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
> As the title says, in viper command mode typing cw (ie change word)
> causes the emacs clipboard (not sure the proper name for it, but the
> thing I expect a middle mouse button to paste into the buffer) to get
> clobbered. This is a regression over all previous versions (actually I
> remember this bug occurring a long time ago and getting fixed so
> something must have broken it again). To replicate:
>
> emacs -Q
> M-x viper
> i (ie, go into insert mode)
> asdf hjkl (type a few words)
> <escape> (ie, go into command mode)
> click on the 'a' (or move there any way you want)
> double click to put 'asdf' into emacs clipboard (ie X11 clipboard,
> primary, whatever)
> click on the 'h' (or move there any way you want)
> cw (ie viper command to change word)j
> <middle mouse click> (to paste the clipboard, or yank or whatever
> emacs calls it :-)
> hjkl is pasted in
>
> But 'asdf' should have been pasted in. This also occurs with other
> commands like 'ct', etc. This is very annoying and I cannot imagine
> using the new version if this is not fixed.

I think the current behavior is the correct one. Why do you think it
is in error?

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 10:25 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 18:18, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
>> But 'asdf' should have been pasted in. This also occurs with other
>> commands like 'ct', etc. This is very annoying and I cannot imagine
>> using the new version if this is not fixed.
>
> I think the current behavior is the correct one. Why do you think it
> is in error?
>

Because the just typing 'cw' should not cause either clipboard or
primary to be altered. The word is highlighted but that should be it,
it should not go into primary (or clipboard or any other selection).
The way it is now the common (for me) work-flow (put something into
primary, go somewhere else, use cw then <middel mouse> to change that
word) described above does not work anymore. The changes to primary
and clipboard described in NEWS have nothing to do with this (or
should not).

Bob

bug#9810: cw in viper mode clobbers clipboard

[Lennart Borgman]

On Thu, Oct 20, 2011 at 18:44, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 10:25 AM, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Thu, Oct 20, 2011 at 18:18, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
>>> But 'asdf' should have been pasted in. This also occurs with other
>>> commands like 'ct', etc. This is very annoying and I cannot imagine
>>> using the new version if this is not fixed.
>>
>> I think the current behavior is the correct one. Why do you think it
>> is in error?
>>
>
> Because the just typing 'cw' should not cause either clipboard or
> primary to be altered.

I do expect cw to cause the clipboard to change since something from
the buffer is erased. I think most people would expect that too.

However I do not understand the reason for why think differently.
(Except that you find it inconvenient, but that is a different thing.)

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 10:48 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 18:44, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
>> On Thu, Oct 20, 2011 at 10:25 AM, Lennart Borgman
>> <lennart.borgman@gmail.com> wrote:
>>> On Thu, Oct 20, 2011 at 18:18, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
>>>> But 'asdf' should have been pasted in. This also occurs with other
>>>> commands like 'ct', etc. This is very annoying and I cannot imagine
>>>> using the new version if this is not fixed.
>>>
>>> I think the current behavior is the correct one. Why do you think it
>>> is in error?
>>>
>>
>> Because the just typing 'cw' should not cause either clipboard or
>> primary to be altered.
>
> I do expect cw to cause the clipboard to change since something from
> the buffer is erased. I think most people would expect that too.
>
> However I do not understand the reason for why think differently.
> (Except that you find it inconvenient, but that is a different thing.)
>

Right after you type 'cw' nothing in the buffer is erased. The word is
hi-lighted but that is it. So it should not change any selection at
that point. Try what I describe in 23.3. You will see it is a
regression.

Bob

bug#9810: cw in viper mode clobbers clipboard

[Stefan Monnier]

> Right after you type 'cw' nothing in the buffer is erased. The word is
> hi-lighted but that is it. So it should not change any selection at

That's what is supposed to happen now that select-active-regions
defaults to t.


        Stefan

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 12:46 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Right after you type 'cw' nothing in the buffer is erased. The word is
>> hi-lighted but that is it. So it should not change any selection at
>
> That's what is supposed to happen now that select-active-regions
> defaults to t.

I like the behavior of select-active-regions when it is set to t.
However, I do not consider the selected word when one does 'cw' an
active region (in the usual emacs sense). It is a vi construct
independent of emacs active regions and so it need not honor the
select-active-regions setting.

I am curious what other long-time viper mode users think about this
change in behavior (note that I no idea if any of the responders to
this bug report are viper users or not).

Bob

bug#9810: cw in viper mode clobbers clipboard

[Lennart Borgman]

On Thu, Oct 20, 2011 at 22:28, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
>
> I am curious what other long-time viper mode users think about this
> change in behavior (note that I no idea if any of the responders to
> this bug report are viper users or not).

I am always using viper (and have contributed some small bits to it).

bug#9810: cw in viper mode clobbers clipboard

[Stefan Monnier]

> I like the behavior of select-active-regions when it is set to t.

[ FWIW, I don't. ;-)  ]

> However, I do not consider the selected word when one does 'cw' an
> active region (in the usual emacs sense).

I see.  But technically, it is (i.e. that's how Viper implements it).

> It is a vi construct independent of Emacs active regions and so it
> need not honor the select-active-regions setting.

Of course, Viper could be changed to use some other mechanism, but it is
convenient to use the region for that.  I'm not sure how/if we could let
Viper tell Emacs to ignore select-active-regions for this case.

> I am curious what other long-time viper mode users think about this
> change in behavior (note that I no idea if any of the responders to
> this bug report are viper users or not).

I don't use Viper myself, so I'll let others handle this part.


        Stefan

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 3:31 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I like the behavior of select-active-regions when it is set to t.
>
> [ FWIW, I don't. ;-)  ]

I figured I would set select-active-regions to nil since I never
changed in in earlier versions, but there is an difference to the old
behavior. In 23.3 (and before):

-when one used the mouse to select a region the primary selection was set

-when one set the mark and used movement commands to make an active
region, the primary selection was not set

In 24.0., if select-active-regions is t, both of these actions set the
primary selection. But if select-active-regions is nil, neither of
these actions set the primary selection.

Do you know how I would get the behavior back what it was in 23.3?

Thanks,
Bob

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 4:12 PM, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 3:31 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>> I like the behavior of select-active-regions when it is set to t.
>>
>> [ FWIW, I don't. ;-)  ]
>
> I figured I would set select-active-regions to nil since I never
> changed in in earlier versions, but there is an difference to the old
> behavior. In 23.3 (and before):
>
> -when one used the mouse to select a region the primary selection was set
>
> -when one set the mark and used movement commands to make an active
> region, the primary selection was not set
>
> In 24.0., if select-active-regions is t, both of these actions set the
> primary selection. But if select-active-regions is nil, neither of
> these actions set the primary selection.
>
> Do you know how I would get the behavior back what it was in 23.3?

OK. I see now that setting select-active-regions to 'only' makes it
work the way I'm used to, and 'cw' even works correctly.

Thanks all,
Bob

bug#9810: cw in viper mode clobbers clipboard

[Stefan Monnier]

> OK. I see now that setting select-active-regions to 'only' makes it
> work the way I'm used to, and 'cw' even works correctly.

Oh, yes, now I remember.  So it's no bug, sorry for the previous email.


        Stefan

bug#9810: cw in viper mode clobbers clipboard

[Stefan Monnier]

> primary selection. But if select-active-regions is nil, neither of
> these actions set the primary selection.

I think you should report this via M-x report-emacs-bug.


        Stefan

bug#9810: cw in viper mode clobbers clipboard

[Chong Yidong]

Bob Nnamtrop <bobnnamtrop@gmail.com> writes:

> I do not consider the selected word when one does 'cw' an active
> region (in the usual emacs sense). It is a vi construct independent of
> emacs active regions and so it need not honor the
> select-active-regions setting.

Could you test the following patch and see if it does what you expect?

=== modified file 'lisp/emulation/viper-cmd.el'
*** lisp/emulation/viper-cmd.el	2011-07-09 19:32:42 +0000
--- lisp/emulation/viper-cmd.el	2011-10-29 05:36:10 +0000
***************
*** 1387,1393 ****
  	(insert " ")(backward-char 1)))
    (if (= viper-com-point (point))
        (viper-forward-char-carefully))
!   (set-mark viper-com-point)
    (if (eq m-com 'viper-next-line-at-bol)
        (viper-enlarge-region (mark t) (point)))
    (if (< (point) (mark t))
--- 1387,1393 ----
  	(insert " ")(backward-char 1)))
    (if (= viper-com-point (point))
        (viper-forward-char-carefully))
!   (push-mark viper-com-point t)
    (if (eq m-com 'viper-next-line-at-bol)
        (viper-enlarge-region (mark t) (point)))
    (if (< (point) (mark t))
***************
*** 1396,1403 ****
        (viper-backward-char-carefully)) ; give back the newline
    (if (eq viper-intermediate-command 'viper-repeat)
        (viper-change-subr (mark t) (point))
!     (viper-change (mark t) (point))
!     ))
  
  ;; this is invoked by viper-substitute-line
  (defun viper-exec-Change (m-com com)
--- 1396,1403 ----
        (viper-backward-char-carefully)) ; give back the newline
    (if (eq viper-intermediate-command 'viper-repeat)
        (viper-change-subr (mark t) (point))
!     (viper-change (mark t) (point)))
!   (viper-deactivate-mark))
  
  ;; this is invoked by viper-substitute-line
  (defun viper-exec-Change (m-com com)

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Fri, Oct 28, 2011 at 11:37 PM, Chong Yidong <cyd@gnu.org> wrote:
> Bob Nnamtrop <bobnnamtrop@gmail.com> writes:
>
>> I do not consider the selected word when one does 'cw' an active
>> region (in the usual emacs sense). It is a vi construct independent of
>> emacs active regions and so it need not honor the
>> select-active-regions setting.
>
> Could you test the following patch and see if it does what you expect?
>
> === modified file 'lisp/emulation/viper-cmd.el'
> *** lisp/emulation/viper-cmd.el 2011-07-09 19:32:42 +0000
> --- lisp/emulation/viper-cmd.el 2011-10-29 05:36:10 +0000
> ***************
> *** 1387,1393 ****
>        (insert " ")(backward-char 1)))
>    (if (= viper-com-point (point))
>        (viper-forward-char-carefully))
> !   (set-mark viper-com-point)
>    (if (eq m-com 'viper-next-line-at-bol)
>        (viper-enlarge-region (mark t) (point)))
>    (if (< (point) (mark t))
> --- 1387,1393 ----
>        (insert " ")(backward-char 1)))
>    (if (= viper-com-point (point))
>        (viper-forward-char-carefully))
> !   (push-mark viper-com-point t)
>    (if (eq m-com 'viper-next-line-at-bol)
>        (viper-enlarge-region (mark t) (point)))
>    (if (< (point) (mark t))
> ***************
> *** 1396,1403 ****
>        (viper-backward-char-carefully)) ; give back the newline
>    (if (eq viper-intermediate-command 'viper-repeat)
>        (viper-change-subr (mark t) (point))
> !     (viper-change (mark t) (point))
> !     ))
>
>  ;; this is invoked by viper-substitute-line
>  (defun viper-exec-Change (m-com com)
> --- 1396,1403 ----
>        (viper-backward-char-carefully)) ; give back the newline
>    (if (eq viper-intermediate-command 'viper-repeat)
>        (viper-change-subr (mark t) (point))
> !     (viper-change (mark t) (point)))
> !   (viper-deactivate-mark))
>
>  ;; this is invoked by viper-substitute-line
>  (defun viper-exec-Change (m-com com)
>
>

Yes, it makes cw work the way I expect even if select-active-regions is t.

Thanks,
Bob

bug#9810: cw in viper mode clobbers clipboard

[Chong Yidong]

Bob Nnamtrop <bobnnamtrop@gmail.com> writes:

> Yes, it makes cw work the way I expect even if select-active-regions
> is t.

Thanks.  I've committed the patch.

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 12:46 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Right after you type 'cw' nothing in the buffer is erased. The word is
>> hi-lighted but that is it. So it should not change any selection at
>
> That's what is supposed to happen now that select-active-regions
> defaults to t.

Playing around a bit more exposes more inconsistencies:

-using the viper command R (viper-overwrite) hi-lights to the end of
the line in a similar way as cw does to the end of the word but the
primary selection is not clobbered. This is inconsistent to the
behavior of cw (although better).

-pasting in the primary selection (using <middle mouse>) or the
clipboard using C-y after the viper command R pastes the selection in
front of the 'R selection' instead of replacing the first part of the
'R selection' (whereas the same action after cw replaces the first
part of the 'cw selection'). Here the behavior of R is worse than cw.

Bob

bug#9810: cw in viper mode clobbers clipboard

[Lennart Borgman]

On Thu, Oct 20, 2011 at 22:57, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 12:46 PM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>> Right after you type 'cw' nothing in the buffer is erased. The word is
>>> hi-lighted but that is it. So it should not change any selection at
>>
>> That's what is supposed to happen now that select-active-regions
>> defaults to t.
>
> Playing around a bit more exposes more inconsistencies:
>
> -using the viper command R (viper-overwrite) hi-lights to the end of
> the line in a similar way as cw does to the end of the word but the
> primary selection is not clobbered. This is inconsistent to the
> behavior of cw (although better).

They actually work quite different. If you press ESC immediately after
R then nothing is changed in the buffer. However if you press escape
after cw then the word is still deleted.

So with respect to clipboard handling I think both are consistent and ok.

But maybe they do not behave the way vi does in this cases. (But that
is a totally different matter than this bug report.)

bug#9810: cw in viper mode clobbers clipboard

[Eli Zaretskii]

> Date: Thu, 20 Oct 2011 10:44:31 -0600
> From: Bob Nnamtrop <bobnnamtrop@gmail.com>
> Cc: 9810@debbugs.gnu.org
> 
> just typing 'cw' should not cause either clipboard or
> primary to be altered. The word is highlighted but that should be it,
> it should not go into primary (or clipboard or any other selection).
> The way it is now the common (for me) work-flow (put something into
> primary, go somewhere else, use cw then <middel mouse> to change that
> word) described above does not work anymore. The changes to primary
> and clipboard described in NEWS have nothing to do with this (or
> should not).

Can you tell me which function does the cw command run?

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 10:58 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 20 Oct 2011 10:44:31 -0600
>> From: Bob Nnamtrop <bobnnamtrop@gmail.com>
>> Cc: 9810@debbugs.gnu.org
>>
>> just typing 'cw' should not cause either clipboard or
>> primary to be altered. The word is highlighted but that should be it,
>> it should not go into primary (or clipboard or any other selection).
>> The way it is now the common (for me) work-flow (put something into
>> primary, go somewhere else, use cw then <middel mouse> to change that
>> word) described above does not work anymore. The changes to primary
>> and clipboard described in NEWS have nothing to do with this (or
>> should not).
>
> Can you tell me which function does the cw command run?
>

Well, I do not really understand the viper code, but some searching
and I found this comment at line 1602 in viper-cmd.el

;; This function is called by various movement commands to execute a
;; destructive command on the region specified by the movement command.  For
;; instance, if the user types cw, then the command viper-forward-word will
;; call viper-execute-com to execute viper-exec-change, which eventually will
;; call viper-change to invoke the replace mode on the region.

bug#9810: cw in viper mode clobbers clipboard

[Eli Zaretskii]

> Date: Thu, 20 Oct 2011 10:18:06 -0600
> From: Bob Nnamtrop <bobnnamtrop@gmail.com>
> 
> emacs -Q
> M-x viper
> i (ie, go into insert mode)
> asdf hjkl (type a few words)
> <escape> (ie, go into command mode)
> click on the 'a' (or move there any way you want)
> double click to put 'asdf' into emacs clipboard (ie X11 clipboard,
> primary, whatever)
> click on the 'h' (or move there any way you want)
> cw (ie viper command to change word)j
> <middle mouse click> (to paste the clipboard, or yank or whatever
> emacs calls it :-)
> hjkl is pasted in
> 
> But 'asdf' should have been pasted in.

Did you read the section "Selection changes" in etc/NEWS?  I think
what you see is the result of a deliberate change in behavior
described there.  In particular, double-clicking a mouse no longer
puts the selected text into the clipboard, only into the PRIMARY
selection.

> This is very annoying and I cannot imagine using the new version if
> this is not fixed.

The above-mentioned section also tells you how to customize Emacs to
get the old behavior back.

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 10:27 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Thu, 20 Oct 2011 10:18:06 -0600
>> From: Bob Nnamtrop <bobnnamtrop@gmail.com>
>>
>> emacs -Q
>> M-x viper
>> i (ie, go into insert mode)
>> asdf hjkl (type a few words)
>> <escape> (ie, go into command mode)
>> click on the 'a' (or move there any way you want)
>> double click to put 'asdf' into emacs clipboard (ie X11 clipboard,
>> primary, whatever)
>> click on the 'h' (or move there any way you want)
>> cw (ie viper command to change word)j
>> <middle mouse click> (to paste the clipboard, or yank or whatever
>> emacs calls it :-)
>> hjkl is pasted in
>>
>> But 'asdf' should have been pasted in.
>
> Did you read the section "Selection changes" in etc/NEWS?  I think
> what you see is the result of a deliberate change in behavior
> described there.  In particular, double-clicking a mouse no longer
> puts the selected text into the clipboard, only into the PRIMARY
> selection.
>
>> This is very annoying and I cannot imagine using the new version if
>> this is not fixed.
>
> The above-mentioned section also tells you how to customize Emacs to
> get the old behavior back.
>

I just read that info in NEWS about selection changes and I'm glad I
did (since it will affect me in other ways). But it should have
nothing to do with the bug I describe. The point I make is that 'cw'
should not alter any of the selections (primary, clipboard, etc). The
word gets hi-lighted but that is only a visual aid, it should not
alter the 'selection'.

Bob

bug#9810: cw in viper mode clobbers clipboard

[Lennart Borgman]

On Thu, Oct 20, 2011 at 18:48, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
>
> The point I make is that 'cw'
> should not alter any of the selections (primary, clipboard, etc).

Doing just 'cw' in viper actually deletes the word in the buffer so
putting it on the clipboard is the expected behavior.

bug#9810: cw in viper mode clobbers clipboard

[Bob Nnamtrop]

On Thu, Oct 20, 2011 at 10:58 AM, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 18:48, Bob Nnamtrop <bobnnamtrop@gmail.com> wrote:
>>
>> The point I make is that 'cw'
>> should not alter any of the selections (primary, clipboard, etc).
>
> Doing just 'cw' in viper actually deletes the word in the buffer so
> putting it on the clipboard is the expected behavior.
>

Well, I do not know if that is true or not from a technical
standpoint. But from the user perspective the word is not deleted
until you type some new text or hit <esc>. Right after typing cw the
word is still displayed and it is hi-lighted. So I would not say it is
deleted. There is no advantage to the user to clobber the selection
that that point, since they may want to use what was previously in
there.

I just tried what I originally describe in a terminal window (ie
starting from emacs -Q -nw) and it works as I expect. The previously
selected selection is pasted in to the hi-lighted word after typing
cw. Just like it all previous versions of emacs (terminal or not).

Bob

bug#9810: cw in viper mode clobbers clipboard

[Eli Zaretskii]

> Date: Thu, 20 Oct 2011 11:09:58 -0600
> From: Bob Nnamtrop <bobnnamtrop@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 9810@debbugs.gnu.org
> 
> I just tried what I originally describe in a terminal window (ie
> starting from emacs -Q -nw) and it works as I expect. The previously
> selected selection is pasted in to the hi-lighted word after typing
> cw. Just like it all previous versions of emacs (terminal or not).

On a text terminal, Emacs does not interact with the clipboard or
selections, so any problems with the clipboard or selections will
never show in "emacs -nw".