After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342918 - Ability to change encoding in opened document
Ability to change encoding in opened document
Status: RESOLVED OBSOLETE
Product: gedit
Classification: Applications
Component: file loading and saving
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Gedit maintainers
Gedit maintainers
: 488811 553125 662560 670495 699697 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-05-25 13:42 UTC by Alexandre Prokoudine
Modified: 2020-11-24 10:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
Fast reopen document in a different encoding (1.92 KB, application/x-gzip)
2008-03-28 13:11 UTC, Vadim
  Details
Save line position when reopen with new encoding. (10.00 KB, application/x-gzip)
2008-03-31 11:38 UTC, Vadim
  Details
Added encodings menu for reopening of a document (30.43 KB, patch)
2009-05-07 15:02 UTC, Alexey Kozhevnikov
none Details | Review
version for gedit win32 (2.23 KB, application/x-gzip)
2011-02-22 06:29 UTC, leniviy
  Details
Add gedit_document_set_encoding() (2.43 KB, patch)
2012-11-11 20:42 UTC, Ma Hsiao-chun
needs-work Details | Review

Description Alexandre Prokoudine 2006-05-25 13:42:32 UTC
It would be very useful to be able to change encoding of an already opened
document. Reopening documents just to change encoding (sometimes several times)
is counter-productive.
Comment 1 Sebastien Bacher 2006-10-24 11:15:19 UTC
ubuntu bug about that: https://launchpad.net/products/gedit/+bug/67844
Comment 2 Сергей 2008-01-04 01:20:23 UTC
+1
Comment 3 Andrey 2008-01-21 13:30:09 UTC
I join to this report. Without this feature, Gedit looses same KDE editor (KWrite).
Comment 4 Vadim 2008-03-28 13:11:40 UTC
Created attachment 108172 [details]
Fast reopen document in a different encoding
Comment 5 Vadim 2008-03-28 13:16:57 UTC
Gedit plugin to fast reopen the file with any encoding, defined in the Open/Save dialog.
To install extract content of the encoding.tar.gz to ~/.gnome2/gedit/plugins/
Encoding list show in the File menu.
Depend: python 2.5, pygtk
Comment 6 Andrey 2008-03-29 14:14:06 UTC
Add this plugin to default Gedit configuration!
Comment 7 Vadim 2008-03-31 11:38:28 UTC
Created attachment 108326 [details]
Save line position when reopen with new encoding.
Comment 8 Dmitriy Tantsur 2009-04-05 13:13:41 UTC
Please add this plugin, it's very-very useful for Russian users!
Comment 9 Maxim Levitsky 2009-04-09 10:43:31 UTC
I also think so, this must be added

I understand that some features can be ommited for simplificy of interface, but this feature forces me to do dozens of steps to change the encoding.
I usuall just open the file in kate, since it is faster.

so, add this plugin
Comment 10 Alexey Kozhevnikov 2009-05-07 15:02:49 UTC
Created attachment 134201 [details] [review]
Added encodings menu for reopening of a document

