GNU nano - Bugs: bug #48489, when a deletion creates a valid...
You are not allowed to post comments on this tracker with your current authentication level.
bug #48489: when a deletion creates a valid character from invalid bytes, nano should adapt
Submitter: | Benno Schulenberg <bens> | ||
Submitted: | Tue 12 Jul 2016 07:42:20 PM UTC | ||
Severity: | 2 - Minor | Status: | Wont Fix |
Assigned to: | None | Open/Closed: | Closed |
Sun 17 May 2020 12:23:48 PM UTC, comment #5: |
Benno Schulenberg <bens> |
Thu 30 Mar 2017 03:59:19 PM UTC, comment #4: Specific example: Run rxvt-unicode 9.22, set URxvt.meta8 to True in your .Xdefaults file, and press Alt-whatever, and it will insert the raw byte with that value (instead of the UTF-8 character with that value as xterm does).
|
David Lawrence Ramsey <dolorous> |
Wed 29 Mar 2017 06:13:01 PM UTC, comment #3: Addendum: it's also possible to output a high-bit control character in do_output() via verbatim input mode if the terminal is configured to set the high bit when, say, Alt is held, so that case could also create a valid UTF-8 sequence. So both input and output need to be covered by whatever fixes this bug. |
David Lawrence Ramsey <dolorous> |
Wed 29 Mar 2017 03:51:33 PM UTC, comment #2: I just had a thought: This problem isn't just caused by character deletion; it can also be caused by character addition.
|
David Lawrence Ramsey <dolorous> |
Sat 25 Feb 2017 09:14:22 PM UTC, comment #1: Since I use constant cursor position display by default, I've noticed another problem with this: aside from making sure that we're not in the middle of a character after a deletion, the character count needs to be adjusted as well.
|
David Lawrence Ramsey <dolorous> |
Tue 12 Jul 2016 07:42:20 PM UTC, original submission:
To reproduce, run 'echo "0000000: 506f 7274 6f72 6fc5 20be 2e" | xxd -r - >portoroz', and then run 'src/nano portoroz' in a UTF8 locale. Move the cursor till it is between the two invalid bytes, then press Delete. The valid character "ž" appears out of nowhere (because the two bytes of its code had artificially been separated by a space, which has now been deleted). Note that the cursor now seems to be positioned on the final period, but... it is not, which you will see when you press Delete again. Instead of deleting the period, the second byte of ž is deleted, making its first byte an invalid one again.
|
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 3 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-05-30 | bens | Open/Closed | Open | Closed | |
2020-05-17 | bens | Attached File | - | Added 0001-editing-an-attempt-to-shy-away-from-the-middle-of-a-.patch, #49102 | |
Status | None | Wont Fix |
Powered by Savane 3.13-758e.
Corresponding source code
It's possible to fix this (see attached patch), but it's too much code for an issue that should normally never occur.
Furthermore, the cursor not moving when pressing the left or right arrow can also occur when dealing with combining characters. It would be more important to get that working in a less surprising way.
(And if the user has configured their terminal so that they can enter raw, invalid bytes, well, they get to live with the problem they themselves have created.)
(file #49102)