Skip to content

Conversation

@matt-phylum
Copy link

Besides the panic with the current implementation, I don't think it's reasonable to try displaying to the user a single line of text over 0xffff bytes long followed by another line with over 0xffff leading space characters. In a terminal or another environment where word wrap is enabled, your display would need to be hundreds of thousands of pixels wide to see the cursor on the second line match the error on the first line.

Instead, I added the column number after the line number, and limited the number of preceding and following bytes to 40.

Taking substrings like this has the potential for new panics related to utf-8, so I also added a test for when the surrounding characters are 3-byte UTF-8 sequences and taking 40 bytes would cause a panic. The test behaves as expected, but demonstrates another problem with the convert_error function: it uses the length of the string in bytes to determine the column number. This won't line up if there are multibyte characters or if there are combining characters or if there are double width characters. Proper handling of multibyte characters would be relatively simple, but IIRC measuring the width of a string in columns is a more complicated problem that would likely involve bringing in a crate specifically for that purpose.

Fixes #1867

@matt-phylum matt-phylum requested a review from Geal as a code owner October 2, 2025 20:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

panic in convert_error for unreasonably long lines

1 participant