From: Walter Alejandro Iglesias Subject: Re: ksh vi mode: stop 'P' command from moving the cursor To: Ingo Schwarze Cc: Anton Lindqvist , millert@openbsd.org, tech@openbsd.org Date: Thu, 24 Apr 2025 21:36:37 +0200 Ingo, On Thu, Apr 24, 2025 at 05:39:56PM +0200, Ingo Schwarze wrote: > 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 I see you judge only in terms of invasiveness. :-) Your first proposal doesn't have to be wrong, but as far as I know it has no precedent, so you should point a good reason to justify your innovation. Second, in case you decide to implement your proposal, did you take in mind to also change the 'p' command to behave in the same manner? Finnaly, it would be great to wait to hear about the bug I found in vi(1) (I already reported the bug to Zhihao Yuan, the nvi2 developer.) I have the suspicion (just guessing) that whoever implemented the current behavior in the put buffer function on vi(1) broke the 'p' command using numeric prefix. This make me more inclined to prefer my second example (the vim like one,) which if, I'm not wrong, is the original. > > Yours, > Ingo > -- Walter