Added encodings submenu (View->Encodings). Encoding changing is implemented through the reopening of a document. Encodings are grouped in sections like in FF.
Comment 11 Alexei 2009-06-27 21:29:28 UTC
can we add this plugin to ubuntu/debian repository for default gedit package or gedit-plugins package?
what should be done to accomplish that?
I would be happy to help with this.
Comment 12 fibonacci.prower 2009-07-01 08:07:28 UTC
Which Gnome version is the patch for?
Comment 13 Alexey Khoroshilov 2009-09-08 10:00:37 UTC
(In reply to comment #12)
> Which Gnome version is the patch for?

I believe it is for GNOME 2.26.

Is anyone going to review/accept/comment the patch?
Comment 14 Maxim Levitsky 2009-09-10 01:10:25 UTC
+1
Comment 15 Коренберг Марк 2010-05-04 07:31:31 UTC
+1
Comment 16 leniviy 2011-02-22 06:29:54 UTC
Created attachment 181558 [details]
version for gedit win32

This plugin takes the list of available encodings from GConf.
Gedit win32 has no GConf python binding. If 'import gconf' fails, this hardcoded list will be used:
["UTF-16","UTF-16LE","ISO-8859-15","WINDOWS-1251"]
Comment 17 Willian Gustavo Veiga 2011-04-15 22:08:58 UTC
+1
Comment 18 techtonik 2011-04-16 12:52:16 UTC
Changing encoding is inconvenient. Gedit should automatically detect encoding - it is not that hard. See https://bugzilla.gnome.org/show_bug.cgi?id=647935
Comment 19 Коренберг Марк 2011-04-16 13:11:48 UTC
PLEASE add possibility to change encoding on the fly. It's essential feature for text editors especially for Russian. Automatic detection is buggy. Why not to choose encoding manually? even when detection thinks that it choose encoding correctly?

P.S.
Народ, поддержите меня :)
Comment 20 Ignacio Casal Quinteiro (nacho) 2011-04-16 13:48:17 UTC
See that you can always open the document with a specific encoding. So I don't really see this so essential. Also if it wasn't that tricky to implement it would be already there.
Comment 21 techtonik 2011-04-16 14:05:00 UTC
(In reply to comment #20)
> See that you can always open the document with a specific encoding.

You can't if you're calling Gedit through context menu on a associated file.
Comment 22 Maxim Levitsky 2011-04-16 15:55:41 UTC
Yes, label me as troll, yes, go ahead....

@Ignacio Casal Quinteiro:

" Also if it wasn't that tricky to implement it
would be already there."

Yet, Vadims python plugin works just fine (download from ubuntu bugreport, (https://bugs.launchpad.net/gedit/+bug/67844/+attachment/244172/+files/encoding.tar.gz), version published here seems to be corrupted...

I think the best solution for this bug and the Gnome bug #1 (Gnome devs remove features and refuse to add any) that this bug depend on, is to switch to KDE or Windows.

Gnome totalitarian attitude to users really makes me sick, and this summer I ether switch to KDE or Windows, cause the biggest Linux advantage, its customization ability just disappears as snow in the summer.

(And KDE, while is very good and almost bug-free, is just slower that Gnome, especially graphics wise).
Comment 23 Ignacio Casal Quinteiro (nacho) 2011-04-16 18:32:50 UTC
Well, if we wouldn't want this feature we would just close the bug as WONTFIX, which is not the case, we are volunteers here working and afaik we've been adding new features for years. The issue is that none of us (the current maintainers) want to work on this feature, but this doesn't mean that we don't want it, if somebody comes up with a good patch it is more than welcome.
Comment 24 Dmitriy Tantsur 2011-04-16 18:39:53 UTC
Ignacio, why not add plugin from comment 22 to official plugins? It seems to be the most simple solution and it won't affect users that do not need it.

And what about patches in this thread? Aren't they alright? If they aren't, what should we fix in them?
Comment 25 Ignacio Casal Quinteiro (nacho) 2011-04-16 18:44:14 UTC
Well the reason we don't add the plugin is:
1) It is outdated
2) We don't think it is the right solution for it.

In the past cycle I've invested a lot of time rewriting the part of gedit that loads and writes files with encoding detection etc, so I guess that the best solution would be to continue this job, and make it possible to make the change of encoding. We would have to discuss how to make it though, if you are interested on making it feel free to join us in #gedit channel of freenode and we can discuss this more deeply.
Comment 26 Dmitriy Tantsur 2011-04-16 18:48:15 UTC
Ghmm... I haven't worked with Gtk yet.. Still, I'd try to fix this issue if no one has time to.
Comment 27 techtonik 2011-04-16 18:55:04 UTC
Patch would be better, indeed.

However, a technical explanation why is it so hard to implement will be appreciated. And while IRC is good, it is better to describe situation here - more chances that somebody experienced can find and help fixing it. We can also split it into several reports if some serious internal rework is required.
Comment 28 Ignacio Casal Quinteiro (nacho) 2011-04-16 19:01:38 UTC
We will, but not today, I have a madrid-barça in less than one hour ;)
Comment 29 Ignacio Casal Quinteiro (nacho) 2011-04-16 19:01:59 UTC
btw, not freenode, gimpnet irc
Comment 30 Dmitriy Tantsur 2011-04-16 19:55:40 UTC
I see this as 2 parts:
1. Reload functionality with ability of setting encoding. Btw, would be nice to have as a separate menu item. Maybe as a sequence of 2 existing actions: close -> open with special encoding set.
2. Encodings menu itself.

