GNU nano - Bugs: bug #55679, replacing a double-width character...
You are not allowed to post comments on this tracker with your current authentication level.
bug #55679: replacing a double-width character at window's edge shows an extra continuation character
Submitter: | Benno Schulenberg <bens> | ||
Submitted: | Fri 08 Feb 2019 04:51:10 PM UTC | ||
Severity: | 2 - Minor | Status: | Fixed |
Assigned to: | dolorous | Open/Closed: | Closed |
Jump to the original submission
Fri 08 Mar 2019 07:05:02 PM UTC, comment #30: |
Benno Schulenberg <bens> |
Thu 07 Mar 2019 08:52:02 PM UTC, comment #29: It seems so. Looking at display_string() again, isdata assumes the string is being displayed as a full line in the edit window, and reserves space both at the beginning and end of the line. isprompt, on the other hand, reserves space only at the end of the line, which is the behavior we actually need.
|
David Lawrence Ramsey <dolorous> |
Thu 07 Mar 2019 06:58:44 PM UTC, comment #28: The patch causes a regression. To reproduce, paste "ㄓㄓ123" (without the quotes) into an empty buffer of the patched nano. Then press <Home> and hold down x until the 3 has gone offscreen (and thus the 2 is overwitten by the > character). Then type:
|
Benno Schulenberg <bens> |
Wed 06 Mar 2019 07:40:25 PM UTC, comment #27: Oh please, stop your vehemence. Sure, it's good to correct the logic. But no matter of testing would have found any observable wrong behavior, because this one buglet would have hidden it.
|
Benno Schulenberg <bens> |
Wed 06 Mar 2019 06:50:23 PM UTC, comment #26:
|
David Lawrence Ramsey <dolorous> |
Wed 06 Mar 2019 06:27:30 PM UTC, comment #25: A comment that I wrote before comment #23 but that somehow didn't make it through.
|
Benno Schulenberg <bens> |
Tue 05 Mar 2019 10:37:17 PM UTC, comment #24: A combination of paranoia and ease of readability. It was easier to trace what the code was doing if it left to_col alone and modified a copy of to_col in a separate variable instead. But using to_col directly does seem to work. Attached a patch with that simplification added. |
David Lawrence Ramsey <dolorous> |
Tue 05 Mar 2019 07:58:20 PM UTC, comment #23: Why do you need break_col? Doing:
|
Benno Schulenberg <bens> |
Mon 04 Mar 2019 10:07:50 PM UTC, comment #22: Attached an updated version of my last patch, resynced against git 37c8232, that sets isdata properly. Combined with the last patch in comment #9 of bug #55638, everything should work. |
David Lawrence Ramsey <dolorous> |
Mon 04 Mar 2019 09:47:41 PM UTC, comment #21:
|
David Lawrence Ramsey <dolorous> |
Sun 03 Mar 2019 09:10:00 AM UTC, comment #20: Dang... I had tried a recipe similar to comment #11 and it had worked okay. I must have forgotten to type 'make' or something. :|
|
Benno Schulenberg <bens> |
Sat 02 Mar 2019 08:01:01 PM UTC, comment #19: The off-by-one error you mentioned in comment #11, which I was still seeing in the version in comment #14, and which I'm not seeing in the new version I posted in comment #15. Besides, you only mentioned syncing it up with git in comment #14, not any bug fixes in it.
|
David Lawrence Ramsey <dolorous> |
Fri 01 Mar 2019 06:53:43 PM UTC, comment #18: If bug #55638 is not fully fixed (for the edit window), then please post on that bug. If however the fix (commit edc0d628) for that bug causes a new issue, then please post a new bug. |
Benno Schulenberg <bens> |
Fri 01 Mar 2019 06:40:12 PM UTC, comment #17: Sorry, I don't follow. Where is there an off-by-one error in the patch that I posted in comment #14? With that patch applied to current git, I can't find any mishighlighting of the string to be replaced. |
Benno Schulenberg <bens> |
Fri 01 Mar 2019 03:11:55 PM UTC, comment #16: Addendum:
|
David Lawrence Ramsey <dolorous> |
Fri 01 Mar 2019 07:59:06 AM UTC, comment #15: Attached an updated version of your patch that should fix the off-by-one in highlighting. Both our versions were a bit off in that regard. I had to put break_col back in this version, but it should work. Also, I changed isdata back to FALSE instead of TRUE in the display_string() call for now, since we're not trimming the string under all circumstances.
|
David Lawrence Ramsey <dolorous> |
Thu 28 Feb 2019 06:59:20 PM UTC, comment #14: Updated patch for current git is attached. |
Benno Schulenberg <bens> |
Wed 27 Feb 2019 09:01:52 PM UTC, comment #13: I'm back. I still haven't figured out how to fix this (also because the fix for bug #55773 overlaps with it), but since your patch does seem to fix this problem, and the apparent problem with it is actually caused by a botched fix for bug #55638, that bug should probably be reopened.
|
David Lawrence Ramsey <dolorous> |
Fri 22 Feb 2019 01:28:52 AM UTC, comment #12: The same problem occurs in my version of it.
|
David Lawrence Ramsey <dolorous> |
Wed 20 Feb 2019 06:56:15 PM UTC, comment #11: Oww... My version of the patch does not work right. To reproduce, run 'src/nano --ignore README' and type: M-R edit <Enter> xx <Enter>. See that actually just "edi" gets highlighted. :| I don't get it. |
Benno Schulenberg <bens> |
Tue 19 Feb 2019 04:23:24 PM UTC, comment #10: Thanks for testing.
|
Benno Schulenberg <bens> |
Mon 18 Feb 2019 10:41:10 PM UTC, comment #9: After some testing, your version does seem to work. |
David Lawrence Ramsey <dolorous> |
Fri 15 Feb 2019 06:01:26 PM UTC, comment #8: (Updated the patch for the changes in master.) |
Benno Schulenberg <bens> |
Thu 14 Feb 2019 08:20:36 PM UTC, comment #7: Updated patch that properly covers the case where the match ends in the screen's last column: then we skip showing the continuation character as it would only get in the way. |
Benno Schulenberg <bens> |
Thu 14 Feb 2019 08:09:22 PM UTC, comment #6: Here's a version that smooths things over a bit. The extra break_col variable is not needed, I think. |
Benno Schulenberg <bens> |
Thu 14 Feb 2019 02:22:49 AM UTC, comment #5: Argh. Forget that version; it's still buggy.
|
David Lawrence Ramsey <dolorous> |
Wed 13 Feb 2019 09:29:14 PM UTC, comment #4: How about the attached new version?
|
David Lawrence Ramsey <dolorous> |
Wed 13 Feb 2019 06:34:05 PM UTC, comment #3: Thanks. The fix works when the double-width character is just before the screen's edge, but not when it straddles the screen's edge. That is: when you type one more space before the fi so that the shown text looks like "fi$", and then do the replacement, it highlights "fi>", and there is no continuation character. However, if you had typed an <Enter> after the "xxx", then the highlighted continuation character "$" is wrongly shown on the next row. :| |
Benno Schulenberg <bens> |
Tue 12 Feb 2019 07:54:11 PM UTC, comment #2: Attached an updated version of the patch, which is resynced against git e7557a9 and fixes an inaccurate comment. |
David Lawrence Ramsey <dolorous> |
Mon 11 Feb 2019 11:23:44 PM UTC, comment #1: This occurs because spotlight() contains no logic to handle double-width characters. All it does is move back one character and display a '$', not accounting for a potential '>' beforehand.
|
David Lawrence Ramsey <dolorous> |
Fri 08 Feb 2019 04:51:10 PM UTC, original submission:
To reproduce, run 'nano --ignore --nowrap' and paste "fiㄓxxx" into the empty buffer. Then press <Home> and hold <Space> until the cactus has just reached the window's edge and its left half has been replaced with ">". Then type: M-R M-R fi.* <Enter> foo <Enter>. See how "fi$" is highlighted before the final "$", instead of "fi>$".
|
Benno Schulenberg <bens> |
Depends on the following items: None found
Items that depend on this one: None found
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 16 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2019-03-25 | bens | Open/Closed | Open | Closed | |
2019-03-08 | bens | Status | In Progress | Fixed | |
2019-03-07 | dolorous | Attached File | - | Added 0001-display-properly-handle-double-width-characters-when.patch, #46455 | |
2019-03-05 | dolorous | Attached File | - | Added 0001-display-properly-handle-double-width-characters-when.patch, #46439 | |
2019-03-04 | dolorous | Attached File | - | Added 0001-display-properly-handle-double-width-characters-when.patch, #46421 | |
2019-03-01 | dolorous | Attached File | - | Added 0001-display-properly-handle-double-width-characters-when.patch, #46381 | |
2019-02-28 | bens | Attached File | - | Added 0001-display-properly-handle-double-width-characters-when.patch, #46374 | |
2019-02-15 | bens | Attached File | - | Added 0001-display-properly-handle-double-width-characters-when.patch, #46275 | |
2019-02-14 | bens | Attached File | - | Added 0001-display-properly-handle-double-width-characters-when.patch, #46267 | |
2019-02-14 | bens | Attached File | - | Added 0001-display-properly-handle-double-width-characters-when.patch, #46266 | |
Status | None | In Progress | |||
Assigned to | None | dolorous | |||
2019-02-14 | dolorous | Attached File | - | Added 0001-display-fix-spotlighting-of-halves-of-double-width-c.patch, #46250 | |
2019-02-13 | dolorous | Attached File | - | Added 0001-display-fix-spotlighting-of-halves-of-double-width-c.patch, #46249 | |
2019-02-12 | dolorous | Attached File | - | Added 0001-display-fix-spotlighting-of-halves-of-double-width-c.patch, #46244 | |
2019-02-11 | dolorous | Attached File | - | Added 0001-display-fix-spotlighting-of-halves-of-double-width-c.patch, #46240 |
Powered by Savane 3.13-4448.
Corresponding source code
I thought that maybe the suggested change would affect the softwrap case, but it seems to work fine too. So...
Pushed to master, commit 43b42246.