GNOME Bugzilla – Bug 777849
Incorrectly guessed encoding
Last modified: 2017-11-25 23:01:46 UTC
Created attachment 344436 [details] screenshot demonstrating the issue Here's a 3-way diff from meld (launched by TortoiseHG) after doing a merge with mercurial. Note the complete mess on the left.
The left file has, for some reason, been decoded as (probably) UTF-16LE or similar. You can work around this by setting the detect-encodings key to try whatever encoding the file is in first, e.g., gsettings set org.gnome.meld detect-encodings "['utf-8']" (replacing 'utf-8' with whatever the encoding is). This just changes up the order of encodings that Meld uses to try to decode the text. I'm going to mark this bug as a dup of bug 760311, since that's an existing feature request to allow manually selecting an encoding when things go wrong (as they have here). Thanks for your bug report. *** This bug has been marked as a duplicate of bug 760311 ***
> I'm going to mark this bug as a dup of bug 760311, since that's an existing > feature request to allow manually selecting an encoding when things go wrong > (as they have here). This should NOT be marked as a duplicate. One thing is the perfectly legitimate feature request to be able to manually force an encoding; a different thing is the BUG that leads to the WRONG automatic detection. The file was encoded in utf-8, as were the other two files which were decoded correctly.
What version of meld is on the screenshot? The guessing behaviour was hugely changed starting with meld 3.15.2 due to porting to GTKSourceView helpers. It has known guessing problem that fails distinguishing utf-8 from ascii-based single-byte-per-character encodings, but has NO known problems related to utf-16* encoding (like in screenshot), since they are very different from others.
Closing, since no more information has been provided. Also, in current master, you can now manually switch encodings for situations like the above.