bugGNU nano - Bugs: bug #31743, nano 2.2.5 doesn't display the...

 
 

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

bug #31743: nano 2.2.5 doesn't display the first UTF-8 character in a line

Submitter:  Andreas Klauer <aklauer>
Submitted:  Thu 02 Dec 2010 12:34:10 PM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Wed 14 May 2014 01:48:40 PM UTC, comment #5: 

The workaround was merged into SVN, r4879.

Benno Schulenberg <bens>
Group administrator
Mon 24 Feb 2014 07:45:01 PM UTC, comment #4: 

Tested the patch. It seems to help. Thank you!

Andreas Klauer <aklauer>
Fri 27 Sep 2013 03:45:10 PM UTC, comment #3: 

Adding several debugging lines, it became clear that nano was giving the exact same commands to the terminal, but now and then getting different display behaviour.  Trying to "disturb" the malfunctioning screen logic by poking something into it before redisplaying the line didn't work.  But poking it afterward did.  First I used stars, but then found an "invisible" character.  Now it came in handy that nano doesn't use the last column of the screen -- while scratching away on this bug I became convinced that nano was wasting this last column, but now... maybe it was even done on purpose.

Patch #8188 "solves" the issue for me.  If you can, please verify.

Benno Schulenberg <bens>
Group administrator
Fri 27 Sep 2013 08:56:49 AM UTC, comment #2: 

With the attached demonstration file (adjust the length of the lines so that they are just one character shorter than the TTY width, meaning that when the cursor is at the end of the line, the line will have just horizontally scrolled, and a single <left> will scroll the line horizontally back) I get weird behaviour.

Move the cursor down to the start of the second long line, the one that start with the wide Japanese character.  Then do <end>, <home>.  Notice how the line is now misaligned: the Japanese character gets treated as if it's only one position wide, and thus gets overlapped by the 2.

Now type a letter, say <w>.  Notice how the pattern of dashes and equal signs gets broken.  It is impossible that nano does this!  I've disabled the colouring code, nano simply repaints the line, and what it gets is this!

Do a <backspace>; the mistaken pattern gets dragged to the left.  Do an <end>; notice how the tail is displayed correctly.  Do a <home> (Japanese character gets overlapped), and an <end>.  Now the tail gets displayed wrong: one character "too late", and the cursor seems to be one position beyond the end of the line, but is in fact in the correct position if the characters were displayed correctly.

Now do an <up>.  Also the tail of the first long line, which doesn't contain any wide character, gets displayed wrong!  Do another <up>, then a <down>.  The tail gets displayed fine.  Another <down>, and also the tail of the problematic line gets displayed fine.  Another <down>: the problematic line gets shown in its overlapped form.  Now do a <delete>, so that there is only one blank line left between the first two long lines and the last.  Then do a <back> to get to the end of the problematic line, the tail being displayed wrong.  Then do an <up>.  Now the tail of the first long line gets displayed correctly!  This is absurd!  How can a line that is three lines further down have any influence on the display of this line!?  I don't think this is nano; this is the terminal or ncurses or whatever, but not nano.

There is some related weird behaviour that I can reproduce in a virtual console (Ctrl+Alt+F5), but not in a Gnome Terminal -- but when I first saw it it was the other way around.  Go to a VC, open the demonstration file, adjust the line lengths so that they just fit the screen.  Then do an <end>, <home>, <end> on the problematic line; tail is displayed wrong.  Do an <up>; like before, tail is also displayed wrong.  Another <up>.  Now the head of the first long line gets displayed here as "023456 7", instead of the correct "01234567".  Flummoxed.  This is not nano.

(file #29242)

Benno Schulenberg <bens>
Group administrator
Tue 24 Sep 2013 09:03:18 PM UTC, comment #1: 

Confirmed, and still present in SVN.  Although the effect I see (on a Gnome virtual terminal) is a little different: the "curl" stays visible but gets half-covered by the "2".

This "curl" is somehow a wide character: at first it takes up two horizontal positions.  But upon redisplay of the line, after having been horizontally scrolled, it gets displayed with a width of one position.  However, when placing the cursor, nano does know that the character takes up two positions: when at the beginning of that line and doing one cursor-right, the cursor seems to be on the three, but when you press Delete and then q, you see that the two has disappeared -- but then at the end a space seems to have appeared...  Nano is definitely confused.  Only after scrolling the line off the screen and then back, does it get redisplayed correctly.

(On a virtual console the behaviour is the same, except that the "curl" gets displayed as a diamond here.)

Benno Schulenberg <bens>
Group administrator
Thu 02 Dec 2010 12:34:10 PM UTC, original submission:  

Originally submitted Mi 24 Nov 2010 20:41:52 GMT as bug 31761 it seems this bug report was lost due to "all user passwords in the system have been reset and we've reverted Savannah to its backup from Nov 23rd." I'm therefore resubmitting it.

    _____________________________________________________

Details:

I'm using nano for some mixed Japanese / English / German files; encoded
UTF-8.

In --nowrap mode, when a line just barely fits the screen (displayed
completely as [line with something]), when you move the cursor to the end of
the line it scrolls (displayed as [$something ]), and when you go into the
next line, the previous line is redrawn but with the first character
missing/empty (displayed as [ ine with something]).

The line I tested this with is:

の2345678901234567890... (filled up until it fits the screen)

Illustrated with screenshot.



    _____________________________________________________

Andreas Klauer <aklauer>

 

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

Attached Files
file #29242:  nettles added by bens (379B - application/octet-stream - demonstration file with three long lines and one wide character)
file #22088:  nanoutf8.png added by aklauer (9KiB - image/png - first utf-8 character not displayed illustration)

 

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 aklauer (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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-05-14 bens StatusNone Fixed
        Assigned toNone bens
        Open/ClosedOpen Closed
    2013-09-27 bens Attached File- Added nettles, #29242
    2010-12-02 aklauer Attached File- Added nanoutf8.png, #22088

    Back to the top

    Powered by Savane 3.13-3230.
    Corresponding source code