bugGNU nano - Bugs: bug #55620, the prompt bar mishandles...

 
 

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

bug #55620: the prompt bar mishandles two-column characters at the screen edge

Submitted by:  David Lawrence Ramsey <dolorous>
Submitted on:  Thu 31 Jan 2019 10:20:11 PM UTC  
 
Severity:  2 - Minor Status:  Fixed
Assigned to:  Benno Schulenberg <bens> Open/Closed:  Closed

( Jump to the original submission)

Sun 10 Feb 2019 09:21:23 AM UTC, comment #14: 

The regression has been reported in bug #55680.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 08 Feb 2019 04:55:49 PM UTC, comment #13: 

Please report the regression as a new bug, and crossreference it here.

Another mishandling of double-width characters I've reported as bug #55679.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Fri 08 Feb 2019 04:00:13 AM UTC, comment #12: 

Check that: it affects both spotlight_softwrapped() and spotlight(), since they both call display_string() with isdata set to FALSE, just as the prompt bar does.

David Lawrence Ramsey <dolorous>
Project Member
Fri 08 Feb 2019 03:49:54 AM UTC, comment #11: 

Unfortunately, with more testing, I just found one problem it causes.

The check you added to display_string() to determine whether it's in the prompt bar and should trim the final character isn't quite right.  It also affects spotlight(); if you do a search and replace of text, that check makes the highlighted text one character shorter than it should be.

David Lawrence Ramsey <dolorous>
Project Member
Thu 07 Feb 2019 08:00:53 PM UTC, comment #10: 

Fixed in git, commit 56181896.

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Wed 06 Feb 2019 05:44:48 PM UTC, comment #9: 

After some testing, your patch does seem to work.

David Lawrence Ramsey <dolorous>
Project Member
Wed 06 Feb 2019 02:07:38 PM UTC, comment #8: 

The 0001 patch does appear to fix the overflow problem, but... it introduces a small other problem (apart from the ^J/^@ diplay issue).  To reproduce, run the patched version, then type:

  ^W ... M-V 0 0 3 1 1 3 <Home>

Then type as many spaces or exes as needed to put the cactus at the screen's edge.  Then type <End>.  See that after the prompt it shows "< <".  The first "<" means that there is more answer to the left, and the second "<" that this is the right half of a double-width character.  This is not right.  Instead of " <" it should show the cactus character itself: "ㄓ".

Also, the stashing and restoring of the value of SOFTWRAP involves several #ifndefs, which makes the patch somewhat ugly.  So I've come up with an alternative patch, that avoids setting 'isdata' to TRUE and thus avoids both the representation issue and the " <" issue.  See attached.

(Please forget about the other patches for now.  They are just tweaks and not relevant for the bug at hand.)

