Index | Thread | Search

From:
Christian Schulte <cs@schulte.it>
Subject:
Re: Improvement for vi(1) paste comand (updated diff)
To:
tech@openbsd.org
Date:
Fri, 6 Feb 2026 20:33:20 +0100

Download raw body.

Thread
Am 06.02.2026 um 11:11 schrieb Walter Alejandro Iglesias:
> Recently, I got the first useful feedback (in private) about this patch
> of mine, so far ignored:
> 
>   https://marc.info/?l=openbsd-tech&m=175645383505284&w=2
> 
> Jeremy Mates made me notice the following:
> 
> On Wed, Feb 04, 2026 at 10:54:26PM +0000, Jeremy Mates wrote:
>> a
>> b
>> c
>> 1
>> 2
>> 3
>> 4
>> 5
>> 6
>>
>> With the cursor on 1 (the 4th line), and a vi with
>>
>> https://marc.info/?l=openbsd-tech&m=175645383505284&w=2
>>
>> applied the copy command of 1,3t. (copy lines 1..3 to the current line)
>> results in the cursor on 3. The base OpenBSD vi (as of 7.7, I really
>> should upgrade sometime) meanwhile instead puts the cursor on c, which
>> seems a more sensible result.
> 
> What Jeremy describes happens because of the following workaround
> present in ex_copy() (ex/ex_move.c:65):
> 
>        /*
>         * Copy puts the cursor on the last line copied.  The cursor
>         * returned by the put routine is the first line put, not the
>         * last, because that's the historic semantic of vi.
>         */
>        cnt = (fm2.lno - fm1.lno) + 1;
>        sp->lno = m.lno + (cnt - 1);
>        sp->cno = 0;
> 
> That comment explains the detour they had to take just to be respectful
> with the "historic semantic of vi." 
This is why people were against changing behavior of just a single
command without verifying the impact this has on other commands in the
various modes. Change behavior of 'p'. Notice a few weeks later another
command was relying on the former behavior. Change that command as well
without verifying no other command depends on that behavior again. Come
back in a few weeks, because now another command needs updating, too.
This is just not the way things should be done. I am not saying your
efforts are not appreciated. You would need to setup some process
backing those changes by testing any single change against some
testcases to ensure a change to one command does not break another.
People could be convinced a change is justified/needed/done right that
way easier.

Just my 2cents,
-- 
Christian