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 743098 - meld doesn't understand "non Latin" path
meld doesn't understand "non Latin" path
Status: RESOLVED OBSOLETE
Product: meld
Classification: Other
Component: general
3.12.x
Other Windows
: Normal major
: ---
Assigned To: meld-maint
meld-maint
Depends on:
Blocks:
 
 
Reported: 2015-01-17 17:18 UTC by Valery V.
Modified: 2017-12-13 19:10 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
exaple "Latin" and "non-Latin"(Russian) folders (1.64 KB, application/zip)
2015-01-17 17:19 UTC, Valery V.
Details

Description Valery V. 2015-01-17 17:18:18 UTC
I've tried to use Meld.lnk as "Send to" menu item and failed.

Problem localization: in 'C:\Program Files\Meld'
a) I've created folder 'rrr' (Latin letters) and place 2 files in folder. command 'Meld.exe rrr\KaznUTF.fb2 rrr\Kazn1251.fb2' works.
b) I've created folder 'абв' (Russian analog of 'abc'), place 2 files in folder. command 'Meld.exe абв\KaznUTF.fb2 абв\Kazn1251.fb2 ' failed ('Meld.exe rrr\KaznUTF.fb2 абв\Kazn1251.fb2 ' failed too). The program interface splashes and closes.

In attachment: archive with 'Latin language' and 'Russian language' folders with sample files

P.S. if I'm not mistaken, earlier version of http://sourceforge.net/projects/meld-installer/ also have some problems with paths, but on elder "Send to" worked normal.
Comment 1 Valery V. 2015-01-17 17:19:58 UTC
Created attachment 294745 [details]
exaple "Latin" and "non-Latin"(Russian) folders
Comment 2 Kai Willadsen 2015-01-17 20:36:09 UTC
Just out of interest, does this work if you open those files from within Meld? It's a problem either way of course, but it would be good to check both.
Comment 3 Valery V. 2015-01-18 06:12:11 UTC
1) if I open files containing non-Latin letters in path - Meld works correctly.

2) if I drop pair of files with non-Latin letters in their path in previously opened Meld GUI - Meld works correctly.

3) but if I try to drop the same pair of file on Meld.exe (or on Meld.lnk) - Meld GUI appears for less then second and closes.
Comment 4 Valery V. 2015-01-18 08:20:52 UTC
Checked previously used copy of fork project (http://sourceforge.net/projects/meld-installer/)... I've used "Send to" only with "Latin paths" (and have integrated Meld as "Tortouis HG" comparer, but all files in HG have Latin names), so it worked. But with "russian letters" in file/folder names fork project doesn't work also.
Comment 5 Valery V. 2015-01-18 10:41:52 UTC
more additional information:
All Russian (Cyrillic) letters are placed in "second part" of ASCII table ( http://www.haghish.com/statistics/stata-blog/stata-programming/images/ascii.png )
with "decimal numbers" > 127. more detailed info here: http://segfault.kiev.ua/cyrillic-encodings/  Windows uses CP1251 in GUI and CP866 in DOS (yes, "DOS made" logs containing Russian letters are unreadable in standard notepad.exe)
Comment 6 Valery V. 2015-01-23 09:04:52 UTC
more:
menu "File->Open Recent" either doesn't understand Russian letters it the filepath and doesn't work with 'non-Latin filepath'.
while in fork project ( http://sourceforge.net/projects/meld-installer/ ) "File->Open Recent" works correctly ( I specially have "unzipped" non-installed copy of fork project to compare 'bugs behavior' )
Comment 7 Kai Willadsen 2015-02-06 21:50:42 UTC
I've created bug 744113 for the recent files problem. That's a different issue and is a pain to fix correctly. For that we'll need good tests (and right now have none).

The problem in this bug is command-line handling of the CP1251 filenames. For reasons that I'm slowly figuring out, we're either getting or expecting the wrong filenames.
Comment 8 Balint Reczey 2015-09-06 13:31:13 UTC
The same issue has been reported to Debian BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784940

A very simple test can show the issue on Linux:

echo foo > meld-784940-test1.txt
echo bar > meld-784940-test-Воскресенье.txt
meld meld-784940-test1.txt meld-784940-test-Воскресенье.txt

Then click on File -> Format as Patch... to show:
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Traceback (most recent call last):
  • File "/usr/lib/python2.7/dist-packages/meld/filediff.py", line 1772 in make_patch
    dialog.run()
  • File "/usr/lib/python2.7/dist-packages/meld/patchdialog.py", line 98 in run
    self.update_patch()
  • File "/usr/lib/python2.7/dist-packages/meld/patchdialog.py", line 94 in update_patch
    diff_text = "".join(difflib.unified_diff(text0, text1, name0, name1))
  • File "/usr/lib/python2.7/difflib.py", line 1204 in unified_diff
    yield '+++ {}{}{}'.format(tofile, todate, lineterm)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 49-59: ordinal not in range(128)

From my package maintainer POV handling paths as UTF-8 would be fine but I'm not sure if that would solve the issue on Windows.
Comment 9 Kai Willadsen 2015-10-03 21:08:01 UTC
(In reply to Balint Reczey from comment #8)
> The same issue has been reported to Debian BTS:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784940

Unfortunately, this is a different problem; I wish the issues from the original bug were as easy to fix. The problems on Windows are very different and I haven't had the time or inclination to understand what's going on there.

> Then click on File -> Format as Patch... to show:
> Gtk-Message: GtkDialog mapped without a transient parent. This is
> discouraged.
> Traceback (most recent call last):

This is now fixed in 3.14.1; the relevant changeset is:
https://git.gnome.org/browse/meld/commit/?h=meld-3-14&id=def9e8777057c414c51b06eda5a41a9ff66f24c8

Thanks for bringing it up.
Comment 10 GNOME Infrastructure Team 2017-12-13 19:10:07 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/meld/issues/80.