PATCH: overwrite mode shouldn't replace newlines

PATCH: overwrite mode shouldn't replace newlines

[Oliver Kiddle]

In overwrite mode, either emacs style or vi-replace, on reaching the end
of the line new characters should be inserted rather than the newline be
replaced.

There was also a bug that the numeric argument was ignored when counting
characters to replace so doing <Escape>4w would replace one character
with 4 'w's.

Oliver

diff --git a/Src/Zle/zle_misc.c b/Src/Zle/zle_misc.c
index a220a6b..a1dc3fa 100644
--- a/Src/Zle/zle_misc.c
+++ b/Src/Zle/zle_misc.c
@@ -47,13 +47,13 @@ doinsert(ZLE_STRING_T zstr, int len)
     iremovesuffix(c1, 0);
     invalidatelist();
 
-    if (insmode)
+    /* In overwrite mode, don't replace newlines. */
+    if (insmode || zleline[zlecs] == ZWC('\n'))
 	spaceinline(m * len);
     else
-#ifdef MULTIBYTE_SUPPORT
     {
 	int pos = zlecs, diff, i;
-
+#ifdef MULTIBYTE_SUPPORT
 	/*
 	 * Calculate the number of character positions we are
 	 * going to be using.  The algorithm is that
@@ -68,15 +68,18 @@ doinsert(ZLE_STRING_T zstr, int len)
 	 * useful there anyway and this doesn't cause any
 	 * particular harm.
 	 */
-	for (i = 0, count = 0; i < len; i++) {
+	for (i = 0, count = 0; i < len * m; i++) {
 	    if (!IS_COMBINING(zstr[i]))
 		count++;
 	}
+#else
+	count = len * m;
+#endif
 	/*
-	 * Ensure we replace a complete combining character
-	 * for each character we overwrite.
+	 * Ensure we replace a complete combining characterfor each
+	 * character we overwrite. Switch to inserting at first newline.
 	 */
-	for (i = count; pos < zlell && i--; ) {
+	for (i = count; pos < zlell && zleline[pos] != ZWC('\n') && i--; ) {
 	    INCPOS(pos);
 	}
 	/*
@@ -96,10 +99,6 @@ doinsert(ZLE_STRING_T zstr, int len)
 	    shiftchars(zlecs, diff);
 	}
     }
-#else
-    if (zlecs + m * len > zlell)
-	spaceinline(zlecs + m * len - zlell);
-#endif
     while (m--)
 	for (s = zstr, count = len; count; s++, count--)
 	    zleline[zlecs++] = *s;
diff --git a/Test/X02zlevi.ztst b/Test/X02zlevi.ztst
index e1ee167..5204311 100644
--- a/Test/X02zlevi.ztst
+++ b/Test/X02zlevi.ztst
@@ -43,6 +43,19 @@
 >
 >CURSOR: 2
 
+  zletest $'\eOword\eO\eraok\ejrxj.rae'
+0:replace character when at end of buffer or newline
+>BUFFER: ok
+>wxrd
+>e
+>CURSOR: 9
+
+  zletest $'two\eOone\ehRreplace'
+0:replace acts like insert at newline
+>BUFFER: oreplace
+>two
+>CURSOR: 8
+
   zletest $' four\eO\C-v\tthree\eO  two\eOone\e3J'
 0:join lines with line count
 >BUFFER: one two three

Re: PATCH: overwrite mode shouldn't replace newlines

[Ray Andrews]

On 11/29/2014 04:04 PM, Oliver Kiddle wrote:
> In overwrite mode, either emacs style or vi-replace, on reaching the end
> of the line new characters should be inserted rather than the newline be
> replaced.
>
Sorry for  ranting, just ignore this, but how is it possible that a 
mistake in something so basic could have survived until now?  How can 
the best, and the second most used, shell in 'nix have permitted such an 
oversight to have existed for (what?) four decades?  When folks run into 
those things, do they just shrug their shoulders?  We see so many things 
that are just-plain-bugs, how do they get past testing?  It seems that 
culturally one should view the shells as sorta like the New York subway 
system--it's huge and the trains mostly run on time, but don't bet your 
life on it, and if the system breaks down, just stay calm they'll fix it 
eventually.  Are things so complicated that they can no longer be 
maintained?  Sheesh, after the kernel, the most bullet proof thing on a 
computer should be the shell.  Dunno, but it's hard to understand.

Re: PATCH: overwrite mode shouldn't replace newlines

[Bart Schaefer]

On Nov 29,  5:23pm, Ray Andrews wrote:
} Subject: Re: PATCH: overwrite mode shouldn't replace newlines
}
} On 11/29/2014 04:04 PM, Oliver Kiddle wrote:
} > In overwrite mode, either emacs style or vi-replace, on reaching the end
} > of the line new characters should be inserted rather than the newline be
} > replaced.
} >
} Sorry for  ranting, just ignore this, but how is it possible that a 
} mistake in something so basic could have survived until now?

Input editing of this sort isn't even the shell's "basic" job.  (E.g.
bash uses readline which is an entirely separate project tested and
maintained independently.)  There are plenty of "basic" things to
rant about, but this doesn't qualify.

} Are things so complicated that they can no longer be maintained?

Since this bug has probably existed since the beginning of time (in zsh
terms), it has little to do with complication that has crept in since.

Like most open-source projects dating from the late 80s, zsh relied on
users to test and report bugs.  There has never been enough volunteer
manpower for a dedicated all-code-paths testing regimen, so a bug that
a real user never encounters will only rarely be fixed.

That a patch showed up would argue against "no longer maintained."

Re: PATCH: overwrite mode shouldn't replace newlines

[Ray Andrews]

On 11/30/2014 11:24 AM, Bart Schaefer wrote:
> Like most open-source projects dating from the late 80s, zsh relied on
> users to test and report bugs.  There has never been enough volunteer
> manpower for a dedicated all-code-paths testing regimen, so a bug that
> a real user never encounters will only rarely be fixed.
That is demonstrably the case.  But as a guy who's done some testing in 
a project
I can't help but notice that trying overstrike mode would be one of the 
first
things I'd have done. It's another cultural adjustment for me.

Re: PATCH: overwrite mode shouldn't replace newlines

[Jan Larres]

On 01/12/14 08:55, Ray Andrews wrote:
> On 11/30/2014 11:24 AM, Bart Schaefer wrote:
>> Like most open-source projects dating from the late 80s, zsh relied on
>> users to test and report bugs.  There has never been enough volunteer
>> manpower for a dedicated all-code-paths testing regimen, so a bug that
>> a real user never encounters will only rarely be fixed.
> That is demonstrably the case.  But as a guy who's done some testing in a project
> I can't help but notice that trying overstrike mode would be one of the first
> things I'd have done. It's another cultural adjustment for me.

Open Source projects, unless they're run by a company, rarely have
dedicated testers whose only job it is to look for bugs. Sometimes
people decide to spend some time on that due to a sense of duty, but
generally it makes more sense to spend time on areas that actually
benefit the most people, or that interest the contributor personally,
instead of trying to find every last bug (which is impossible anyway).
The fact that this bug apparently wasn't discovered until now or at
least not deemed important enough by users to report it shows that not
that many people would have benefited from a comprehensive testing
approach here. Of course doing more testing is generally a good thing,
but there is also a cost/benefit factor to consider, especially for
volunteer-run projects.

-Jan