Any other ideas?
Comment 31 Dmitriy Tantsur 2011-04-17 15:09:53 UTC
As to me, whether this feature is easy to implement or not depends on whether gedit_document_load can be used to reopen a document or not.
Comment 32 Oleg Strizhechenko 2011-08-30 05:48:00 UTC
(In reply to comment #19)
> PLEASE add possibility to change encoding on the fly. It's essential feature
> for text editors especially for Russian. Automatic detection is buggy. Why not
> to choose encoding manually? even when detection thinks that it choose encoding
> correctly?
> 
> P.S.
> Народ, поддержите меня :)

+1
Auto detection is really buggy, 5-7 minutes ago my gedit opened KOI8R document as CP1251.
P.S.: Марк, поддерживаю :)
Comment 33 Ma Hsiao-chun 2012-04-26 03:36:06 UTC
*** Bug 670495 has been marked as a duplicate of this bug. ***
Comment 34 Ma Hsiao-chun 2012-04-26 03:46:53 UTC
Hi, all.

I'd point out that Chinese users' situation is similar to that of Russian.

I tried to create a (Python) encoding selection plugin for gedit3 two months ago. But I found that the encoding is kind of read-only. All I wrote can be found in the following link.
https://github.com/maxiaojun/gedit3-encoding-helper
Comment 35 André Klapper 2012-08-02 09:36:22 UTC
*** Bug 662560 has been marked as a duplicate of this bug. ***
Comment 36 André Klapper 2012-08-02 16:09:39 UTC
*** Bug 488811 has been marked as a duplicate of this bug. ***
Comment 37 Ma Hsiao-chun 2012-11-11 20:42:49 UTC
Created attachment 228727 [details] [review]
Add gedit_document_set_encoding()

"encoding" property in GeditDocument is read-only currently.
My patch adds setter of "encoding" property.

Given that the setter is available, plugins can be created to mitigate or solve long lasting encoding issues.

Please review it.
Comment 38 Nick 2013-01-13 10:53:09 UTC
+1
Comment 39 André Klapper 2013-01-13 12:49:38 UTC
Please do not add "+1" comments in Bugzilla. This is not a voting contest.
A "Could somebody please review the patch here" would have been more helpful.
Comment 40 Paolo Borelli 2013-01-13 13:33:06 UTC
About the patch, I should have update bugzilla, but it was discuessed and reviewed on irc. It needs some work, here is the log of the irc conversation for my own reference before I loose the logs:


