<h1 dir="auto">Environment</h1>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="
Windows build number: [Version 10.0.18362.267] Windows 10 Professional Version 1903
Windows Terminal version (if applicable): whatever is out-of-the-box

Any other software?"><pre class="notranslate"><code class="notranslate">
Windows build number: [Version 10.0.18362.267] Windows 10 Professional Version 1903
Windows Terminal version (if applicable): whatever is out-of-the-box

Any other software?
</code></pre></div>
<ul dir="auto">
<li>Ubuntu 18.04.LTS from the Microsoft Store fully updated with<br>
<code class="notranslate">sudo apt update ; sudo apt upgrade</code></li>
<li>The joe editor installed in Ubuntu with<br>
<code class="notranslate">sudo apt install joe</code></li>
</ul>
<h1 dir="auto">Steps to reproduce</h1>
<ol dir="auto">
<li>Start the joe editor with a new file without specifying a filename</li>
<li>Type 3 lines at least to see what happens, e.g.:</li>
</ol>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="line1
line2
line3"><pre class="notranslate"><code class="notranslate">line1
line2
line3
</code></pre></div>
<ol start="3" dir="auto">
<li>Go back with the cursor to the beginning of line2.</li>
<li>Press the ENTER key.</li>
</ol>
<h1 dir="auto">Expected behavior</h1>
<p dir="auto">A new line should be inserted in the place of the cursor and the part of the file starting with the cursor position was in should be scrolled down on the screen and the last shown line should scroll out (disappear) and the cursor should move one line down.</p>
<p dir="auto">I.e. you should see</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="line1

line2
line3"><pre class="notranslate"><code class="notranslate">line1

line2
line3
</code></pre></div>
<p dir="auto">and the new cursor position should be at the beginning of line2</p>
<p dir="auto"><strong>Note that after saving the file, the expected behavior is what correctly happens in the file data, only the display behavior is incorrect.</strong></p>
<p dir="auto"><strong>Note, that this worked correctly in Windows 1803 with the same Ubuntu 18.04 LTS and joe versions. The upgrade to Windows 1903 broke this, and reinstalling joe and reinstalling the entire Ubuntu 18.04 LTS distribution did not fix this either.</strong></p>
<h1 dir="auto">Actual behavior</h1>
<p dir="auto">No scrolling of the part after the cursor happens, instead the line the cursor was in is cleared (becomes empty, not disappear), and the cursor (correctly) moves down to the beginning of the next line.</p>
<p dir="auto">I.e. you see</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="line1

line3"><pre class="notranslate"><code class="notranslate">line1

line3
</code></pre></div>
<p dir="auto">and the cursor position is at the beginning of line3.</p>
<p dir="auto"><strong>Note that after saving the file, the expected behavior is what correctly happens to the file data, only the display behavior is incorrect.</strong></p>
<h1 dir="auto">Environment</h1>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="Windows build number: 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0"><pre lang="none" class="notranslate"><code class="notranslate">Windows build number: 10.0.18362.0
Windows Terminal version (if applicable): 0.5.2762.0
</code></pre></div>
<h1 dir="auto">Steps to reproduce</h1>
<p dir="auto">Issue an EL (clear to end of line, <code class="notranslate">\e[K</code>) when the cursor is at the rightmost position, in "pending wrap" a.k.a. "delayed eol wrap" state. Print further characters. E.g.:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="printf &quot;%$(tput cols)s\e[K%s\n&quot; 0123456789 abcdef"><pre class="notranslate"><code class="notranslate">printf "%$(tput cols)s\e[K%s\n" 0123456789 abcdef
</code></pre></div>
<h1 dir="auto">Expected behavior</h1>
<p dir="auto">xterm's behavior, and as far as I know the "official" one is that EL clears the "delayed eol wrap" state along with erasing the last column (<code class="notranslate">9</code>), resulting in (denoting the right margin by a "left one eighth block" <code class="notranslate">▏</code>):</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="          012345678a▏
bcdef               ▏"><pre class="notranslate"><code class="notranslate">          012345678a▏
bcdef               ▏
</code></pre></div>
<p dir="auto">Some terminals, including <a href="https://bugzilla.gnome.org/show_bug.cgi?id=740789" rel="nofollow">VTE</a>, iTerm2, Kitty, Konsole, PuTTY 0.73 intentionally deviate: make EL not clear the "delayed eol wrap" flag and not erase the last character either:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="          0123456789▏
abcdef              ▏"><pre class="notranslate"><code class="notranslate">          0123456789▏
abcdef              ▏
</code></pre></div>
<p dir="auto">Rationale:</p>
<p dir="auto">There are several utilities that want to just simply print some text with colors or other attributes, without caring about the terminal width or doing anything more complex terminal driving. If these attributes include a background color too, the behavior is messy across a linewrap, due to the <a href="https://bugzilla.gnome.org/show_bug.cgi?id=754596" rel="nofollow">terribly designed bce (background color earse)</a> feature. (Now, VTE, and perhaps some other emulators too, intentionally implement bce differently, as another means of mitigating the problem I'm describing here, but let's leave that to another day.)</p>
<p dir="auto">As a workaround for the background color problem, several utilities decide to also emit an EL after restoring the background color, to earse the faulty color there. And they often don't realize that this introduces an even more serious issue: at linewrap, a character might get dropped from the output. An example is <a href="http://savannah.gnu.org/bugs/?36831" rel="nofollow">grep</a> with its default settings. PuTTY 0.73's changelog refers to gcc.</p>
<p dir="auto">Notes We (VTE) haven't received any bugreport about it, nor did I saw one in Kitty's, Konsole's or iTerm2's bugtracker. Also there's no vttest test case for this.</p>
<p dir="auto">I do recommend that you follow our behavior here. :)</p>
<h1 dir="auto">Actual behavior</h1>
<p dir="auto">The last digit <code class="notranslate">9</code> is wiped out by EL for no apparent reason since the "delayed eol wrap" state isn't cleared, the first letter <code class="notranslate">a</code> is printed in the next line anyway:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="          012345678 ▏
abcdef              ▏"><pre class="notranslate"><code class="notranslate">          012345678 ▏
abcdef              ▏
</code></pre></div>
<p dir="auto">Or, at 38 columns:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="echo 'The quick brown fox jumps over the lazy dog.' | GREP_COLORS='ms=1;91' grep z

The quick brown fox jumps over the la ▏
y dog.                                ▏"><pre class="notranslate"><code class="notranslate">echo 'The quick brown fox jumps over the lazy dog.' | GREP_COLORS='ms=1;91' grep z

The quick brown fox jumps over the la ▏
y dog.                                ▏
</code></pre></div>