Rendering error, cursor moves below the text as you type.

[David-Else]

Summary

When in a Markdown document with softwrap on, at the bottom of the document the cursor jumped to the line below and followed along with the typing.

When pressing enter and writing on the next line, the cursor jumped two lines below and followed along with the typing.

Eventually it fixed itself.

[[language]]
name = "markdown"
max-line-length = 80

[editor.soft-wrap]
enable = true

[editor.cursor-shape]
insert = "bar" # change cursor shape in insert mode

[editor.whitespace.render]
newline = "all"

[editor.whitespace.characters]
newline = "⏎"

Reproduction Steps

Sorry, can't find reproduction steps, but it happened the first day of use after the softwrap update so I am sure it is from that @pascalkuthe .

Helix log

No response

Platform

Linux

Terminal Emulator

Kitty

Helix Version

helix 22.12 (71a544b)

[pascalkuthe]

This is actually looks like a bug I fixed in the softwrap branch a while ago. I can't reproduce this on master but from the helix version you posted it looks like you are still using a 2 weeks old version of the softwrap branch and not the version that actually got merged.

I tried really hard to reproduce this and I am fairly certain my fix for this was correct. I personally use almost the exact same settings and haven't noticed this problem ever since I fixed this bug.

If you find any file for which this problem occurs on master, I would highly appreciate if you could upload a copy.

[David-Else]

I don't see how it is an old branch as I only did a git pull yesterday and was using a new feature that was only just merged: #4571 . I checked again and got:

hx --version
helix 22.12 (71a544b5)

but I am on the master branch:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
[david@xxx helix]$ git branch
  icons
* master

So I updated, pulling in the one new commit that has appeared, here is the output:

$ git pull
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 5 (delta 1), reused 3 (delta 1), pack-reused 0
Unpacking objects: 100% (5/5), 4.08 KiB | 1.02 MiB/s, done.
From https://github.com/helix-editor/helix
   685cd383..62d046fa  master     -> origin/master
Updating 685cd383..62d046fa
Fast-forward
 helix-core/src/shellwords.rs | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)
 ...
$ cargo install --locked --path helix-term
 ...
    Finished release [optimized] target(s) in 1m 14s
   Replacing /home/david/.cargo/bin/hx
    Replaced package `helix-term v0.6.0 (/home/david/src/helix/helix-term)` with `helix-term v0.6.0 (/home/david/src/helix/helix-term)` (executable `hx`)

[david@xxx helix]$ hx --version
helix 22.12 (71a544b5)

It still says Helix is on the same commit even after an update... makes no sense, I am probably doing something wrong.

[pascalkuthe]

Thanks for checking @David-Else. Sorry about that I got confused by the old commit hash in your bug report. I think that's actually a separate (unrelated) bug with the way helix calculates the ouput of --version. I think cargo doesn't rerun the relevant buildscript automatically. A cargo clean would fix that. I think the issue is that we do the rev-parse in helix-loader. This probably needs to be a proc macro like this crate instead a buildscript inside helix-term (that crate always gets rebuild) to ensure the revision is always fresh.

@aukeroorda managed to find a reproduction case for this bug (or a related issue): https://dpaste.org/7QrA9/raw](https://dpaste.org/7QrA9/raw. However the issue only happens for me when the view is scrolled far enough down so only softwrapped lines appear at the top (basically only the line is visible on screen and cutoff at the top).

I am not sure why this appears for you @David-Else as that doesn't seem to be the case in the example you posted. I will start with fixing the case I can reproduce and as the problem is related to the same 10 loc or so I hope/assume that this will also fix the case you reported

[David-Else]

Glad I am not going mad, I am having a bad day with Git!

However the issue only happens for me when the view is scrolled far enough down so only softwrapped lines appear at the top (basically only the line is visible on screen and cutoff at the top).

In my example I was scrolled all the way down to the bottom on the screen, I don't quite follow the rest of your explanation, but I bet it is the same bug, so, hurray!

I think that's actually a separate (unrelated) bug with the way helix calculates the ouput of --version
A cargo clean would fix that.

Maybe add cargo clean to the docs to avoid messing up future bug reports?

[pascalkuthe]

#5786 should fix this issue. At least the reproduction case works fine now and the code is relatively simple (I just forgot to subtract an offset in the special case for EOF) so I think/hope that there isn't a second bug there. You could give it a spin @David-Else to see if that fixes the issue for you since I am still not 100% sure if you issue is the same one as the reproduction case.