Nov 18 18:04:59 <maxiaojun>	add gedit_document_set_encoding() patch, wanna review of comment
Nov 18 18:05:12 <maxiaojun>	https://bugzilla.gnome.org/attachment.cgi?id=228727&action=diff
Nov 18 19:02:37 madewokherd maxiaojun 
Nov 18 19:02:39 <pbor>	hi maxiaojun 
Nov 18 19:02:54 <maxiaojun>	hi
Nov 18 19:03:19 <pbor>	I had that mail marked in my todo list, but I was procrastinating... encoding are such a burden :)
Nov 18 19:03:24 <pbor>	sorry about that
Nov 18 19:04:20 <pbor>	maxiaojun: I did not look at the patch in detail, but one of the things I do not like is that it uses get_text to get all the text in a single string
Nov 18 19:04:29 <pbor>	we try to avoid that as much as possible
Nov 18 19:04:29 <maxiaojun>	ok, so i try to find you later?
Nov 18 19:04:48 <pbor>	because it could be a large file
Nov 18 19:05:00 <pbor>	so we try to do the conversion incrementally
Nov 18 19:05:18 <maxiaojun>	I know that, so I asked whether we need to do stream conversion.
Nov 18 19:05:30 <pbor>	yes, it would be nice
Nov 18 19:05:51 <pbor>	also because it would allow to show where the conversion fails
Nov 18 19:05:59 <pbor>	if it fails in the middle of the file
Nov 18 19:06:38 <maxiaojun>	i don't know how to handle such error nicely
Nov 18 19:07:01 <pbor>	actually...
Nov 18 19:07:03 <pbor>	lemme see
Nov 18 19:07:04 <maxiaojun>	now i just return FALSE but no information is given to the caller
Nov 18 19:08:04 madewokherd maxiaojun 
Nov 18 19:08:20 <pbor>	maxiaojun: we already have streaming conversion for load and save
Nov 18 19:08:34 <pbor>	maxiaojun: maybe it is enough to pipe them together?
Nov 18 19:08:55 <pbor>	well, I guess it would not be that easy, but I think it may be doable
Nov 18 19:09:46 <pbor>	we have a document stream that outputs encoded text (the one we use for saving) and we could stream it into the one we use for loading
Nov 18 19:09:56 <pbor>	the principle would be the same you used
Nov 18 19:10:01 <maxiaojun>	i've checked the output conversion but not yet sure about the input one
Nov 18 19:10:32 <pbor>	convert back from utf8 to the old encoding and then use the new encoding to convert again to utf8
Nov 18 19:11:50 <pbor>	they are called gedit-document-input-stream and output-stream
Nov 18 19:12:36 <maxiaojun>	yes
Nov 18 19:13:09 <pbor>	output stream would take care automatically of the error handling
Nov 18 19:13:24 <maxiaojun>	output stream has a convert_text function
Nov 18 19:13:33 <maxiaojun>	but it is static
Nov 18 19:14:03 <pbor>	that's ok, it should be internal
Nov 18 19:14:09 <pbor>	what I mean is:
Nov 18 19:14:42 <pbor>	you instanciate an input-stream to convert the text buffer (utf8) to the "old" encoding
Nov 18 19:15:16 <pbor>	you instanciate an output stream to convert what comes from the input stream to the "new encoding"
Nov 18 19:15:49 <pbor>	probably you would need to use tow TextBuffers
Nov 18 19:16:00 <pbor>	(that is two GeditDocuments)
Nov 18 19:16:29 <pbor>	since obviously you cannot get the text and write the text on the same one
Nov 18 19:16:42 <pbor>	but that should be ok
Nov 18 19:17:00 <pbor>	we could have the set_encoding on the view level
Nov 18 19:17:13 <pbor>	and that swaps the document with the new one
Nov 18 19:17:35 <maxiaojun>	i wonder can we really avoid double memory?
Nov 18 19:17:46 <pbor>	double memory is ok
Nov 18 19:17:58 <pbor>	I do not mind that much
Nov 18 19:18:24 <pbor>	afterall if you do not have momory to open another file, you would be in trouble already
Nov 18 19:18:50 <maxiaojun>	i'm a bit confused, then what's good about stream conversion?
Nov 18 19:18:54 <pbor>	what I want to avoid is having in memory a single huge string with all the content
Nov 18 19:19:38 <pbor>	the OS is prefectly capable of giving you e.g. 100MB
Nov 18 19:19:55 <pbor>	but it could fail to give you a single contigous block of 100MB
Nov 18 19:20:19 <maxiaojun>	actually i'm not quite sure whether GeditDocument is cached or something
Nov 18 19:21:04 <maxiaojun>	i mean, if i have 100MB content in a GeditDocument, how would GeditDocument store it?
Nov 18 19:21:48 <pbor>	GtkTextBuffer uses a btree in memory
Nov 18 19:22:00 <pbor>	where each line is a leaf of the tree
Nov 18 19:23:25 <maxiaojun>	that's fine
Nov 18 19:24:13 <maxiaojun>	btw, i tried to open a 30MB debdiff yesterday and Gedit 3.4 stuck
Nov 18 19:24:48 <pbor>	does it have long lines
Nov 18 19:24:50 <pbor>	?
Nov 18 19:25:06 <maxiaojun>	no
Nov 18 19:25:12 <pbor>	e.g. a binary blob which is encoded on a single line etc
Nov 18 19:25:15 <pbor>	ok :(
Nov 18 19:25:51 *	nacho (~nacho@078088063204.bielskobiala.vectranet.pl) has joined #gedit
Nov 18 19:25:51 <pbor>	did it get stuck or did it go 100% cpu for long time?
Nov 18 19:26:47 <maxiaojun>	i haven't checked that at that moment, i can do some study later and write a nice bug report
Nov 18 19:27:25 <pbor>	that'd be great
Nov 18 19:27:46 <pbor>	coming back to the encoding thing
Nov 18 19:27:53 <maxiaojun>	yeah
Nov 18 19:28:03 <pbor>	I'd say to try to play a bit with the idea of the two streams
Nov 18 19:28:07 <pbor>	I think it can work
Nov 18 19:28:12 <maxiaojun>	ok
Nov 18 19:28:18 <pbor>	and if you have problems feel free to poke us
Nov 18 19:28:28 <maxiaojun>	what about the interface?
Nov 18 19:28:33 <pbor>	worse case your patch looks quite ok
Nov 18 19:28:45 <pbor>	you mean the api interface or the UI?
Nov 18 19:28:50 <maxiaojun>	API
Nov 18 19:29:01 <pbor>	well
Nov 18 19:29:14 <pbor>	the api in your patch is the simpler
Nov 18 19:29:34 <pbor>	but as I said above if we use the stream we will need to use two GeditDocuments
Nov 18 19:29:46 <pbor>	so we have two possibilities I think
Nov 18 19:29:59 <pbor>	1) keep the api the same
Nov 18 19:30:23 <pbor>	we wuuld hide inside GeditDocument the creation of an helper document
Nov 18 19:30:32 <pbor>	so it would go something like this
Nov 18 19:31:09 <pbor>	create a new document, copy the text from the cur doc to the new one, stream the text from the helper to the current one
Nov 18 19:31:48 <maxiaojun>	yeah
Nov 18 19:31:57 <pbor>	the downside is "creating a new document with the same text" is not as easy as it sound
Nov 18 19:32:00 <pbor>	I mean
Nov 18 19:32:11 <pbor>	it is easy with get_text() set_text()
Nov 18 19:32:28 <pbor>	but if we want to avoid that then we'd would have to stream
Nov 18 19:32:40 <maxiaojun>	true
Nov 18 19:32:55 <pbor>	so it would become
Nov 18 19:33:52 <pbor>	create a new doc, stream content without conversion (utf8->utf8) to the new doc, stream back the text with the roundtrip conversion
Nov 18 19:33:57 <pbor>	maybe it is not that bad
Nov 18 19:34:12 <pbor>	hard to say without trying
Nov 18 19:34:27 <pbor>	the other possibility is to have a different api
Nov 18 19:34:27 <maxiaojun>	let's focus on api interface first :)
Nov 18 19:34:43 <pbor>	which would be something like
Nov 18 19:35:23 <pbor>	GeditDocument *gedit_document_convert(doc)
Nov 18 19:35:33 <pbor>	(well, the name is to think)
Nov 18 19:35:45 <pbor>	but the idea would be to return a cloned document
Nov 18 19:35:54 <pbor>	with the new encoding
Nov 18 19:36:21 <maxiaojun>	with the new encoding?
Nov 18 19:36:35 <pbor>	at that point the ui would be in charge of detaching the old doc from the view
Nov 18 19:36:40 <pbor>	and use the new one
Nov 18 19:38:24 <maxiaojun>	i didn't get GeditDocument *gedit_document_convert(doc)
Nov 18 19:38:48 <maxiaojun>	it just clone or do something also?
Nov 18 19:39:05 <pbor>	it would do the conversion
Nov 18 19:39:12 <pbor>	it would return a new doc
Nov 18 19:39:32 <pbor>	with the text converted to the selected encoding
Nov 18 19:40:55 <maxiaojun>	so it should have a encoding argument also and becomes GeditDocument *gedit_document_convert(doc, enc) ?
Nov 18 19:41:20 <pbor>	yes
Nov 18 19:41:23 <pbor>	sorry
Nov 18 19:43:27 <maxiaojun>	i just wonder, it we use the later api interface, is it convenient for python plugins?
Nov 18 19:45:10 <maxiaojun>	what people want about encoding stuff is following:
Nov 18 19:45:50 <maxiaojun>	1. select encoding on the fly
Nov 18 19:46:55 <pbor>	yes, I think the first api would be nicer
Nov 18 19:46:58 <maxiaojun>	this is more needed in some regions, so i guess a shipped but not default enabled plugin would be best.
Nov 18 19:47:26 <pbor>	well, once we have the functionality we can see about the UI
Nov 18 19:47:40 <pbor>	we could have a combo in the toolbar
Nov 18 19:47:55 <nacho>	hey
Nov 18 19:48:00 <pbor>	shown only if the original encoding is not utf8
Nov 18 19:48:03 *	nacho does not like to have a combo for that...
Nov 18 19:48:15 <pbor>	but anyway, let's first make it work
Nov 18 19:48:16 <maxiaojun>	2. use locale heuristic to guess encoding 
Nov 18 19:48:21 <pbor>	and then we'll see
Nov 18 19:48:23 <pbor>	hey nacho 
Nov 18 19:48:35 <pbor>	nacho: did not have time for gtkapp in the end :(
Nov 18 19:48:41 <nacho>	yeah...
Nov 18 19:48:45 <nacho>	me neither :)
Nov 18 19:48:54 <nacho>	but I really think we are quite close
Nov 18 19:48:58 <pbor>	maxiaojun: that's something separate
Nov 18 19:49:00 <nacho>	and I am all for regress
Nov 18 19:49:09 <pbor>	so for now I'd say let's focus on the convert
Nov 18 19:49:16 <pbor>	I have to run to dinner now
Nov 18 19:49:32 <maxiaojun>	3. universal detection, as i tried both chardet and ICU, they do not cover all common encoding and have some bugs. 
Nov 18 19:50:16 <maxiaojun>	ok, i just want to argue that an api interface nicer for plugin would be better
Nov 18 19:51:08 <pbor>	sure
Nov 18 19:51:12 <pbor>	bye!
Nov 18 19:51:20 <maxiaojun>	bye
Nov 18 19:51:41 <pbor>	(and thanks for tackling this)
Nov 18 19:53:12 <maxiaojun>	welcome
Nov 18 19:53:57 <maxiaojun>	nacho: 'does not like to have a combo for that…' so a plugin should be ok?
Nov 18 19:55:12 <nacho>	dunno, I would actually do not like this part of the api exposed externally
Nov 18 19:55:15 <nacho>	maybe a menu?
Nov 18 19:55:48 <maxiaojun>	well why not api first?
Nov 18 19:56:59 <nacho>	sure
Nov 18 19:57:04 <nacho>	focus on the api
Nov 18 19:57:17 <nacho>	but for starting I would not expose it externally to plugins...
Nov 18 19:57:39 <maxiaojun>	i was asking why you think this way? 
Nov 18 19:58:27 <nacho>	exposing api from the beginning it means that you have to maintain it over the years
Nov 18 19:58:52 <nacho>	so if there is really an use case for exposing that to the plugins I am all for it
Nov 18 19:59:04 <nacho>	but why would a plugin want to change the encoding?
Nov 18 19:59:20 <nacho>	I'd say that makes more sense in the core...
Nov 18 19:59:40 <maxiaojun>	because you are hopeless when gedit guess encoding wrong
Nov 18 20:00:04 <nacho>	maxiaojun, sure but what has to do with this case?
Nov 18 20:00:38 <maxiaojun>	so it would be nice if a plugin can give you a menu like Chrome/Firefox/Kate
Nov 18 20:00:49 *	nacho came a bit late in the conversion so maybe I lost some part
Nov 18 20:01:01 <nacho>	maxiaojun, but I mean, why a plugin?
Nov 18 20:01:13 <nacho>	this is definetly something to be in the core no?
Nov 18 20:01:52 <maxiaojun>	well, since such requests probably patch on 2.x exist for years
Nov 18 20:02:03 <nacho>	anyway we can decide that later
Nov 18 20:02:13 <nacho>	let's focus on getting this working with unit tests
Nov 18 20:02:31 <nacho>	and then we can decide about exposing to plugins vs core
Nov 18 20:02:39 <nacho>	and the kind of UI that we would like
Nov 18 20:03:20 <maxiaojun>	ok, what's your concern about that?
Nov 18 20:05:09 <maxiaojun>	?
Nov 18 20:06:01 *	carandraug has quit (Ping timeout: 600 seconds)
Nov 18 20:08:27 <maxiaojun>	if you want unit test, i will write one for the new api
Nov 18 20:09:27 <maxiaojun>	if you want something become a core feature, that's more complicated.
Nov 18 20:10:21 <maxiaojun>	browsers/kate has encoding menu and automatic detection
Nov 18 20:11:24 <maxiaojun>	if you want encoding menu, you still need similar api internally, afaik
Nov 18 20:12:38 <maxiaojun>	for automatic detection, we discussed in gedit-list a little bit that you may not want to link to another library.
Nov 18 20:13:01 *	derek_v has quit (Leaving)
Nov 18 20:13:55 <maxiaojun>	as said, i tried both chardet and ICU (through my patch and python plugin), they are not good enough but would be very nice some people
Nov 18 20:14:33 *	carandraug (~carandrau@79.97.223.237) has joined #gedit
Nov 18 20:15:36 <maxiaojun>	i'd eat my lunch now, afk
Nov 18 20:17:11 <nacho>	maxiaojun, ok
Nov 18 20:17:27 <nacho>	what does webkit uses for that btw?
Nov 18 20:18:41 <maxiaojun>	Chromium uses ICU, i don't know Epiphany/Safari, may be i can check later
Comment 41 mihail2009 2013-02-10 23:32:47 UTC
I second this bug, but I want to stress what's so annoying about it.

