GNU nano - Bugs: bug #47626, composed and decomposed characters...
You are not allowed to post comments on this tracker with your current authentication level.
bug #47626: composed and decomposed characters are not seen as equal
Submitter: | Benno Schulenberg <bens> | ||
Submitted: | Tue 05 Apr 2016 12:15:18 PM UTC | ||
Severity: | 2 - Minor | Status: | Wont Fix |
Assigned to: | None | Open/Closed: | Closed |
Mon 07 Dec 2020 10:15:17 AM UTC, comment #2: |
Benno Schulenberg <bens> |
Tue 05 Apr 2016 01:23:51 PM UTC, comment #1: Proposed solution: when reading in a file (in a Unicode locale), nano should normalize the encoding. And, when any normalization occurs, it should note this on the statusbar (just like when a DOS or Mac file is converted -- the difference is that now writing out the file does modify it). This normalization step should probably be behind a configuration and/or runtime flag. |
Benno Schulenberg <bens> |
Tue 05 Apr 2016 12:15:18 PM UTC, original submission:
When a Unicode-encoded text contains characters that are canonically equivalent but encoded in differing manners, then nano will not see them as the same when searching for them.
|
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 4 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2020-12-21 | bens | Open/Closed | Open | Closed | |
2020-12-07 | bens | Status | None | Wont Fix | |
2016-04-05 | bens | Summary | composed and precomposed characters are not seen as equal | composed and decomposed characters are not seen as equal | |
2016-04-05 | bens | Attached File | - | Added equivalents, #36840 |
Powered by Savane 3.13-4448.
Corresponding source code
Well, normalizing Unicode strings is complicated. As the FAQ (http://www.macchiato.com/unicode/nfc-faq_ says, it's best not to roll your own, but I don't want nano to have another dependency (in this case: libicu), so... won't fix.
Anyway, Vim and Emacs don't recognize precomposed and composed characters as equivalent either, so it can hardly be said that nano is falling short.
(Strangely, when xterm and urxvt display a letter that is followed by a combining character, they actually display the equivalent precomposed character. Which means that copy-pasting something from the screen can give you something different from what is actually in the file. Xfce Terminal displays the file as it is.)