bugGNU nano - Bugs: bug #49440, double-width characters are not...

 
 

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

bug #49440: double-width characters are not shown when they don't fit

Submitter:  Benno Schulenberg <bens>
Submitted:  Tue 25 Oct 2016 03:56:11 PM UTC
   
 
Severity:  4 - Important Status:  Fixed
Assigned to:  dolorous Open/Closed:  Closed

Jump to the original submission

Tue 11 Jul 2017 08:36:58 PM UTC, comment #8: 

Yes.

David Lawrence Ramsey <dolorous>
Group Member
Tue 11 Jul 2017 05:44:00 PM UTC, comment #7: 

Ah, forgot this one.  In the commit messages it says that 8490f4ac fixes this bug, which is basically right, I think?

Benno Schulenberg <bens>
Group administrator
Tue 11 Jul 2017 03:51:35 PM UTC, comment #6: 

Hasn't the variable-width softwrap overhaul in nano's upcoming version 2.8.6 fixed the rest of this bug?

Since commit aa04ad4, nano breaks softwrapped lines before double-width characters at the edge of the screen.  Also, since commit bb4d0d54, nano breaks softwrapped lines before double-width characters at whitespace at or before the edge of the screen.  So, in short, nano no longer attempts to break double-width characters if they actually can't be broken across rows.

David Lawrence Ramsey <dolorous>
Group Member
Mon 03 Apr 2017 07:58:31 PM UTC, comment #5: 

Yes, I like that mitigation -- showing > and < is better than leaving them just as blanks.  Patch is in git, c3830517.  Thanks.

Benno Schulenberg <bens>
Group administrator
Sun 02 Apr 2017 09:54:53 PM UTC, comment #4: 

What about displaying '<' for the left half of a double-width character and '>' for the right in display_string()?  This would be clearer than putting blank spaces before the "$" token.  (Obviously, doing this is much more useful in non-softwrap mode at the moment.)

The attached patch against current git adds this.

(file #40237)

David Lawrence Ramsey <dolorous>
Group Member
Fri 10 Mar 2017 09:07:38 PM UTC, comment #3: 

Attached is a proposed patch for the original issue with softwrap "hiding" double-width characters that straddle a row boundary.

(file #39969)

Benno Schulenberg <bens>
Group administrator
Fri 17 Feb 2017 11:17:13 AM UTC, comment #2: 

Thanks reporting this other issue.  I have rereported it as a separate bug, though: bug #50335.  I want to reserve the current bug for double-width characters that get hidden because their right half is offscreen at the right edge.

Benno Schulenberg <bens>
Group administrator
Fri 17 Feb 2017 07:41:42 AM UTC, comment #1: 

I've found another issue (neither of the two given here, but it falls under the category of double-width characters' sometimes not being shown).

Using an 80x24 terminal, run

nano --ignore chinese.html

Then do the following.

1. Press ^W to get the "Search" prompt.

2. Press Meta-B to toggle backwards searches.

3. Search for "<br>".

4. Press Meta-W to search for "<br>" a second time.  Note that this second match is bracketed on either side by two-column characters,

5. Press Meta-$ to toggle softwrap mode.  Note that the "<br>" is now on the right edge of the screen, the two-column character to its left is still there, and the two-column character to its right is on the next line (or would be if it wasn't displayed as blanks).

You can verify that the two-column character on the right isn't gone, only misdisplayed, by pressing Space.  Since the cursor should still be on the first character of "<br>", that will shift it forward, and the character will reappear.

This problem is caused by an oversight with regards to display_string() and softwrap mode, triggered by having a two-column character start exactly at the beginning of a row of a softwrapped line other than the first.  The code to add a "$" to the end or beginning of overlong lines is only supposed to be used when we're not in softwrap mode, and properly makes sure of that.  The first place where this is referenced is at the very beginning of display_string(): winio.c, starting at line 1814:

    /* If this is data, make room for the "$" at the end of the line. */
    if (isdata && !ISSET(SOFTWRAP) && strlenpt(buf) > start_col + span)
        span--;

However, there's a second instance later that assumes we're adding a "$" to the beginning of the line, that wasn't updated for softwrap mode: winio.c, starting at line 1835:

    if (*buf != '\0' && *buf != '\t' &&
        (column < start_col || (isdata && column > 0))) {
        /* We don't display the complete first character as it starts to
         the left of the screen. /

The next if/else block after this, which handles two-column characters, assumes that we've added a "$" as the first column of the overlong line (even in softwrap mode).  Thus, it tries to display a space over half the character since it can't display half a character, and ends up displaying two spaces insstead of the full character at the beginning of the line.

The attached patch fixes this by checking for softwrap mode in the second case, and makes the missing character in the test case appear properly.

(file #39770)

David Lawrence Ramsey <dolorous>
Group Member
Tue 25 Oct 2016 03:56:11 PM UTC, original submission:  

To reproduce, download the attached file, and run 'stty cols 49 && src/nano +2,49 --soft chinese.html'.  See how the cursor seems to be on a space and how the next screen line seems to begin with a space.  But toggling M-P does not show a middot in those places -- so there is something else than whitespace there.  Now type an x, and see how the character 有 appears at the start of the next screen line, underneath the cursor -- so that is the character that the cursor was sitting on but that couldn't be shown because it requires two columns to be displayed.  Also see how at the end of the same screen line, the character 色 has disappeared -- because it is now "split" over two screen lines and thus cannot be displayed.

To be fair, also without softwrap double-width characters are sometimes not shown.  Run for example "stty cols 50 && src/nano +2,50 chinese.html', and see how the cursor seems to be sitting on a space, but when you type an x, it results that the cursor was in fact sitting on 有.  This is problematic when the user thinks that the cursor was really sitting on a space and presses Delete, and thus unknowingly deletes the 有 character.  Not good.

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 14 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-07-22 bens Open/ClosedOpen Closed
    2017-07-11 bens StatusNone Fixed
        Assigned toNone dolorous
    2017-04-02 dolorous Attached File- Added 0001-display-show-and-placeholders-for-split-two-column-U.patch, #40237
    2017-03-16 bens StatusIn Progress None
        Assigned tobens None
    2017-03-10 bens Attached File- Added 0001-softwrap-shrink-the-screen-by-one-column-to-keep-wid.patch, #39969
        StatusNone In Progress
        Assigned toNone bens
    2017-02-17 bens Summarydouble-width characters are sometimes not shown double-width characters are not shown when they don't fit
    2017-02-17 dolorous Attached File- Added 0001-display-display-two-column-characters-properly-in-so.patch, #39770
    2017-01-11 bens Severity3 - Normal 4 - Important
        Summarywith softwrap, double-width characters are sometimes not shown double-width characters are sometimes not shown
    2016-10-25 bens Attached File- Added chinese.html, #38807

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code