(file #46191)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Wed 06 Feb 2019 12:30:43 AM UTC, comment #7: 

I mean, aside from the ^J/^@ display issue, the problem seems to be gone.

David Lawrence Ramsey <dolorous>
Project Member
Tue 05 Feb 2019 05:57:53 PM UTC, comment #6: 

Attached new versions of the patches; 0001 and 0004 are the only changed ones.  If you apply the experimental patch from bug #55638 first, and then these patches, the problem seems to be gone, at least in my testing so far.

(file #46182, file #46183, file #46184, file #46185)

David Lawrence Ramsey <dolorous>
Project Member
Tue 05 Feb 2019 07:19:25 AM UTC, comment #5: 

Bug #55638 does seem to be related to this bug.  If I apply the experimental patch from there, the behavior does improve, although it still isn't perfect.

David Lawrence Ramsey <dolorous>
Project Member
Mon 04 Feb 2019 08:49:10 AM UTC, comment #4: 

Thanks.  Your patch fixes the specific overflow of your reproduction recipe, but... does not fix the overflow in general.  For example, follow your recipe until the two-column character has just "jumped" to the next chunk and the answer at the prompt looks like this: "<xだ".  Then press <Left>, and see  how "だ>" has oveflowed into the first help line.

There is another (probably related) problem in the edit window itself -- see bug #55638.

Also, setting 'isdata' to TRUE makes that typing ^J (M-V ^J) at the ^O or ^R prompt makes the ^J appear as ^@.  (Of course, having a newline in a filename is absurd, so I'm willing to ignore this tiny representation problem while the overflowing problem gets fixed.)

Benno Schulenberg <bens>
Project AdministratorIn charge of this item.
Thu 31 Jan 2019 10:42:26 PM UTC, comment #3: 

Also, Pico's status bar prompt doesn't draw scrolling characters for the prompt text if the text is exactly the width of the screen, either.

David Lawrence Ramsey <dolorous>
Project Member
Thu 31 Jan 2019 10:35:25 PM UTC, comment #2: 

Check that: the second paragraph should start with

"The first patch makes draw_the_promptbar() use display_string() with isdata set to TRUE to display the prompt text".

draw_the_promptbar() was using display_string() before, but its attempt to manually do what the isdata parameter was supposed to do was incorrect.

David Lawrence Ramsey <dolorous>
Project Member
Thu 31 Jan 2019 10:31:24 PM UTC, comment #1: 

The attached patches should fix this.  (Only the first is the actual fix; the others are cleanups.)  The existing code in draw_the_promptbar() attempts to reserve space for scrolling characters, but it does so incorrectly.

The first patch makes draw_the_promptbar() use display_string() to display the prompt text (manually switching off softwrap, since it doesn't apply to the prompt).  One side effect of this is that nano will no longer draw scrolling characters for the prompt text if the text is exactly the width of the screen.  I couldn't figure out how to decouple this behavior change from the bug fix, but it now matches the behavior of the edit window (except for using '<' and '>' instead of '$').

The remaining patches tweak things so that variables are assigned earlier and/or used to avoid recalculating the same things multiple times.  All the calls to strlenpt() can get expensive, but it's a simple matter to save their values, since they don't change in this function.

(file #46147, file #46148, file #46149, file #46150)

David Lawrence Ramsey <dolorous>
Project Member
Thu 31 Jan 2019 10:20:11 PM UTC, original submission:  

Currently, in git b895402, nano behaves incorrectly when the prompt text contains multi-column characters.  This can be reproduced as follows:

1. In an 80x24 terminal, in a UTF-8 locale, run nano with UTF-8 support enabled.

2. In the empty buffer, type ^W to get to a search prompt.

3. At the search prompt, press

M-V 0 0 3 0 6 0

to type the two-column Unicode character U+3060.

4. Press Home to put the cursor back at the beginning of the prompt text.

5. Press the "x" key until the Unicode character after all the "x"s reaches the edge of the screen.  The prompt will be erroneously split and drawn over two rows.

David Lawrence Ramsey <dolorous>
Project Member

 

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 dolorous
  • -email is unavailable- added by dolorous (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.

     

     

     

    Follow 16 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-03-25 bens Open/ClosedOpen => Closed
    2019-02-07 bens StatusIn Progress => Fixed
        Assigned toNone => bens
    2019-02-06 bens Attached File- => Added 0001-prompt-trim-a-double-width-character-at-the-screen-s.patch, #46191
        Severity3 - Normal => 2 - Minor
        StatusNone => In Progress
        Summarythe status bar prompt mishandles multi-column characters at the screen edge => the prompt bar mishandles two-column characters at the screen edge
    2019-02-05 dolorous Attached File- => Added 0001-prompt-fix-mishandling-of-multi-column-characters-wh.patch, #46182
        Attached File- => Added 0002-tweaks-calculate-a-variable-earlier-and-reuse-it.patch, #46183
        Attached File- => Added 0003-tweaks-reuse-another-variable.patch, #46184
        Attached File- => Added 0004-tweaks-use-another-variable-instead-of-calculating-t.patch, #46185
    2019-01-31 dolorous Attached File- => Added 0001-prompt-fix-mishandling-of-multi-column-characters-wh.patch, #46147
        Attached File- => Added 0002-tweaks-calculate-a-variable-earlier-and-reuse-it.patch, #46148
        Attached File- => Added 0003-tweaks-reuse-another-variable.patch, #46149
        Attached File- => Added 0004-tweaks-use-another-variable-instead-of-calculating-t.patch, #46150
        Carbon-Copy- => Added bens

    Back to the top


    Powered by Savane 3.5