bugGNU nano - Bugs: bug #64945, with --atblanks, miswrapping can...


You are not allowed to post comments on this tracker with your current authentication level.

bug #64945: with --atblanks, miswrapping can occur with very long words

Submitter:  Andreas Schamanek <aschamanek>
Submitted:  Wed 29 Nov 2023 03:27:01 PM UTC
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Open

Jump to the original submission

Fri 08 Dec 2023 11:17:54 AM UTC, comment #6: 

Thanks for testing.  The patch has been pushed to master, in commit a76a6bf6.

Benno Schulenberg <bens>
Group administrator
Wed 06 Dec 2023 06:37:40 PM UTC, comment #5: 

I applied the patch (file #55416) and I found no errors, neither with our 2 minimal examples, nor in real-life testing with existing documents.

Thanks a lot Benno!

Andreas Schamanek <aschamanek>
Wed 06 Dec 2023 03:55:08 PM UTC, comment #4: 

More economical patch is attached.

(file #55416)

Benno Schulenberg <bens>
Group administrator
Wed 06 Dec 2023 03:21:49 PM UTC, comment #3: 

The problem is that, when the 3 has been typed, the space after "makesadozen" is exactly at the 'goal_column' (the column just beyond the right edge of the screen) and thus has already been seen by the get_softwrap_breakpoint() routine.  And thus, when this routine is called again for the next chunk, it continues searching for the next breaking point after this space -- which is wrong, of course, when softwrapping at blanks.

So, the right thing to do is to "reset" the current text point that get_softwrap_breakpoint() remembers to the actual breaking point when softwrapping occurs at a blank.  Attached patch does this.  (The implementation is somewhat wasteful, so I'll think about doing this in a better way.)

(The patch should apply without issue to version 7.2.)

(file #55411)

Benno Schulenberg <bens>
Group administrator
Wed 06 Dec 2023 09:56:11 AM UTC, comment #2: 

Transforming the recipe to something that one can copy-paste
(and adding line numbers to make the miswrapping more obvious):

echo -n "one two three four five six seven " >tsf
echo -n "eight nine ten eleven twelve makesadozen " >>tsf
echo -n "andthencomesaverylongwordthatis" >>tsf
echo "probablysomethinglikeacommithashorsimilar" >>tsf
src/nano --ignore --softwrap --atblanks --linenumbers tsf

Start this nano in an 80-column terminal (for example a default xterm), then type: 1 2 3.

See that after typing 3 the "andthencomes..." is placed right after "makesadozen" instead of on a third line by itself.

Now type: 4.  The "andthencomes..." is pushed to the next line, where it should have been anyhow.

Now type: <Bsp>.  The "andthencomes..." moves back to where it was, wrongly, right after "makesadozen".

(This worked correctly before version 6.4, commit 0e9bef34.)

Benno Schulenberg <bens>
Group administrator
Wed 29 Nov 2023 04:36:28 PM UTC, comment #1: 

Thanks for reporting, and especially for the clear reproduction recipe.  I can reproduce the issue.

I have bisected the cause to 0e9bef34: "remember text and column positions when softwrapping a line".  I will have to think about how to fix this.

Benno Schulenberg <bens>
Group administrator
Wed 29 Nov 2023 03:27:01 PM UTC, original submission:  

To (hopefully) reproduce use an 80 columns wide terminal. Start nano with `nano --atblanks` and generate a text with the following words all on 1 line:

foobar foobar foobar foobar foobar foobar foobar foobar foobar looongerword verylongwordorrathertextorwhateverlikeforinstanceweburlsandsuchstuff

Press M-$ for soft line wrapping. The result should be 2 lines with only the "verylong..." word on the 2nd line. Place the cursor at the start of the 1st line and start typing 12345. Once 5 was inserted observe that "looongerword" was correctly wrapped to the 2nd line but the "verylong..." word should actually have been wrapped to a 3rd line but it is still shown in the 2nd line.

Additionally (but this would be a consequence and not the cause): After typing 5 type Cursor-Down several times and observe that the cursor moves to the 2nd line but does not move to the 3rd line.

An ASCII art "screenshot" of my terminal at this stage would be

|12345foobar foobar foobar foobar foobar foobar foobar foobar foobar             |
|looongerword verylongwordorrathertextorwhateverlikeforinstanceweburlsandsuchstuf|
|f                                                                               |

Helpful for debugging might be the observation that the wrapping continues to work as expected once the  1st line is made 1 char longer (e.g. by inserting a 6 after 5):

|123456foobar foobar foobar foobar foobar foobar foobar foobar foobar            |
|looongerword                                                                    |
|verylongwordorrathertextorwhateverlikeforinstanceweburlsandsuchstuff            |
|                                                                                |

Nano 7.2 on Debian GNU Linux with libncursesw6 6.2+20201114-2+deb11u2 using a VTE w/ TERM=xterm, and I also reproduced this in a tmux window w/ TERM=tmux-256color.

Andreas Schamanek <aschamanek>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by aschamanek (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.


    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-12-08 bens StatusReady For Test Fixed
        Summaryatblanks error wrapping lines with very long words with --atblanks, miswrapping can occur with very long words
    2023-12-06 bens Attached File- Added 0001-softwrap-remember-the-actual-breaking-point-when-wra.patch, #55416
        StatusIn Progress Ready For Test
    2023-12-06 bens Attached File- Added move-back-the-text-pointer-to-the-actual-breaking-point.patch, #55411
        StatusNone In Progress
    2023-11-29 bens Assigned toNone bens

    Back to the top

    Powered by Savane 3.13.
    Corresponding source code