Hello Walter,

we have now three options what to do with 'P' in ksh(1) VI mode; one
of them also changes the behaviour of 'p'.  So i'm asking people:
which one of the three do you prefer?

If people prefer one of the two solutions proposed by Walter, i'll
polish, test, and commit that.  Otherwise, i'll commit the diff i
posted earlier.  Something needs to be committed because right now,
the 'P' command misbehaves with UTF-8.

Walter Alejandro Iglesias wrote on Thu, Apr 24, 2025 at 10:49:02AM +0200:
> On Mon, Apr 21, 2025 at 11:38:01PM +0200, Ingo Schwarze wrote:

>> here is a patch to change the behaviour of the "paste before" (P) command
>> in the VI command line editing mode of ksh(1).

> With your diff, after pasting with the 'P' command the cursor lands one
> character *after* the last character in the string pasted.

Correct.
That is also the character the cursor is on before pasting.

> I'm not saying this is wrong, maybe it's more convenient, but it's not
> what the 'p' command does

Correct.
In our ksh(1), 'p' puts the cursor on the last character inserted.

> or what other popular applications (vim, bash) that
> have adopted moving the cursor to the end of the pasted string do.
> 
> The two diffs below are *NOT TESTED* (but considering I'm not modifying
> functions in this case, they probably won't cause regressions.)  The
> idea is to show the difference between two behaviors with practical
> examples; you'll decide which one you like best.

I do not feel strongly about which cursor positioning after 'p' or 'P'
might be most useful.  Opinions from people who actually use VI mode
in our ksh(1) would be particularly appreciated.  Opinions from
developers would be helpful even if they do not use VI mode.

If nobody voicces a preference, i tend to use the diff i posted
because it is least intrusive, and *if* there is limited interest,
least intrusive is arguably best.

> The first behavior (vi(1), nvi2 from ports, FreeBSD sh):
> 
>   After pasting text with 'p' or 'P' the cursor lands on the first
>   character of the string pasted.

I can confirm this is what our vi(1) does.  I did not test nvi2
or FreeBSD.

> The second behavior (vim, bash and other shells):
> 
>   After pasting text with 'p' or 'P' the cursor lands on the last
>   character of the string pasted.

I did not test vim or bash, but there is one potential (weak) argument
supporting this behabiour: in our ksh(1), that's where the cursor
lands when you insert text with 'a' or 'i' and press ESCAPE.
So arguably, this option slightly improves consistency of ksh(1) VI mode.

Looking at the ksh(1) manual page, i do not see any other VI mode
commands that could be looked at as a model for what 'p' and 'P'
should do.

> (By the way, I found a bug on vi(1) paste command.  I'll report it in
> other thread in the future.)

Thanks, keeping different issues in different, well-named threads
helps everyone.

> FIRST BEHAVIOR (vi like)  # go to the first inserted character
> 
> Index: vi.c
> ===================================================================
> RCS file: /cvs/src/bin/ksh/vi.c,v
> diff -u -p -r1.61 vi.c
> --- vi.c	21 Apr 2025 20:06:15 -0000	1.61
> +++ vi.c	24 Apr 2025 08:36:19 -0000
> @@ -837,8 +837,10 @@ vi_cmd(int argcnt, const char *cmd)
>  			while (es->cursor < es->linelen)
>  				if (!isu8cont(es->cbuf[++es->cursor]))
>  					break;
> +			any = es->cursor;
>  			while (putbuf(ybuf, yanklen, 0) == 0 && --argcnt > 0)
>  				;
> +			es->cursor = any + 1;
>  			while (es->cursor > 0)
>  				if (!isu8cont(es->cbuf[--es->cursor]))
>  					break;

From code inspection, this looks likely to do what you want.
Probably, it would be even better to replace the last four lines
with simply

	es->cursor = any;

because if the first inserted character is valid UTF-8, that does the
same, and if the first inserted character is isu8cont (which shouldn't
normally happen), backing up to the last character before the insertion
feels like a dubious choice.

> @@ -848,11 +850,10 @@ vi_cmd(int argcnt, const char *cmd)
>  
>  		case 'P':
>  			modified = 1; hnum = hlast;
> -			any = 0;
> +			any = es->cursor;
>  			while (putbuf(ybuf, yanklen, 0) == 0 && --argcnt > 0)
> -				any = 1;
> -			if (any && es->cursor != 0)
> -				es->cursor--;
> +				continue;
> +			es->cursor = any;
>  			if (argcnt != 0)
>  				return -1;
>  			break;

Yes, that might do what you want.

> SECOND BEHAVIOR (vim like)  # go to the last inserted character
> 
> Index: vi.c
> ===================================================================
> RCS file: /cvs/src/bin/ksh/vi.c,v
> diff -u -p -r1.61 vi.c
> --- vi.c	21 Apr 2025 20:06:15 -0000	1.61
> +++ vi.c	24 Apr 2025 07:34:50 -0000
> @@ -848,11 +848,9 @@ vi_cmd(int argcnt, const char *cmd)
>  
>  		case 'P':
>  			modified = 1; hnum = hlast;
> -			any = 0;
>  			while (putbuf(ybuf, yanklen, 0) == 0 && --argcnt > 0)
> -				any = 1;
> -			if (any && es->cursor != 0)
> -				es->cursor--;
> +				continue;
> +			es->cursor--;

Not quite, instead of es->cursor--, here we would likely need

	while (es->cursor > 0)
		if (!isu8cont(es->cbuf[--es->cursor]))
			break;

such that we back up a complete character and not just a single byte.

So, which behaviour do people want?

 0) minimally invasive, 1P unchanged:
    p  unchanged -> to last character inserted
    1P unchanged -> after last character inserted
    2P changed to match 1P -> after last character inserted

 1) meximally invasive -> always to first charcter inserted
    like in our vi(1)

 2) minimally invasive, 2P unchanged -> always to last character inserted
    p  unchanged
    1P changed to match 2P
    2P unchanged

Yours,
  Ingo