Wrong line numbers

[antoyo]

When opening this file, I have the wrong line numbers.

Reproduction steps

Open the above file and type 11081G and you'll end up on line 11063 even though it shows 11081 in helix.

Environment

• Platform: Linux
• Terminal emulator: Alacritty
• Helix version: helix v0.6.0

[tomKPZ]

Looks like the first inconsistency is around the 2 blank lines L104-L105 which helix renders as 3 empty lines. If I press j/k repeatedly around those lines, I can get the editor to hang.

[tomKPZ]

The bytes for those lines are 0a 0a 0c 0a, so 3 newlines and a form feed.

[kirawi]

@cessen Do you have an idea of what could be happening here?

[kirawi]

Can you compare to what other editors report?

[cessen]

Looks like the first inconsistency is around the 2 blank lines L104-L105 which helix renders as 3 empty lines.

I think Helix is actually rendering this correctly...? The form feed character (0x0c) is an explicit page break, which implies a line break as well. So the sequence 0a 0a 0c 0a is a series of four line breaks (one of which also happens to be a page break), resulting in three blank lines.

Having said that, none of the other editors I've opened this file with (emacs, vim, sublime) render it that way. So it's possible I misinterpreted the Unicode spec when implementing line breaks in Ropey. But it seems pretty clear to me (under the "mandatory break" section):

FORM FEED separates pages. The text on the new page starts at the beginning of the line. In some layout modes there may be no visible advance to a new “page”.

[archseer]

I think the problem is that very few editors actually conform to the spec and only accept CR/CRLF (an example being the LSP spec only treating those two as line endings as well).

Ropey is more correct here, but it might be nice to put the additional line endings under a feature flag. That way we could only treat CR/CRLF as line endings, then render the others with a special mark to indicate them -- if I'm editing code then I don't really expect any other line endings, and if they do appear it's usually a bug.

[antoyo]

The thing is: a failed assertion in GCC will output the line number and if I want to go to this line number easily, and helix print the line numbers correctly while every other piece of software is wrong, it makes it harder to go to this line number.

[cessen]

but it might be nice to put the additional line endings under a feature flag. That way we could only treat CR/CRLF as line endings, then render the others with a special mark to indicate them

That's a great idea. I'll put that on my to-do list for Ropey. I'll also happily accept a PR if someone else gets to it first. I believe it would just involve making alternative versions of the line-related str_utils functions.

[cessen]

I've made an issue on the Ropey repo for this.