Friday, July 7, 2023

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

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

--
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/20230707213859.GK6600%40phoenix.

No comments: