bugGNU nano - Bugs: bug #57422, text can disappear when automatic...


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

bug #57422: text can disappear when automatic hard-wrapping occurs

Submitted by:  Benno Schulenberg <bens>
Submitted on:  Mon 16 Dec 2019 09:42:53 AM UTC
Severity:  4 - Important Status:  Fixed
Assigned to:  bens Open/Closed:  Closed
* Mandatory Fields

Add a New Comment (Rich Markup)

Comment Type & Canned Response:


( Jump to the original submission )

Tue 24 Dec 2019 09:15:05 AM UTC, comment #9: 

The fix has been released in 4.7.

Benno Schulenberg <bens>
Project Administrator
Wed 18 Dec 2019 10:52:36 AM UTC, comment #8: 

Fixed in git, as a side effect of fixing bug #57425.

Benno Schulenberg <bens>
Project Administrator
Tue 17 Dec 2019 10:17:05 AM UTC, comment #7: 

(In comment #5 I was under the delusion that the character that the user typed was inserted somewhere in the middle of do_wrap().  But that is of course not the case.  The character was inserted earlier and has triggered a call of do_wrap() to see if the line needs to be rewrapped and do so when needed.  So, the 'lead_len += ...' thing is fine and correct.)

Benno Schulenberg <bens>
Project Administrator
Mon 16 Dec 2019 03:34:47 PM UTC, comment #6: 

In fact, wrapping the whole "#what word word" to the start of the next line is the wrong thing to do.  Nano should never wrap in leading whitespace, whether or not --autoindent is in effect.  Because doing such wrapping makes it impossible to indent words that by themselves (plus their leading whitespace) exceed the wrapping width.  This is what bug #57425 is about.  And when that bug is fixed, this bug is automatically avoided, because the quoting part will always still be present on the original line.

Benno Schulenberg <bens>
Project Administrator
Mon 16 Dec 2019 01:20:24 PM UTC, comment #5: 

Also the 'lead_len += indent_length(line->data + lead_len)' is wrong: it assumes that the 'lead_len' characters of 'line' are still the original characters that were counted by quote_length().  But when typing something anywhere near the start of the line (as in the given recipe), this will not be the case.

(By the way, see bug #57425 for a related bug.  It is much older, though, and should probably be fixed first.)

Benno Schulenberg <bens>
Project Administrator
Mon 16 Dec 2019 11:07:05 AM UTC, comment #4: 

The quote-copying code was written with the assumption that automatic hardwrap would occur while the user was typing somewhere near the end of the line, and that the quoting part of that line would still be present on that line after it was hardwrapped.  Also, it kind of tries to implement automatic indentation (when the quotestr includes leading whitespace) even when autoindent is off.

Benno Schulenberg <bens>
Project Administrator
Mon 16 Dec 2019 10:48:14 AM UTC, comment #3: 

The problem is that the 'strncpy(line->data, line->prev->data, lead_len)' assumes that the quoting part is still present on the preceding line.  But in this case, the do_enter() has moved the final character of the quoting part (the "#") to what is now the current line and the strncpy() will copy just the leading whitespace plus the terminating \0.  The latter is what makes the text that was wrapped to the current line disappear.

Benno Schulenberg <bens>
Project Administrator
Mon 16 Dec 2019 10:14:54 AM UTC, comment #2: 

The offending commit is 8fce33af: "copy leading quote characters when automatic hard-wrapping occurs".

Benno Schulenberg <bens>
Project Administrator
Mon 16 Dec 2019 10:03:08 AM UTC, comment #1: 

The bug was introduced in version 4.4.  Version 4.3 and earlier wrap the whole "#what word word" to the start of the next line.

Benno Schulenberg <bens>
Project Administrator
Mon 16 Dec 2019 09:42:53 AM UTC, original submission:  

(Original report by S├ębastien Desreux in https://lists.gnu.org/archive/html/nano-devel/2019-12/msg00020.html -- the essential information is in https://lists.gnu.org/archive/html/nano-devel/2019-12/msg00026.html.)

To reproduce, run the following two commands:

echo "        #what word word"  >oneline
nano --ignore --break --fill=20 --quote="^([[:blank:]]*#)+"  oneline

Then type <Tab>.  See how the three words disappear into oblivion.  Now type M-U.  Some random junk is "restored" instead of the three words.

Benno Schulenberg <bens>
Project Administrator


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

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by bens (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.

    Only logged-in users can vote.





    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-12-24 bens Open/ClosedOpen => Closed
    2019-12-18 bens StatusIn Progress => Fixed
    2019-12-16 bens StatusNone => In Progress
    2019-12-16 bens Assigned toNone => bens

    Back to the top

    Powered by Savane 3.9