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
