Written by Eldmannen the 23 May 08 at 18:50.
Category: Others.
Related project:
Nothing/Others.
Status: New
Rationale
Make gedit (the primary text editor in Ubuntu) be able to open any type of file.
When I try to open a binary file or a .png file or something, it whines and says;
* "gedit has not been able to detect the character coding.
Please check that you are not trying to open a binary file."
Well, I would like to be able to open a binary file.
But what would be an interesting idea: A program that fetches file type information (text, html, audio, video, picture, binary) and loads a specific backend (like gedit, gecko, gstreamer, ...).
But that's the point where we come to what the Konqueror is, because he can include KParts.
Yes, gedit could open binary file in hex mode, with charachet display on the side, this way we can have a look at the characters strings we can found in pictures or video files.
+1 but for an "hexadecimal mode" with a splited edition panel with hexadecimal left and the character on the right when the text can't be interpreted (because the "MS notepad" way to view binary files suck)
Even though most of the file is unreadable, I like to open a binary file in windows with, say, edit or notepad, to check out any "normal" text. Things like "password", my name spelled out among other things make me suspicious.
Definitely a good idea. Inability of gedit to open files containing zoros is the single most annoying "feature" of gedit.
Some text files might get corrupted and filled with zeros making gedit is no longer able to open them at all. This is possible after a hard system crash when the filesystem is trying to recover.
Another scenario is when recovering files with ddrescue. It pads read errors with zeros.
It is useful to compare the recovered file with a backup copy for instance so other tools, like meld, should be able to handle them too.
Until then:
'less' and 'emacs' opens these files.
'strings' can be use to extract readable text but it doesnt appear to support utf-8.
Some people may not want to see the contents of non text files, but for those of us who do it is a real pain to have to find another app like ghex. It should be a configuration option only show text file / open any file.
A hex view mode should then be added as a plug-in.
This is about the only feature I miss from windows.
My problem is openning a file and getting the "gedit has not been able to detect the character encoding" message. It is a text file that I created, but apparently introduced characters not part of the UTF-8 default encoding. Its a royal nuscience to then not be able to open it. Best fix to gedit is to open the file and have all foreign characters display uniformly as some character not normally displayed. That way I can find them and change them to a character in the encoding.
I have a large text file, with one (1!) control character in it. All editors other than gedit will show this file. Actually just to absolutely maximize my frustration, gedit does this big tease, showing me the file for about 1/5 second, then showing this huge red alert warning. It looks like the huge red firefox warning about web forgery. Surely one lone control character isn't such a huge threat!?!??? In ye olde days back in the era of text editors on text terminals, this thing was handled easily- a control character was just show as, e.g. ^K (i.e. control-K). There were representations for all 256 character combinations. Even if gedit just gave me a choice! It's nice that gedit is so fancy that it is trying to help me exotic character encoding- but why doesn't it let me say "assume character encoding XYZ" and just proceed? And one of the choices should be simple ASCII. Gosh, even Firefox lets me proceed if I want, and that could be a real threat. This gedit "feature" is extremely dysfunctional, unnecessary, frustrating, and drives me to use other editors on perfectly good simple text files. This is dumb.
I agree that is a good idea to normally prevent the opening of a binary file, because a user who doesn't know what he does can easily distroy his file. BUT the BIG BUT: Just like a browser offers you the possibility to view a https page with wrong autenthication infos (after a big red warning), just the same way gedit should let the user choose to act against what the program suggests.
This is a flat out usability bug and is completely infuriating. I have never used a text editor which did not give you the option to open a binary file if you really wish to. There are many reasons why you would want to do so, for example; edit the ascii header of a pgm binary file (which is in ascii and intended to be human readbale/editable); or to fix a malformed xml or html file; or open custom log files which happen to use the full ascii character set but are still largely human readable.
Giving the warning is fine but you have to give the option. I would even accept the option being hidden by default and has to be enabled in settings, but there is absolutely no excuse for not giving the option.
Many people seem to misunderstand this problem, except mpupilli saying it is a usability bug. The big problem with gedit is that it does this stupid complaint when the file is not a binary file at all, but a text file, possibly with only a single perplexing character. Who knows how that got there? Who cares? What gedit needs is to have an option to open the file anyway... the "never mind" option. Instead I get this huge red warning, completely overdone, like the warning Firefox gives me when I'm about to open the website portal to the trojan horse capital of the universe. In the mean time, we've been discussing this for 2 years, and the program flatly is unusable, at its own insistence, on a wide variety of files, which it is actually capable of working with just fine, if it would just shut the (*#@*# up.
gedit should always show contents of the file, even if it is ASCII only, with control codes marked in some fashion like SciTE, VIM, Notepad++, UltraEdit and many other technical editors. One the user has access to the file, options might be presented, like "Ignore", rather than forcing the user to decide what encoding to use or close the file.