'Keyboard input' vs 'cursor copy+paste' for "repeat" (.) action

23 views
Skip to first unread message

Eric Marceau

unread,
Jul 5, 2023, 4:24:01 PM7/5/23
to vim...@googlegroups.com

Currently using

VIM version 8.1.3741
on Ubuntu MATE (Linux 5.4.0-150-generic #167-Ubuntu)

When I copy+paste text using the system cursor,

regardless of whether that text is from another non-Vim
window, or from the text file currently in the Vim window,
if the text string being inserted is a combination of
typed-input and copy+paste,  the Vim's "." (repeat operator)
seems to ignore the copy+paste text and will only repeat
that portion of the entry which was directly-typed at the
keyboard (i.e. xyz{cut+paste_text}<return>abc )!!!

Is that behaviour controlled by a modifiable Vim parameter
which can be set to allow both inputs to be captured as
a single operation for full repeat?


Thank you,

Eric

meine

unread,
Jul 6, 2023, 3:42:48 AM7/6/23
to vim...@googlegroups.com
On Wed, Jul 05, 2023 at 04:23:54PM -0400, Eric Marceau wrote:
> Currently using
>
> VIM version 8.1.3741
> on Ubuntu MATE (Linux 5.4.0-150-generic #167-Ubuntu)
>
> When I /copy+paste/ text using the system cursor,
>
> regardless of whether that text is from another non-Vim
> window, or from the text file currently in the Vim window,
>
> if the text string being inserted is a combination of
> */typed-input/* and /*copy+paste*/,  the Vim's "." (repeat operator)
> seems to ignore the /copy+paste/ text and will *only* repeat
> that portion of the entry which was /directly-typed at the //
> //keyboard/ (i.e. xyz{cut+paste_text}<return>abc )!!!
>
> Is that behaviour controlled by a modifiable Vim parameter
> which can be set to allow both inputs to be captured as
> a *single operation for full repeat*?

Cutting and copying tekst places the text in a register -- the '0
register'. The paste command places the contence of that register where pasted.

The pasting can be repeated with the dot-command, it pastes the same
text from the dot-register.

Since the dot-command only repeats the last command, it kan only repeat
the pasting. Copying another word overwrites the buffer the text is
copied into.

You could make a small macro to combine commands you want and use that.

Vim has several registers that you can use to copy text into and only
call that register to paste the text. The working is great but can be
overwhelming to learn. See `help: registers`.

//meine

Eric Marceau

unread,
Jul 6, 2023, 11:54:12 AM7/6/23
to vim...@googlegroups.com

Thank you, meine.

Not sure that you understood that my

/*typed-input*/ and /*copy+paste*/

are both during the same insert/replace operation.

Since both inputs have been "inserted" together (in my view),

why are they not being captured as a complete set for the

repeat operation?


Eric

Salman Halim

unread,
Jul 6, 2023, 12:09:51 PM7/6/23
to Vim Users
On Windows, if my * register (system clipboard) contains some text and I type:

iHello <c-r>=*<esc>

Then, hitting . repeats the whole thing, including the pasted text. Perhaps you're pasting in a different way?

Do you have custom mappings? Some plugins take over the . (such as repeat.vim).

Salman

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/6fd8c8e4-d7f4-bd54-eab0-a4e668858ec3%40gmail.com.

Eric Marceau

unread,
Jul 6, 2023, 2:29:15 PM7/6/23
to vim...@googlegroups.com

Thank you, Salman.

My customizations are limited to the appearance and layout.  I have not installed any related to action-key mappings.  I don't know how to obtain a report of all such mappings (default + custom).  If anything was mapped differently, it was not disclosed as part of the appearance plug-ins.

Attached is my .vimrc file.

Under plugin, I have the following:

ColorSchemeEditor.glade
ColorSchemeEditor.py
ColorSchemeEditor.vim
CSApprox.vim
ScrollColor.vim
VIM__ID_2180__ColorSchemeEditor   (directory)

Under each of pack and bundle, there is nothing populated.

Under autoload, there is only

csapprox.vim

Everything under after relates to csapprox.

Under syntax, I have:

bash.vim.SUPPRESS
BOURNE.txt
logtalk.vim
lprolog.vim
modsim3.vim
prolog.vim
sh.vim.DISTRO
sh.vim.GITHUB
sh.vim.HIDE
sh.vim.Oasis
sh.vim.SUPPRESS

Given the above, I don't see why it is behaving as it is.

Eric

vimrc

Gary Johnson

unread,
Jul 6, 2023, 6:12:34 PM7/6/23
to vim...@googlegroups.com
On 2023-07-06, Eric Marceau wrote:
> Thank you, Salman.
>
> My customizations are limited to the appearance and layout.  I have not
> installed any related to action-key mappings.  I don't know how to obtain a
> report of all such mappings (default + custom).  If anything was mapped
> differently, it was not disclosed as part of the appearance plug-ins.

Pure Vim has no default mappings. (If your Vim is configured to
source $VIMRUNTIME/defaults.vim at startup, you will have two
mappings defined by that file.) Those keys and key-combinations
you type to make things happen are the names of the commands.

To see a list all such commands, see

:help index

To get a list of any mappings in effect, type

:map

to see normal-mode mappings and

:map!

to see insert-mode mappings. Actually, mappings in more modes than
just normal and insert are shown by those commands, but I don't know
which command lists which other modes. You can read about this in

:help map-overview
:help map-listing
:help mapmode-i

For everything about maps, see

:help 5.4
:help 40.1
:help map.txt

HTH,
Gary

Eric Marceau

unread,
Jul 7, 2023, 12:45:46 PM7/7/23
to vim...@googlegroups.com

Thank you, Gary, for all that info.  It will be very helpful.

When I get the ":map" report, I get the following:

The report from ":map!" gives:


So my interpretation is that there is not deviation from the base.

Also, to clarify, when I paste from "clipboard" (copy of mouse-highlighted),
when the operation is replace (R), it only inserts instead of replacing.  The
replace function only works for data entered directly at the keyboard.

Is there any way to change that setting, so that "mouse-pasted text"
will replace the text starting at the insert/replace point in the file?


Text before doing "R" replace:


Text after starting "R" operation by typing word (pulvinar):


"mouse-copied" text "rhoncus" pasted at next position in
replace operation:
NOTE:  "mouse-copied" text  is only inserted, not replacing!!!

Continuing keyboard "R" entry by typing "magna", overwriting
libero as expected:

So ... gvim is treating the input source differently.
Maybe the drop-down menu for handling visual needs to be
context sensitive, based on the current action being performed,
whether that is "i" (insert) or "R" (replace).

The intuitive expectation is that the "mouse-copied" text
replace the file text in the same manner as keyboard entry.

Also, when I go to perform the "." (repeat" operation, it is again
not performing as expected.  It does not paste the entire
"single-input" sequence, only the last portion of the keyboard
entry "magna", not even keeping the first portion "pulvinar".
So, the "paste" operation is definitely resetting the entire
"R" (replace) operation buffer, which does not register that as
"keyboard" entry (my intuitive expectation), leaving only that
final word, at the start of the 7th line (orange cursor line).

Am I wrong about my expectations for behaviour encompassing
both keyboard and mouse-pasted as a "whole" for repeat
operations?


Eric

P.S.  Raw text for example:

Etiam volutpat ligula eu lorem iaculis venenatis. Pellentesque rhoncus viverra arcu ut rhoncus. Curabitur in nibh mauris. Pellentesque volutpat convallis erat eu interdum. Mauris placerat libero at ante porta, nec hendrerit urna vehicula. Quisque nec leo sem. Curabitur pulvinar nisl eu magna tempor pellentesque. Cras vitae tempus purus, euismod eleifend massa.

Gary Johnson

unread,
Jul 7, 2023, 5:40:33 PM7/7/23
to vim...@googlegroups.com
On 2023-07-07, Eric Marceau wrote:
> Thank you, Gary, for all that info.  It will be very helpful.

You're welcome.

> When I get the *":map"* report, I get the following:
>
> The report from ":map!" gives:
>
>
> So my interpretation is that there is not deviation from the base.

I read all my email from technical mailing lists in mutt, and I've
never figured out how to get it to display images in-line. I looked
at the images out-of-context and I think I get the gist.

> Also, to clarify, when I paste from "clipboard" (copy of mouse-highlighted),
> when the operation is replace (R), it only inserts instead of
> replacing.  The
> replace function only works for data entered directly at the keyboard.

It works fine for me. I'm running Xfce on Ubuntu 20.22 and have vim
running in an xterm and gvim running in its own window, with random
text in both. In either window, I can highlight and copy text by
dragging the mouse over it with the left button pressed, then
release the button. In the other window, if I type R and press the
middle mouse button, the text after the cursor is replaced by what
I copied; if I type i and press the middle mouse button, the copied
text is inserted. All is as you would expect.

I repeated the experiment, but with vim and gvim each started with
"-N -u NONE -i NONE" to avoid anything special in my setup.
I executed the following in each:

:set mouse=a
:set clipboard+=unnamed

Again, I can copy text from either window by dragging the mouse
across it, and in the other, R replaced and i inserts.

> Is there any way to change that setting, so that "mouse-pasted text"
> will replace the text starting at the insert/replace point in the file?

So, it appears that Vim normally behaves that way but that there is
something in your setup that interferes with that.

I'd start Vim as I did, verify that copy-and-replace behaves as we
think it should, then add pieces of your setup until it breaks. If
it is broken at the start, then we'll have to look at the rest of
your environment and/or at how your Vim was built.

> So ... gvim is treating the input source differently.
> Maybe the drop-down menu for handling visual needs to be
> context sensitive, based on the current action being performed,
> whether that is "i" (insert) or "R" (replace).
>
> The intuitive expectation is that the "mouse-copied" text
> replace the file text in the same manner as keyboard entry.

Oh! I see now. If you paste by using the Edit menu Paste
operation, your copied text _is_ inserted, even when in Replace
mode. I never use the menu bar--I hardly ever use the mouse--so
I didn't think to check that at first. You're right--that's not
what I would expect, either. I see the command that's doing that,
but I don't have an explanation for why the menu Paste operation
doesn't adapt to the insert/replace mode.

> Also, when I go to perform the "." (repeat" operation, it is again
> not performing as expected.  It does not paste the entire
> "single-input" sequence, only the last portion of the keyboard
> entry "magna", not even keeping the first portion "pulvinar".
> So, the "paste" operation is definitely resetting the entire
> "R" (replace) operation buffer, which does not register that as
> "keyboard" entry (my intuitive expectation), leaving only that
> final word, at the start of the 7th line (orange cursor line).

If you type part of your text and paste other parts from the mouse
using a mouse button, all your text should be handled as one unit,
so that typing . to repeat the operation should insert or replace
all of it. However, if you paste text from the mouse by using the
Edit->Paste command from the menu, you have pasted that text by
performing a separate command, "+gP , which will terminate the
current command before it is executed. The . command repeats only
the last command executed.

> Am I wrong about my expectations for behaviour encompassing
> both keyboard and mouse-pasted as a "whole" for repeat
> operations?

I don't think your expectations are wrong, but sometimes you have to
pay more attention than you think you would to the details of how
Vim performs certain operations, such as Edit->Paste executing
a paste command rather than just emitting the contents of the
clipboard.

Regards,
Gary

Reply all
Reply to author
Forward
0 new messages