bugGNU nano - Bugs: bug #52956, tabs and spaces are not treated...

 
 

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

bug #52956: tabs and spaces are not treated equally when hard-wrapping

Submitter:  Benno Schulenberg <bens>
Submitted:  Mon 22 Jan 2018 08:50:17 PM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  dolorous Open/Closed:  Closed

Fri 09 Mar 2018 10:16:26 AM UTC, comment #3: 

Released in 2.9.4.

Benno Schulenberg <bens>
Group administrator
Thu 08 Feb 2018 04:44:52 PM UTC, comment #2: 

Thanks for looking into this, and for the patch.

Applied with minor edits, and pushed, commit 7a038adf.

Benno Schulenberg <bens>
Group administrator
Wed 07 Feb 2018 03:30:19 AM UTC, comment #1: 

There's also another inconsistency.  Following your instructions, after typing "abc", instead of pressing Space or Tab, try inserting a space using verbatim input (Meta V 0 0 0 0 2 0); prepending won't work properly then either.

I've looked into this, and I know why it's happening.  The problem is caused by do_input(), nano.c lines 1775-1777 in current git (d865d7a):

           /* If the cursor moved to another line, clear the prepend flag. */
            if (openfile->current->next != was_next)
                wrap_reset();

This piece of code is only run if the user presses a shortcut instead of text.  Since no ASCII control characters are considered text, this also gets run when the user presses Tab.  So, even though calling either do_tab() or do_verbatim_input() will add text, prepending gets reset for them.  Also, the current behavior for do_verbatim_input() is a regression added in commit 29f7654a, when the exception for do_verbatim_input() was removed.

I've attached a patch that fixes this, albeit crudely, for do_tab() and do_verbatim_input(); it's against current git.  There's probably a better approach, but it matches similar code below exempting do_delete() and do_backspace().

(file #43197)

David Lawrence Ramsey <dolorous>
Group Member
Mon 22 Jan 2018 08:50:17 PM UTC, original submission:  

To reproduce, first do:

  echo -n "1234567890123456789012345678901234567890123456789012 x " >oneline
  echo -n " 1234567890123" >>oneline

Then run:

  nano  --fill=72  +1,56  oneline

And type: abc <Space> aaaaa <Space> bbbbb <Space> cccc.
Note that the "ccccc" gets pushed to the next line, in front of the "1234567890123" that got pushed earlier.

Exit nano without saving and run the same command again, but now type a tab instead of the first space: abc <Tab> aaaaa <Space> bbbbb <Space> cccc.
Note how the "ccccc" gets pushed to a new line, before the "123..." one.  Weird!  Why does this tab cause nano to think that the "123..." is not a previously hard-wrapped line?

Benno Schulenberg <bens>
Group administrator

 

(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 dolorous (Updated the item)
  • -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.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-09 bens Open/ClosedOpen Closed
    2018-02-08 bens StatusNone Fixed
        Assigned toNone dolorous
    2018-02-07 dolorous Attached File- Added 0001-input-don-t-stop-prepending-when-the-user-adds-text-.patch, #43197

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code