I noticed this bug when I received a text file that Geany opened as something unreadable, but I found out that it is easily reproducible.
Let's say I create a file test.txt with some cyrillic content. For example, just one word "Тест", which is "Test" in Russian. Of course, it's two lines: the line with "Тест" and the last empty line. Then I select any Cyrillic encoding (e.g. Cyrillic/Russian (CP866)) and save the file. At this moment I still can discern its content: "Тест".
Then I close this file and open it again. Now it's content reads (in case I chose CP866) as "¥áâ". Checking the encoding setting I see that it's now set to ISO-8859-1 (and no, I have not enabled the setting "Use fixed encoding when opening non-Unicode files"). Setting the encoding to the right one does not fix the issue because Geaby does not recode the content of the file, it just sets the encoding in which the current (wrong) content will be saved.
So it seems that Geany when it determines that the file is not Unicode tries to open it as ISO-8859-1. I don't know if it requires a lot of work to fix, but Notepad2 and Notepad++ on Windows, whichever the encoding is, determine it correctly.
My system is: Kernel: 4.10.1-1-MANJARO i686 (32 bit) Geany 1.29 GTK 2.24.31, GLib 2.50.3
It is not generally possible to always accurately determine the encoding of a file just from its content, and particularly if it is a small file with little content. This is even more difficult for files encoded in various "code pages" since they resuse the same codes to mean different characters.
What encodings are specified by your locales on Windows and Linux? My guess is that the Windows locales match the file encoding, but the Linux one is UTF-8.
Inside Geany all files are UTF-8 encoded, they are only converted on opening and closing, thats why changing the encoding specification does nothing.
On opening a file with no embedded encoding specification, and no explicitly set encoding, Geany will first check to see if the file is already UTF-8, then check the encoding specified by the locale, then get desperate and try the known encodings and accept the first that converts to a valid UTF-8. At least that gets the file open and you can then often see that its wrong and close and re-open it with a different encoding (you did notice that the "more options" section of the open dialog allows you to select an encoding for this file).
Then I guess it's more of a feature request: selection of the encoding (for both "Reload as" and "Set encoding") could be improved: right now it requires wading through submenus: Document -> Set encoding -> $Group (West European, East European, etc.) -> $ActualEncoding. Or File -> Reload as -> $Group -> $ActualEncoding. Probably if on pressing "Reload as" or "Set encoding" a flat list (with $Group acting just as a header for the respective group of encodings) would pop up with find-as-you type possibility that would make the selection quicker?
Also (but that is less critical) probably File -> "Reloas as" can be duplicated as "Recode file" adjacent to Document -> "Set encoding"?
Probably if on pressing "Reload as" or "Set encoding" a flat list
There can be a lot of encodings, a flat list is likely to be too big for small screens like laptops.
Also (but that is less critical) probably File -> "Reloas as" can be duplicated as "Recode file" adjacent to Document -> "Set encoding"?
As I said above, all files are utf-8 in memory, they only get encoded at save, so there is no "Recode As".
I'm sorry, but there seems to be a miscommunication.
Probably if on pressing "Reload as" or "Set encoding" a flat list
There can be a lot of encodings, a flat list is likely to be too big for small screens like laptops.
I wrote
Probably if on pressing "Reload as" or "Set encoding" a flat list (...) would pop up with find-as-you type possibility.
Not unfold as a submenu, like now, but pop up as the list of plugins when you select Tools -> Plugins. It brings up the list of all installed plugins but it's not important whether it fits on a small laptop screen because it has a find-as-you-type field, where you type a part of the name of the plugin you want and then select it. If you had to select a plugin from a menu it would be a nightmare. Why not give one the possibility to select encoding in such a way too? Or for that matter the file type too (Document -> "Set file type"). There are a lot of file types and they are also grouped into submenus which makes it tedious to get to any exact file type.
Also (but that is less critical) probably File -> "Reloas as" can be duplicated as "Recode file" adjacent to Document -> "Set encoding"?
As I said above, all files are utf-8 in memory, they only get encoded at save, so there is no "Recode As".
Thank you for the explanation, I understood that all files are utf-8 in memory the first time you said it :)
But there is is a menu item File -> Reload as. What I suggested was making a duplicate of that item as Document -> "Recode file" adjacent to Document -> "Set encoding". Because in practice it does exactly what one would expect from a menu item of that name and it would be more logical to have it near the item "Set encoding". I saw the option "Set encoding", saw that it has no effect on the file that has already been opened with the wrong encoding and did not think to look for a possibility to "reload" the file. If there was an item "Recode file" near to "Set encoding" I would have immediately looked there. It just seems logical from a common user point of view.
Well, not that the second one is critical, but the first one (making a searchable list out of those nested submenus) would, imho, greatly improve usability.
Not unfold as a submenu, like now, but pop up as the list of plugins when you select Tools -> Plugins. It brings up the list of all installed plugins but it's not important whether it fits on a small laptop screen because it has a find-as-you-type field, where you type a part of the name of the plugin you want and then select it. If you had to select a plugin from a menu it would be a nightmare. Why not give one the possibility to select encoding in such a way too? Or for that matter the file type too (Document -> "Set file type"). There are a lot of file types and they are also grouped into submenus which makes it tedious to get to any exact file type.
Ok, makes more sense, but somebody has to do it.
"Recode file" near to "Set encoding" I would have immediately looked there. It just seems logical from a common user point of view.
The `Document` menu is for the document, the thing in memory, not the file on disk. Nothing in the document menu relates to the file, and as I said, we cannot re-code the document in memory.
`Reload` is in the `File` menu because it is a file operation.
It does not make sense (IMHO) to mix the two concepts, the document and the file.
Ok, makes more sense, but somebody has to do it.
Well, unfortunately I'm not a programmer, so if no one from the Geany team is willing to handle it, then I suppose I have to close the issue now.
Well, unfortunately I'm not a programmer, so if no one from the Geany team is willing to handle it, then I suppose I have to close the issue now.
Geany is an open source project, anybody can decide to contribute. Somebody who also has many encoding issues may decide to contribute a patch, it doesn't need to be a project member, and even the team members are volunteers that work on what they consider worthwhile, not what some manager tells them to. You can of course close the issue if you wish, but then its unlikely somebody will see it and think, "thats what I need, I'll try and do it".
Then perhaps this issue should be renamed (is it possible?) or a new one created with a name more directly related to transferring from nested submenus to a searchable list?
Then perhaps this issue should be renamed (is it possible?)
The `edit` button next to the title, as you opened the issue you should be able to edit it.
Oops. Thanks, I'm completely new to this.
github-comments@lists.geany.org