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 760311 - Allow manually select/change encoding when automatic guess is wrong
Allow manually select/change encoding when automatic guess is wrong
Status: RESOLVED FIXED
Product: meld
Classification: Other
Component: filediff
3.14.x
Other Linux
: Normal normal
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2016-01-08 09:41 UTC by pav.rez
Modified: 2017-11-25 23:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
File for meld comparison (10.07 KB, patch)
2016-01-08 09:41 UTC, pav.rez
none Details | Review
Different encodings used. (381.00 KB, image/png)
2016-06-13 12:32 UTC, Frans Bilsen
  Details

Description pav.rez 2016-01-08 09:41:35 UTC
Created attachment 318466 [details] [review]
File for meld comparison

Hello,

  seldom I hit a problem when a comparison of ascii files (e.g. patch files) resulted in wrong encoding detection and meld is showing Chinese characters. Since I can imagine the automatic encoding detection can't be make perfect, or files are sometimes mixing encodings, would it be possible to add an option to change the encoding manually ? (e.g. in the right-click menu on an opened file).

It probably also matches with the other seen bug-reports about "fake" binary detection and possibility to override it manually.

Just in case there might be some other specific encoding problem in my case, I am attaching a file where the problem appears ("meld file file" demonstrates the problem).

Thanks,
Pavel
Comment 1 Kai Willadsen 2016-01-09 20:56:10 UTC
We don't actually have any automatic encoding detection. I experimented with adding it once, and it was so consistently incorrect that I just deleted the branch. We consult a list of encodings to try (which has changed a bit in 3.15.1), and pick the first one that decodes the file.

Either way, manually being able to select a different encoding is definitely something we should support; I'm just not sure how it will work either technically, or on a UI level.
Comment 2 Frans Bilsen 2016-06-13 12:30:54 UTC
Bump... 
Last version (ubuntu xenial) has this a lot. 

So if I understand correctly, I should try to build the last version and change that list...
Comment 3 Frans Bilsen 2016-06-13 12:32:23 UTC
Created attachment 329689 [details]
Different encodings used.

Actually, now I think about it, comparing should always use the same encoding for both files...
Comment 4 Kai Willadsen 2016-06-13 21:24:21 UTC
(In reply to Frans Bilsen from comment #2)
> Bump... 
> Last version (ubuntu xenial) has this a lot. 

Please try Meld 3.16.0. You may or may not need to change the list; I suspect that your left file there is being decoded as UTF16-LE.

(In reply to Frans Bilsen from comment #3)
> Actually, now I think about it, comparing should always use the same
> encoding for both files...

I agree that intuitively comparisons should probably use the same encoding for both files, but sadly people's real-world use cases won't allow that assumption.
Comment 5 Kai Willadsen 2017-01-27 20:24:38 UTC
*** Bug 777849 has been marked as a duplicate of this bug. ***
Comment 6 Kai Willadsen 2017-11-25 23:04:54 UTC
In 3.16.0 we started to use GtkSourceView for auto-detecting encodings, and so overall less manual intervention should be needed. There's still some issues with it, but nothing that we can really do much about.

More importantly, in master you can now select a different encoding from the status bar if the auto-detect fails. We *don't* always use the same encoding for all files, since that's... going to upset people in different ways.

Thanks for your bug report!