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

 
 

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

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

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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

Released in 2.9.4.

Benno Schulenberg <bens>
Project 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>
Project 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>
Project AdministratorIn charge of this item.
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>
Project Administrator

 

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

Attach Files:
   
   
Comment:
   

 

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)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    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.3