When you open a file and it's opened with wrong encoding, the first thing you try is going to File -> Open menu to open it again specifying exact encoding in the open dialog. Unfortunately, this doesn't lead to the file actually being reopened.

Then you think "oh, I just need to close the file before opening it again". You close it, but when you do File -> Open it turns out that gedit has already forgotten the directory the file was in and it shows your home folder instead, so you have to go all the way through the filesystem hierarchy to find the file (which achieves your goal, but is really annoying to do each time this happens, which is actually always).

So gedit actually has everything one needs, it's just a usability issue. What is really needed is a way to REOPEN a file; it would be quite ok if it would be a "Reopen" menu which just brought an open dialog with the currently open file already selected (so the user just needs to select encoding).

What is NOT NEEDED is the ability to change encoding on the fly for the text that's never been saved or for the file that was edited after being opened: 

1) I don't see any use for this except fixing some wrongly-encoded text produced by other applications (which is not what gedit is for anyway)

2) in the important use case of a file loaded with wrong encoding this leads to 3 encoding transforms: file bits on disk -> internal utf (assuming wrong encoding) -> reverse transform (assuming wrong encoding) -> internal utf (assuming new encoding). The first two transforms should in theory constitute an identity transform, but given that they are done using wrong encoding they can produce some undesirable artifacts. Just reopening the file with the right encoding seems much saner to me.
Comment 42 Sébastien Wilmet 2013-05-19 17:53:23 UTC
*** Bug 553125 has been marked as a duplicate of this bug. ***
Comment 43 Sébastien Wilmet 2013-11-01 22:03:54 UTC
*** Bug 699697 has been marked as a duplicate of this bug. ***
Comment 44 Sébastien Wilmet 2014-01-11 16:15:42 UTC
(In reply to comment #41)
> Just reopening the file with the right
> encoding seems much saner to me.

Yes, it's safer to take again the original contents. For small files it is not really a performance problem to reload the file from the disk.

I'm working on a new API for file loading and saving in GtkSourceView, so I take this bug into account. And it will be possible to change the encoding and reload the file easily. When reloading the file, the old GtkTextBuffer contents is simply removed.
Comment 45 Sébastien Wilmet 2020-11-24 09:58:04 UTC
Mass-closing of all gedit bugzilla tickets.

Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing:

2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3

By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements.

We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.
Comment 46 Коренберг Марк 2020-11-24 10:42:28 UTC
Please reopen. Still actual.
Comment 47 Marc Plano-Lesay 2020-11-24 10:47:42 UTC
As indicated in the previous comment, Bugzilla is going away. This bug still lives on GitLab - https://gitlab.gnome.org/GNOME/gedit/-/issues/20.