Public bug reported:
The handling of codepages by gedit is inconsistent and may corrupt files and/or cause loss of data: gedit 3.18.3 / Ubuntu 16.04 LTS If I use the command gedit --encoding ISO-8859-15 <File> If, for some reason, the (new) input contains an UTF-8 character (e.g., by typing, or by pasting) then gedit does not save the file, but issues a warning: Could not save the file <..> using the "Western (ISO-8859-15)" character encoding. but does not show the incorrect character. Now there are two options: (1) If the file is saved using UTF-8 then also the "old" (unchanged) content is saved using UTF-8 (i.e., it corrupts the existing data) (2) Using "Save as ..." in order to avoid this does not work either: gedit acts as if it had obeyed this command, but after exit there is no such file (i.e., newly added material is lost), but the terminal shows the following error message: ** (gedit:20985): CRITICAL **: _gedit_tab_save_as_async: assertion 'tab->state == GEDIT_TAB_STATE_NORMAL || tab->state == GEDIT_TAB_STATE_EXTERNALLY_MODIFIED_NOTIFICATION || tab->state == GEDIT_TAB_STATE_SHOWING_PRINT_PREVIEW' failed I think that this behaviour counts as a (quite) serious bug. Moreover, I made some tests and noticed another quite curious behaviour: If a new file is opened with this command and then saved with text containing non-standard characters (like accented characters), these are saved using UTF-8 encoding. If this file is opened again they are shown "binary" as two characters while newly added characters are treated as the should. ** Affects: gedit (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to gedit in Ubuntu. https://bugs.launchpad.net/bugs/1681962 Title: gedit handles encodings inconsistently (and corrupts files) Status in gedit package in Ubuntu: New Bug description: The handling of codepages by gedit is inconsistent and may corrupt files and/or cause loss of data: gedit 3.18.3 / Ubuntu 16.04 LTS If I use the command gedit --encoding ISO-8859-15 <File> If, for some reason, the (new) input contains an UTF-8 character (e.g., by typing, or by pasting) then gedit does not save the file, but issues a warning: Could not save the file <..> using the "Western (ISO-8859-15)" character encoding. but does not show the incorrect character. Now there are two options: (1) If the file is saved using UTF-8 then also the "old" (unchanged) content is saved using UTF-8 (i.e., it corrupts the existing data) (2) Using "Save as ..." in order to avoid this does not work either: gedit acts as if it had obeyed this command, but after exit there is no such file (i.e., newly added material is lost), but the terminal shows the following error message: ** (gedit:20985): CRITICAL **: _gedit_tab_save_as_async: assertion 'tab->state == GEDIT_TAB_STATE_NORMAL || tab->state == GEDIT_TAB_STATE_EXTERNALLY_MODIFIED_NOTIFICATION || tab->state == GEDIT_TAB_STATE_SHOWING_PRINT_PREVIEW' failed I think that this behaviour counts as a (quite) serious bug. Moreover, I made some tests and noticed another quite curious behaviour: If a new file is opened with this command and then saved with text containing non-standard characters (like accented characters), these are saved using UTF-8 encoding. If this file is opened again they are shown "binary" as two characters while newly added characters are treated as the should. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/1681962/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp