meld issueshttps://gitlab.gnome.org/GNOME/meld/-/issues2018-11-21T21:07:49Zhttps://gitlab.gnome.org/GNOME/meld/-/issues/247Performance issue - High I/O on dconf due to GTK2018-11-21T21:07:49ZGhost UserPerformance issue - High I/O on dconf due to GTKWhen interacting with **GTK GUI elements** (moving the mouse over an element) or **scrolling** the panes there is a **massive I/O** load visible on the **dconf** database (~/.conf/dconf/user). On regular HDDs you can hear the heads rattl...When interacting with **GTK GUI elements** (moving the mouse over an element) or **scrolling** the panes there is a **massive I/O** load visible on the **dconf** database (~/.conf/dconf/user). On regular HDDs you can hear the heads rattling in realtime to the mouse movements. You can literally make music with it.
To make the issue visible you can use 'dconf watch /', 'iotop', or 'strace'.
Its probably not all too healthy for drives and performance. The bug is older than 1+ years. I workaround it atm by putting the dconf database into tmpfs.
ArchLinux 4.19.2, meld 3.19.1https://gitlab.gnome.org/GNOME/meld/-/issues/246When typing in text into the right hand window, it can lag by quite a lot.2018-12-27T22:06:43ZJackWhen typing in text into the right hand window, it can lag by quite a lot.This is prolly due to Meld trying to refresh all the time. Would be nice to either be able to disable that or have a timeout before refreshing, as well as being able to abort the refresh.This is prolly due to Meld trying to refresh all the time. Would be nice to either be able to disable that or have a timeout before refreshing, as well as being able to abort the refresh.https://gitlab.gnome.org/GNOME/meld/-/issues/245Comparison directory contextual information overly short2018-11-16T02:09:32ZIlija PavlicComparison directory contextual information overly shortOn multiple places in Meld GUI, the comparison directory is overly short:
* New comparison
* Open recent
* Selected folder in opened comparison
They all show just the "selected directory" or "[immediately preceding directory] select...On multiple places in Meld GUI, the comparison directory is overly short:
* New comparison
* Open recent
* Selected folder in opened comparison
They all show just the "selected directory" or "[immediately preceding directory] selected directory" combination.
Usually, the compared directories are "almost the same". For example, two locations containing the same project could be compared. In such situations, it's unclear what is on the left hand side and what is on the right hand side, because the UI elements will show exactly the same thing; "[immediately preceding directory] directory".
A full path would be preferable to prevent ambiguity.https://gitlab.gnome.org/GNOME/meld/-/issues/244meld cant display files with mtime=02019-01-01T15:34:21ZNorbert Langemeld cant display files with mtime=0To reproduce:
1. copy a directory
2. change mtime of a file with `touch -d @0 <somefile>`
3. meld both directories
the files with mtime=0 will be interpreted as missing. I use `mtime=0` commonly for reproducible builds, so this is a...To reproduce:
1. copy a directory
2. change mtime of a file with `touch -d @0 <somefile>`
3. meld both directories
the files with mtime=0 will be interpreted as missing. I use `mtime=0` commonly for reproducible builds, so this is annoying.
Meld Version is 3.18.2https://gitlab.gnome.org/GNOME/meld/-/issues/243Support network folder comparsions with Gio port2023-12-31T10:26:09ZGhost UserSupport network folder comparsions with Gio portI can't compare 2 folders in different servers, it would be really useful.I can't compare 2 folders in different servers, it would be really useful.https://gitlab.gnome.org/GNOME/meld/-/issues/242Meld 3.18 directory compare does not find differences when there are2018-11-29T23:15:17Zviolet4everMeld 3.18 directory compare does not find differences when there areMeld fails to see file differences in a directory compare under Ubuntu 18.04. I was comparing compat-wireless-2014-03-31/drivers/net/wireless/ath/ath5k/ and compat-wireless-2017-11-01/drivers/net/wireless/ath/ath5k/ and Meld said there ...Meld fails to see file differences in a directory compare under Ubuntu 18.04. I was comparing compat-wireless-2014-03-31/drivers/net/wireless/ath/ath5k/ and compat-wireless-2017-11-01/drivers/net/wireless/ath/ath5k/ and Meld said there were no differences. I tried from the GUI, and I tried from the command line with both relative and full paths. In all cases Meld found no differences in the directories. People I work with who use Fedora do not have this Meld problem - Meld reports differences between files in those same two directories.
Note - in the Ubuntu Software Manager comments for Meld, someone else has the same issue of directory compares falsely reporting no difference under Ubuntu 18.04. (Roger's comment says "Does not work. Ubuntu 18.04. Check carefully. Says directories are same, even when they contain different numbers of files.")https://gitlab.gnome.org/GNOME/meld/-/issues/241Zoom using Ctrl+Wheel2023-09-10T14:07:14ZGhost UserZoom using Ctrl+WheelHello,
Ctrl+Zoom would be a nice to have in Meld. Is it conceivable?
Gedit has the text-size plugin for this.
Related Gedit issue: https://gitlab.gnome.org/GNOME/gedit/issues/93
Maybe the problem is more general and a way to use Gedit ...Hello,
Ctrl+Zoom would be a nice to have in Meld. Is it conceivable?
Gedit has the text-size plugin for this.
Related Gedit issue: https://gitlab.gnome.org/GNOME/gedit/issues/93
Maybe the problem is more general and a way to use Gedit plugins in Meld would fix this more general issue.https://gitlab.gnome.org/GNOME/meld/-/issues/240Two form-feeds seem to confuse meld2021-03-13T02:01:30ZpkzcTwo form-feeds seem to confuse meldThe two consecutive FFs in the attached files make meld show the wrong lines as differing.
Remove one FF, and meld works well.
[mp3toc.txt](/uploads/239addc52b88cc07e88fc5c9f9b2e410/mp3toc.txt)
[old_mp3toc.txt](/uploads/4a49e747ff065361...The two consecutive FFs in the attached files make meld show the wrong lines as differing.
Remove one FF, and meld works well.
[mp3toc.txt](/uploads/239addc52b88cc07e88fc5c9f9b2e410/mp3toc.txt)
[old_mp3toc.txt](/uploads/4a49e747ff065361fb40ed149562f8d0/old_mp3toc.txt)
![Screenshot_at_2018-11-11_13-21-29](/uploads/a579b6eb0df5ac70e7e7b27fa147204e/Screenshot_at_2018-11-11_13-21-29.png)
![Screenshot_at_2018-11-11_13-27-36](/uploads/c3cdd6d5cef46b4e84e390faf2b52b6f/Screenshot_at_2018-11-11_13-27-36.png)https://gitlab.gnome.org/GNOME/meld/-/issues/239Failing to save modified files from MELD.2018-11-13T20:39:53ZGhost UserFailing to save modified files from MELD.Thank you for the great package.
I am using MELD on Debian GNU/Linux distribution.
It worked just fine until earlier this year.
However, today, when I tried to a comparison of a pair of directories and made changes to make them identica...Thank you for the great package.
I am using MELD on Debian GNU/Linux distribution.
It worked just fine until earlier this year.
However, today, when I tried to a comparison of a pair of directories and made changes to make them identical, and tried to save the modified files when I tried to close the tab and prompted to save files, MELD failed to save files [without any visible indication of the failures.]
The tab did not close and when I tried to close it again, I got the prompt to save the files again.
So one issue is that MELD fails to report the failure of saving file(s) in a visible manner using its GUI.
Funny, I thought. I experimented a little, and eventually I figured that the terminal window
where I originally invoked meld had these warning/error lines.
```
!meld
meld ~/repos/dot-files/ ~/
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/meld/meldwindow.py", line 542, in <lambda>
icon, "", lambda b: page.on_delete_event())
File "/usr/lib/python3/dist-packages/meld/filediff.py", line 841, in on_delete_event
response = self.check_save_modified()
File "/usr/lib/python3/dist-packages/meld/filediff.py", line 807, in check_save_modified
self.save_file(i)
File "/usr/lib/python3/dist-packages/meld/filediff.py", line 1495, in save_file
text = text.encode(encoding)
LookupError: unknown encoding: EUC-JP-MS
repetition of the above since I tried a few saving operations.
```
Obviously MELD seems to have failed to write the files.
My take is that somehow python3 run-time figures that the encoding of the files are
EUC-JP-MS and a function LookupError complained that it does not know anything about such encoding, EUC-JP-MS.
It could be either python issue or GNU/Linux distribution issue.
My take on this:
EUC-JP-MS seems suspicious (and looks too much Windows-specific?).
There *IS* an encoding called
EUC-JP (alias) under Linux for a looong time and some files I inherited over the years have this encoding.
```
grep -i euc /etc/locale.gen
ja_JP.EUC-JP EUC-JP
# ko_KR.EUC-KR EUC-KR
# zh_TW.EUC-TW EUC-TW
```
I suspect that the python3's text encoding detector misinterprest the particular file, ~/.emacs
in this case, as having this strange encoding EUC-JP-MS while it has the simple EUC-JP encoding.
(My .emacs file is close to 28 yars old. It has a few lines that mention a modification in 1991. Back then UNICODE is a future target and EUC-JP encoding was very popular in Japan.)
That it is encoded EUC-JP is clear since the next command executes successfully.
(Also I checked the file very carefully that it does not contain any suspicious characters that falls outside EUC-JP. See the note at the end.)
` iconv -f euc-jp -t utf8 .emacs`
What hould I do?
Not being able to use MELD for merging work hampers my workflow very much.
Thank you again for this great package.
PS: I found a web page that mentions EUC-JP-MS (the web page is in Japanese).
It mentions that EUC-JP-MS is an encoding devised by an industrial consorcium to handle EUC-JP character set under Windows and throwing some additional stuff.
In the diagram of the following URL, there are four different encodings. The diagram shows how each diagram covers the character sets.
The characters covered by the most popular EUC-JP (Non-Japanese characters such as characters covered by US ASCII and the Japanese characters covered by JIS X 0208) is the light blue area the minimalist set shared among the four encodings.
The right-most colum is EUC-JP-MS (or actually called euc_JP-MS). It adds some character set to the characters covered by EUC-JP in a certain manner.
Microsoft itself has devised CP51932 (the second leftmost column), and if someone mentions casually the encoding that supports EUC-JP under Windows, it is quite likely this CP51932 is intended implicitly. However, DO NOTE THAT IT does not handle the additional characters (outside the character set covered by EUC-JP) differently from other encodings such as EUC-JP-MS.
[https://msyk.at.webry.info/200511/article_2.html](https://msyk.at.webry.info/200511/article_2.html )
Well, after reading the above URL and considering the failure of MELD, I am afraid that python3's encode detection routine was written by someone who only understands Windows encodings and not realize that EUC-JP has been used widely under UNIX for a long time (preceding the usage by linux by almost 20 years) in the Japanese UNIX user community.https://gitlab.gnome.org/GNOME/meld/-/issues/238Cannot save modified file: g-io-error-quark2019-03-19T22:03:33ZGhost UserCannot save modified file: g-io-error-quarkWhen I try to save a changed file of a cifs share it fails due to renaming problem.
Direct error message of meld is: "Couldn't save file due to: g-io-error-quark: Error renaming temporary file: Invalid argument(13)".
Further message (t...When I try to save a changed file of a cifs share it fails due to renaming problem.
Direct error message of meld is: "Couldn't save file due to: g-io-error-quark: Error renaming temporary file: Invalid argument(13)".
Further message (that assumes it could be a renaming issue) is from the SMB server, which is an Alfresco JLAN implementation:
06 Nov 2018 15:06:10,956 ERROR [ncms.jlan.CmsJlanDiskInterface: 93] Fehler beim Überschreiben der Ressource (-> can't replace) "/system/modules/de.stuttgart.uni.v3.basics/elementviews/de.stuttgart.uni.v3.xml" mit der Ressource "/system/modules/de.stuttgart.uni.v3.basics/elementviews/.goutputstream-NCSLSZ".
org.opencms.file.CmsVfsException: Fehler beim Überschreiben der Ressource "/system/modules/de.stuttgart.uni.v3.basics/elementviews/de.stuttgart.uni.v3.xml" mit der Ressource "/system/modules/de.stuttgart.uni.v3.basics/elementviews/.goutputstream-NCSLSZ".
So the question is: who (meld?) deals with temporary .goutputstream-* files? I know that Alfresco libraries are quite old and
have problems with renaming operations. E.g. vi fails too as long as swap files are enabled.
Actually I use the latest KDE Neon (18.04), reproduced on Gentoo.https://gitlab.gnome.org/GNOME/meld/-/issues/237Add "line interval selection" based file diff feature2020-10-16T12:18:27ZpgpAdd "line interval selection" based file diff featureIt may happen the need to compare big code files, when the actual necessity is just to compare a few functions in these files (clearly, the files could differ -even a lot- in other parts, and we are not interested in these ones, this may...It may happen the need to compare big code files, when the actual necessity is just to compare a few functions in these files (clearly, the files could differ -even a lot- in other parts, and we are not interested in these ones, this may happen when doing refactoring or porting from legacy code). Without doing copy/paste into different files every time, a line interval selector in the diff view would be useful in order to allow comparing only relevant intervals of the two files (e.g. choosing lines l1 to l2 of file 1 to be compared against lines l3 to l4 of file 2).https://gitlab.gnome.org/GNOME/meld/-/issues/236Files appear crossed out during dir compare if epoch time is zero +1hr2018-11-14T19:39:22ZGhost UserFiles appear crossed out during dir compare if epoch time is zero +1hrWhilst comparing two directories I was surprised to see a file appear crossed out on both sides of the comparison! Turns out, the files both had a timestamp of 01-Jan-1970 01:00:00
Tested Meld 3.18.2 using:
```$ mkdir -p /tmp/meldtest/d...Whilst comparing two directories I was surprised to see a file appear crossed out on both sides of the comparison! Turns out, the files both had a timestamp of 01-Jan-1970 01:00:00
Tested Meld 3.18.2 using:
```$ mkdir -p /tmp/meldtest/dir1
$ cd /tmp/meldtest
$ touch -t 197001010100.00 dir1/file1.txt
$ touch -t 197001010100.01 dir1/file2.txt
$ cp -pr dir1 dir2
$ meld dir1 dir2
$ stat dir1/file1.txt
File: dir1/file1.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 801h/2049d Inode: 264782 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 2000/ pryan) Gid: ( 2000/ pryan)
Access: 2018-10-26 22:02:20.630622211 +0100
Modify: 1970-01-01 01:00:00.000000000 +0100
Change: 2018-10-26 22:02:09.598859080 +0100
Birth: -
$ stat dir1/file2.txt
File: dir1/file2.txt
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: 801h/2049d Inode: 264783 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 2000/ pryan) Gid: ( 2000/ pryan)
Access: 2018-10-26 22:02:20.630622211 +0100
Modify: 1970-01-01 01:00:01.000000000 +0100
Change: 2018-10-26 22:02:15.286736941 +0100
Birth: -
```
This is running on Ubuntu 18.04.1 on an Ext4 file-system, and I'm in BST timezone (+0100) which I mention in case that relates to it being unix epoch +1 hour and not just unix epoch.https://gitlab.gnome.org/GNOME/meld/-/issues/235UnicodeEncodeError/surrogates not allowed when comparing filenames with unusu...2018-10-27T23:04:30ZGhost UserUnicodeEncodeError/surrogates not allowed when comparing filenames with unusual encodingsWhen comparing dirs with unusual filename encodings, I get the following error:
`UnicodeEncodeError: 'utf-8' codec can't encode character '\udcf1' in position 64: surrogates not allowed`
Directory comparison then appears to end, the tre...When comparing dirs with unusual filename encodings, I get the following error:
`UnicodeEncodeError: 'utf-8' codec can't encode character '\udcf1' in position 64: surrogates not allowed`
Directory comparison then appears to end, the tree doesn't expand to show differences, and when I manually open the tree, many dirs appear empty presumably because comparison stopped early. The problem directory contains:
`-rw------- 1 pryan pryan 362 Jan 1 1970 'Ma'$'\361''anaDB.pdb'`
`-rw------- 1 pryan pryan 362 Jan 1 1970 MananaDB.pdb`
I experienced this problem on Ubuntu 18.04.1 using Meld 3.18.0, and I have since tested and experienced the same issue with Meld 3.18.2
(Not important, but I did wonder if the filename was the result of file corruption; turns out it was an intentional name part of the jPilot project but has since changed that file to use safer ASCII characters as mentioned here: http://jpilot.org/blog/release-1.8.2/)https://gitlab.gnome.org/GNOME/meld/-/issues/234Do not show shell appmenu under Unity2018-10-28T13:51:20ZKhurshid AlamDo not show shell appmenu under UnityOS: Ubuntu 18.10,
Meld Version: 3.18.0-6
Under Unity, Meld shows both the appmenu and the menubar (under unity menubar is exported to the panel).
![](https://i.imgur.com/8aXlOxY.png)
This can be filtered in meldapp.py:
```diff
--- a...OS: Ubuntu 18.10,
Meld Version: 3.18.0-6
Under Unity, Meld shows both the appmenu and the menubar (under unity menubar is exported to the panel).
![](https://i.imgur.com/8aXlOxY.png)
This can be filtered in meldapp.py:
```diff
--- a/meld/meldapp.py
+++ b/meld/meldapp.py
@@ -65,7 +65,8 @@
# TODO: Should not be necessary but Builder doesn't understand Menus
builder = meld.ui.util.get_builder("application.ui")
menu = builder.get_object("app-menu")
- self.set_app_menu(menu)
+ if not "Unity" in os.environ["XDG_CURRENT_DESKTOP"]:
+ self.set_app_menu(menu)
# self.set_menubar()
self.new_window()
```https://gitlab.gnome.org/GNOME/meld/-/issues/233wrong git command call2018-10-27T20:05:40ZGhost Userwrong git command callWhen there is an filename (or directory name) with the same name as some git branch name then meld produces error message on the console.
I have prepared small bash script which demonstrate the error:
```bash
#!/bin/bash
mkdir -p /tmp/...When there is an filename (or directory name) with the same name as some git branch name then meld produces error message on the console.
I have prepared small bash script which demonstrate the error:
```bash
#!/bin/bash
mkdir -p /tmp/demo/server
cd /tmp/demo/server
git init
echo "foo" >foo
git add *
git commit -m "foo"
git checkout -b foo
cd ..
mkdir workdir
cd workdir
git clone file:///tmp/demo/server .
meld .
```
After executing this script the following error message appears in terminal window:
```
fatal: ambiguous argument 'foo': both revision and filename
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
```
I'm using meld 3.18.2 on Gentoo linux.https://gitlab.gnome.org/GNOME/meld/-/issues/232[feature] Directory Comparison File Filter: match against relative path2018-10-27T22:07:12ZGhost User[feature] Directory Comparison File Filter: match against relative pathCurrently, it is not possible to have a filter entry that matches against a specific subdirectory tree, as the match/filtering is performed just against the directory entry
https://gitlab.gnome.org/GNOME/meld/blob/master/meld/dirdiff.py...Currently, it is not possible to have a filter entry that matches against a specific subdirectory tree, as the match/filtering is performed just against the directory entry
https://gitlab.gnome.org/GNOME/meld/blob/master/meld/dirdiff.py#L774-777
So, a filter like `some/sub/dir/*` will never match
The relative path should be to the start folder of the directory comparison (like .gitignore)https://gitlab.gnome.org/GNOME/meld/-/issues/231No Preferences menu on ubuntu2018-10-20T07:36:51ZGhost UserNo Preferences menu on ubuntuHello,
As mentioned in https://gitlab.gnome.org/GNOME/meld/issues/186#note_115927, I also don't see the Preferences menu.
I have ubuntu 16.04 with gnome shell, meld 3.14.2.
But I also tried with versions 3.16.4, 3.17.4, 3.18.2 for the ...Hello,
As mentioned in https://gitlab.gnome.org/GNOME/meld/issues/186#note_115927, I also don't see the Preferences menu.
I have ubuntu 16.04 with gnome shell, meld 3.14.2.
But I also tried with versions 3.16.4, 3.17.4, 3.18.2 for the source directory, and no Preferences menu anywhere..
Can you help me track the issue ?
Thanks a lot !https://gitlab.gnome.org/GNOME/meld/-/issues/230Mac mojave update2019-05-06T12:11:28ZGhost UserMac mojave updatenot working in mac update of Mojave.
even not getting closed need to force stop itnot working in mac update of Mojave.
even not getting closed need to force stop ithttps://gitlab.gnome.org/GNOME/meld/-/issues/229Allow enable/disable the display of file line numbers2018-10-05T19:16:06ZGhost UserAllow enable/disable the display of file line numbersAdd the ability to enable/disable the display of file line numbers.Add the ability to enable/disable the display of file line numbers.https://gitlab.gnome.org/GNOME/meld/-/issues/228"No Disk" Error pops up when opening Meld in Windows 72020-06-06T16:46:31ZGhost User"No Disk" Error pops up when opening Meld in Windows 7Sorry if this is the wrong place for MS Windows-related bugs but I couldn't find anywhere else to report this.
I have been using Meld under Ubuntu for years but I just now tried installing it under Windows 7 (64 bit), more out of curios...Sorry if this is the wrong place for MS Windows-related bugs but I couldn't find anywhere else to report this.
I have been using Meld under Ubuntu for years but I just now tried installing it under Windows 7 (64 bit), more out of curiosity than for any other reason. For Windows, I normally use a paid version of Araxis Merge and was wondering whether I could use Meld instead.
Every time I open the program, I get a "No Disk" error (![melderror](/uploads/1be390b37b3c5fe972c1fb73f85ad935/melderror.jpg)).
I couldn't find anywhere in the preferences menu that might explain this behaviour.
Oh well.
Allan