Escaped numbers in brackets cause incorrect WordWrap #23

New Issue

2020-06-14T21:21:56Z

makeworld-the-better-one commented

2020-06-14 21:21:56 +00:00

(Migrated from gitlab.com)

Here's an example line:

Donec vitae elit urna. Nulla facilisi[1][2] Morbi massa nibh, faucibus tristique vulputate vel, blandit a dolor. Praesent nec vehicula arcu. Vestibulum vel egestas mauris. Vivamus tincidunt tempus ipsum ore mollis. Pellentesque et mollis tellus. Nunc sed posuere enim. Morbi non sem porttitor, ultricies lectus sit amet, hendrerit risus. Nam ultricies dui et dolor pretium, gravida sollicitudin enim luctus. Duis aliquam nibh arcu, congue efficitur metus euismod in. Ut nec purus eleifend, pharetra sapien a, ullamcorper metus. Maecenas vehicula venenatis velit, non aliquet libero volutpat a. Morbi ac luctus elit, in consectetur neque. Aliquam consequat placerat odio vel condimentum. Praesent semper placerat cursus.

If you use cview.WordWrap, a newline is inserted at the first space before the numbers, so facilisi[1][2] starts the new line, even though it hasn't hit the max number of columns. Empty brackets ([][]) do not cause the issue.

The bracketed numbers alone still cause the issue: ...urna. Nulla facilisi [1][2] Morbi massa nibh, fauc...

Removing the space to the right fixes the issue: ...urna. Nulla facilisi [1][2]Morbi massa nibh, fauc...

The issue still occurs with spacing and words between the numbers: Nulla facilisi[2] example[1] Morbi massa nibh, faucibus, with the newline starting right before example[1].

Please note that cview.Escape was used before wrapping, and all the examples above show the brackets how they are displayed and were typed, not how they are represented internally by cview.

Here's an example line: ``` Donec vitae elit urna. Nulla facilisi[1][2] Morbi massa nibh, faucibus tristique vulputate vel, blandit a dolor. Praesent nec vehicula arcu. Vestibulum vel egestas mauris. Vivamus tincidunt tempus ipsum ore mollis. Pellentesque et mollis tellus. Nunc sed posuere enim. Morbi non sem porttitor, ultricies lectus sit amet, hendrerit risus. Nam ultricies dui et dolor pretium, gravida sollicitudin enim luctus. Duis aliquam nibh arcu, congue efficitur metus euismod in. Ut nec purus eleifend, pharetra sapien a, ullamcorper metus. Maecenas vehicula venenatis velit, non aliquet libero volutpat a. Morbi ac luctus elit, in consectetur neque. Aliquam consequat placerat odio vel condimentum. Praesent semper placerat cursus. ``` If you use `cview.WordWrap`, a newline is inserted at the first space before the numbers, so `facilisi[1][2]` starts the new line, even though it hasn't hit the max number of columns. Empty brackets (`[][]`) do not cause the issue. The bracketed numbers alone still cause the issue: `...urna. Nulla facilisi [1][2] Morbi massa nibh, fauc...` Removing the space to the right fixes the issue: `...urna. Nulla facilisi [1][2]Morbi massa nibh, fauc...` The issue still occurs with spacing and words between the numbers: `Nulla facilisi[2] example[1] Morbi massa nibh, faucibus`, with the newline starting right before `example[1]`. Please note that `cview.Escape` was used before wrapping, and all the examples above show the brackets how they are displayed and were typed, not how they are represented internally by cview.

makeworld-the-better-one commented

2020-06-29 16:49:27 +00:00

(Migrated from gitlab.com)

I've also had this happen with escaped words in brackets as well. Do have an idea what's causing it? Is it some error in the system that tries to skip over style tags?

makeworld-the-better-one commented

2020-06-29 17:14:13 +00:00

(Migrated from gitlab.com)

mentioned in issue #27

tslocum commented

2020-11-03 18:36:48 +00:00

(Migrated from gitlab.com)

WordWrap does not seem to have been intended for use with escaped text. I've just added TextView.SetWrapWidth so that no text manipulation is required.

`WordWrap` does not seem to have been intended for use with escaped text. I've just added `TextView.SetWrapWidth` so that no text manipulation is required.

makeworld-the-better-one commented

2020-11-03 18:45:04 +00:00

(Migrated from gitlab.com)

I'm not sure I agree with this, but we can talk further in #27. Thank you.

Sign in to join this conversation.