meld issueshttps://gitlab.gnome.org/GNOME/meld/-/issues2024-03-23T04:33:44Zhttps://gitlab.gnome.org/GNOME/meld/-/issues/831Add support for .rtf files2024-03-23T04:33:44ZJonathan BergenAdd support for .rtf filesI work with a lot of rtf templates and would like to use Meld to view the changes instead of switching diff tools for specific files.
Is there a current format that would work for these types of files? If not, could someone familiar wit...I work with a lot of rtf templates and would like to use Meld to view the changes instead of switching diff tools for specific files.
Is there a current format that would work for these types of files? If not, could someone familiar with Meld's architecture reach out to me? I have the time to add this feature, but need an introduction.
Thanks,
Jonathanhttps://gitlab.gnome.org/GNOME/meld/-/issues/817[Feature Request] "Save diff as..."2023-12-31T20:52:09ZFranky[Feature Request] "Save diff as..."This Feature Request is similar to https://gitlab.gnome.org/GNOME/meld/-/issues/674 but in the other way around, sometimes when you have checked how 2 files/directories are different, you may want to save that difference as a .diff or .p...This Feature Request is similar to https://gitlab.gnome.org/GNOME/meld/-/issues/674 but in the other way around, sometimes when you have checked how 2 files/directories are different, you may want to save that difference as a .diff or .patch file.
That would be very useful if in the menu, next to "Save as...", there would be a "Save diff as...".https://gitlab.gnome.org/GNOME/meld/-/issues/812Provide a way to switch between 2-way and 3-way diff2023-12-10T22:17:42Zxmo-odooProvide a way to switch between 2-way and 3-way diffI often use Meld for ad-hoc visual comparisons between all sorts of items (e.g. logs, bits of code, text, ...). It is quite good and proficient at that, however it does not seem to provide an easy way to "convert" a 2-way comparison to a...I often use Meld for ad-hoc visual comparisons between all sorts of items (e.g. logs, bits of code, text, ...). It is quite good and proficient at that, however it does not seem to provide an easy way to "convert" a 2-way comparison to a 3-way one. That would be very useful, as it's quite common for an initial 2-way comparison to lead to some modifications, and wanting to show a third option.https://gitlab.gnome.org/GNOME/meld/-/issues/791Ability for Meld to monitor and notify about external changes in folders' con...2023-09-10T14:16:23ZZambet PentruAbility for Meld to monitor and notify about external changes in folders' contentsIt would be great if Meld could track changes to source file systems so that as files are updated the UI shows these files have changed / are now equal.It would be great if Meld could track changes to source file systems so that as files are updated the UI shows these files have changed / are now equal.https://gitlab.gnome.org/GNOME/meld/-/issues/779File filters are inconsistent2023-08-06T04:00:30ZDonjan RodicFile filters are inconsistentRunning Meld 3.22.0 from the GitHub release page.
In a directory comparison, the `File Filters` are grouped in two categories.
**Observed Behaviour**
`File Status` entries such as `Modified` will show changed files when checked, and h...Running Meld 3.22.0 from the GitHub release page.
In a directory comparison, the `File Filters` are grouped in two categories.
**Observed Behaviour**
`File Status` entries such as `Modified` will show changed files when checked, and hide (filter) them when unchecked.\
`Filename` entries such as `Media` will hide (filter) media files when checked, and show them when unchecked.
**Expected Behaviour**
The entries should filter out files consistently by their check status, either way.
**Additional Info**
I'm sure the maintainers are aware of the discrepancy between these groups, and users quickly learn by trial and error. But I didn't find any related issue, and think it merits one because it's unintuitive and inconsistent.https://gitlab.gnome.org/GNOME/meld/-/issues/768meld oversees a difference in two folders, when one contains a symlink to /de...2023-06-03T23:01:16ZChristoph Anton Mitterercalestyo@scientia.orgmeld oversees a difference in two folders, when one contains a symlink to /dev/nullHey.
I've just noted this by accident with meld 3.22.0 on Debian:
Reproducer:
```
$ mkdir a b
$ echo foo > a/bar
$ echo foo > b/bar
$ ln -s /dev/null a/symlink-to-dev-null
```
```
$ meld a/ b/
```
claims `Folders have no differences`.
...Hey.
I've just noted this by accident with meld 3.22.0 on Debian:
Reproducer:
```
$ mkdir a b
$ echo foo > a/bar
$ echo foo > b/bar
$ ln -s /dev/null a/symlink-to-dev-null
```
```
$ meld a/ b/
```
claims `Folders have no differences`.
While e.g. `diff` correctly finds:
```
$ diff -qr --no-dereference a/ b/
Only in a/: symlink-to-dev-null
```
Thanks,<br>
Chris.https://gitlab.gnome.org/GNOME/meld/-/issues/756Feature Suggestion: Incorporate Difftastic as an optional diff generator2023-08-08T01:24:49Zthe-moogFeature Suggestion: Incorporate Difftastic as an optional diff generatorI was comparing a library somebody had forked and gone and changed almost every line :anguished: but, so far as I can tell, actually not made that many changes.
So to find the actual functional differences, I was wondering if a diff too...I was comparing a library somebody had forked and gone and changed almost every line :anguished: but, so far as I can tell, actually not made that many changes.
So to find the actual functional differences, I was wondering if a diff tool existed that actually had a basic understanding of the syntax (C++ in my case) rather than just comparing letters. Other than simply ignoring whitespace I can see that Meld does not yet have that feature.
Well there is a project that does! And it is written in Rust and would probably be easy to meld (sorry) into Meld
as I understand it is not that difficult to link and call between the two (Though I don't know Rust, yet, so I can't comment on that WRT Meld's code).
Difftastic is a diff generator that as well as performing a normal textual diffs, it can make use of the Abstract Syntax Tree (AST) so that it compares the actual logic and function of syntax, rather than just the text. That way it can ignore differences in just formatting and allow people to spend less time being distracted or being forced to uuse a prettyfy tool. Difftastic supports a large number of languages (From Ada to Zig) and text data (e.g. YAML, HTML, etc)
See [Difftastic Repo](https://github.com/Wilfred/difftastic)https://gitlab.gnome.org/GNOME/meld/-/issues/747Allow handling melding a sparse "files-from" like file subset into a destinat...2023-03-25T03:30:53ZChris HAllow handling melding a sparse "files-from" like file subset into a destination source repo which is expensive (slow) to crawl looking for destination content not among the source subset.Enhancement suggestion, allow handling melding a sparse "files-from" like file subset into a destination source repo which is expensive (slow) to crawl looking for destination content not among the source subset.
So I've got a DESTINATI...Enhancement suggestion, allow handling melding a sparse "files-from" like file subset into a destination source repo which is expensive (slow) to crawl looking for destination content not among the source subset.
So I've got a DESTINATION as a megarepo of code as a destination of a desired meld merge; that repo mirror is non-local and lazily loaded (copied over network) when any directory/file is accessed which can be slow.
As a SOURCE of stuff I want to meld I've got a very sparse subset of scattered files / directories which were e.g. copied out of that mega-repo because they were modified using something like a selective tar or rsync with an explicit "files-from" list for just the interesting / changed files to be "stashed" / exported etc. There could be many different sparse parts of the megarepo tree included in the SOURCE files which I've copied out and want to meld FROM out TO the network repo mirror.
So if both the sparse source tree and the megarepo start with some path like ...something.../myrepo e.g
SOURCE to meld: ~/mysubset_copy/myrepo/...
DESTINATION to meld: /mnt/megarepo/myrepo/...
If just running `meld ~/mysubset_copy/myrepo /mnt/megarepo/myrepo`
I believe it'll basically crawl the `/mnt/megarepo/myrepo` tree looking for different stuff not appearing in `~/mysubset_copy/myrepo`
and conversely as well. But the former operation is far too slow to be considered (maybe millions of files over a slow network, think of something like AOSP or whatever) and is not necessarily desirable if the use case is a unidirectional meld
FROM SOURCE to DESTINATION.
So I don't know what UI/UX encapsulation might be interesting to the project to consider ameliorating this sort of use case but it feels like there might be some enhancement that could allow say omitting certain directories from consideration or more particularly constraining the differencing to ONLY files/directories listed on either the LHS (e.g. SOURCE) or RHS (e.g. destination) and maybe their children (selectively?) and NOT a bilateral difference.
I guess this sounds like a somewhat niche case relating to huge repos that are expensive to crawl but I think maybe there could be
much more general utility in some possible enhancements which could address this as a sub use case, for instance a way to label one side of the meld as immutable so it'd be uninteresting / impossible to meld anything from the right side to the left side so no point necessarily to crawl the right side if files / directories appear there not already on the left etc.
Just sharing an idea; thanks for the great tool / work!https://gitlab.gnome.org/GNOME/meld/-/issues/730git differences: consider renamed files2022-12-18T01:20:16ZChristoph Anton Mitterercalestyo@scientia.orggit differences: consider renamed filesHey.
Not sure if that would even be possible, but meld is used with `git` (e.g. `git difftool -d`) and when a file is renamed there (`git mv`) optionally, with further changes in the file... then git tries to determine such renamed file...Hey.
Not sure if that would even be possible, but meld is used with `git` (e.g. `git difftool -d`) and when a file is renamed there (`git mv`) optionally, with further changes in the file... then git tries to determine such renamed files and also output that in e.g. `git diff` like so:
```
$ git diff --staged
diff --git a/bla b/foo
similarity index 80%
rename from bla
rename to foo
index 9405325..e006065 100644
--- a/bla
+++ b/foo
@@ -1,5 +1,4 @@
a
b
-c
d
e
```
(not the `similarity index 80%`).
Right now, `meld` shows such a rename as deleted file on the left side and added on the right side (actually both in green colour,... whereas I think on the left side it should be red?).<br>
It would be cool if `meld` could realise that and indicate that the files are renamed, perhaps with another colour (orange?).<br>
If it's not just renamed, but also has changes in the content, the colour highlighting of the files could be orange/blue hatched (with the same blue that's used now for indicating changes)?
Also, right now such files are not displayed in the "same line".<br>
I guess there would be several ways to improve that:
* If the renamed files are still in the same folder, an option could allow users to choose whether for one side the file is simply moved to another place, so that it's "right next" to its counterpart on the other side. Of course this would break the alphabetical ordering.
When it's not configurable to choose which side would be "moved", it should IMO be the left one.
* If files are however in a different directory, the moving no longer works. In that case the following could be done: If the renamed file is selected on either side, there could be some line or so, that connects it on both sides, so that one can - if desired - easily find its counterpart.
Oh and last but not least... unless that can be somehow read from the git config (and beware, that reading the git config may allow for remote code execution attacks, when embedded bare repos are considerd), it would be nice if one could set a threshold for the similarity index.
Thanks,
Chris.https://gitlab.gnome.org/GNOME/meld/-/issues/716Fullscreen mode should have a toolbar for exit handling2023-12-31T21:36:26ZEloi TorrentsFullscreen mode should have a toolbar for exit handlingI want to use meld in the pinephone. It was working great until I enabled fullscreen mode. I was unable to quit it (it covers the screen keyboard), and after restarting meld it kept appearing in fullscreen mode.
I tried to delete the ~/....I want to use meld in the pinephone. It was working great until I enabled fullscreen mode. I was unable to quit it (it covers the screen keyboard), and after restarting meld it kept appearing in fullscreen mode.
I tried to delete the ~/.local/share/meld without luck.
At the end I faked the key combination "Super+F" using wtype.
I would appreciate if it were easier to exit full screen.https://gitlab.gnome.org/GNOME/meld/-/issues/677please show difference counts when diff'ing files2022-06-06T05:45:52ZJason Perezplease show difference counts when diff'ing filesMeld does not show difference counts in the GUI when looking at diffs between two files. I find this lack of info holding me back from using meld all the time. While the GUI lets you cycle thru the differences, it would be really helpf...Meld does not show difference counts in the GUI when looking at diffs between two files. I find this lack of info holding me back from using meld all the time. While the GUI lets you cycle thru the differences, it would be really helpful to know HOW many differences there are. If it's a jillion, then cycling thru the diffs is either pointless or would take a very long time. If not, then I know how many I'll be clicking thru and if I make some changes in one of the files and then Refresh I should see the diff count reduced.https://gitlab.gnome.org/GNOME/meld/-/issues/662Custom labels are no longer visible by default2022-04-10T01:08:43Zphp fanCustom labels are no longer visible by defaultI use meld in Tortoise HG.
I have Totroise HG configured to use meld as the resolve tool and as the 3-way diff.
This issue is about the 3-way diff.
I have no idea how you'd use Meld outside of THG.
In Tortoise HG what I do is:
- I do a ...I use meld in Tortoise HG.
I have Totroise HG configured to use meld as the resolve tool and as the 3-way diff.
This issue is about the 3-way diff.
I have no idea how you'd use Meld outside of THG.
In Tortoise HG what I do is:
- I do a merge. There are conflict
- I resolve the conflict with whatever tool
- I review and edit the merged version by clicking the "3-way diff" button which launches Meld showing a 3way diff.
So that launches Meld and shows a 3-way diff where on one side there is the working-directory version, on the opposite side there is the "other revision" version (the one that I am merging into the working directory), and in the center the proposed merged version.
The issue is: **I have no clue which one (left or right)** is the working directory version and which one is the "other revision" version.
At the top of each there is a file path, but that doesn't help because both paths are like /tmp/some-numbers-and-shit/whatever/filename.xml and I don't know how to interpret those.
It used to be the case that somewhere at the top (I seem to remember in the window title bar) it used to read "local -- current -- other", or something like that, or of course viceversa. While not the most intuitive thing in the world, that was enough for me to know which one was what.
Now that hint is no longer there.https://gitlab.gnome.org/GNOME/meld/-/issues/658Header unnecessarily short2022-08-11T23:30:26ZCefn HoileHeader unnecessarily shortIn the primary diff view, the headers showing the path of files are unnecessarily limited in length. There is huge space both left and right, and the file path actually shown is humorously truncated.
Practically speaking, looking at th...In the primary diff view, the headers showing the path of files are unnecessarily limited in length. There is huge space both left and right, and the file path actually shown is humorously truncated.
Practically speaking, looking at the file diff below I've no idea what package it's for because there is no directory information. There are 6 jest configs, one for each package in my repository.
![image](/uploads/4ee24457f9e5570f7cb21602a6f2a553/image.png)https://gitlab.gnome.org/GNOME/meld/-/issues/657Enhancement: file name optional when directory is given2022-03-04T23:19:51ZvrossumEnhancement: file name optional when directory is givenGiven files
./dir1/x and ./dir2/x
With traditional 'diff' you can call
diff dir1/x dir2
It then infers to do
diff dir1/x dir2/x
This is very helpful when comparing code across directories.
It would be great if meld could do the sam...Given files
./dir1/x and ./dir2/x
With traditional 'diff' you can call
diff dir1/x dir2
It then infers to do
diff dir1/x dir2/x
This is very helpful when comparing code across directories.
It would be great if meld could do the same thing.
PS Great piece of software!https://gitlab.gnome.org/GNOME/meld/-/issues/650[Feature Request] Add option to "lock" the right side in diff mode, only allo...2022-01-30T20:15:25ZDavid Dean[Feature Request] Add option to "lock" the right side in diff mode, only allowing merge operations from right-to-leftWould it be possible to add a feature to Meld in diff mode where the "right" side could be "locked", so operations are only permitted from right to left?
I’m using Meld to compare my current git branch (left) with another branch (right)...Would it be possible to add a feature to Meld in diff mode where the "right" side could be "locked", so operations are only permitted from right to left?
I’m using Meld to compare my current git branch (left) with another branch (right) and selectively pull in changes to my active branch.
It is easy to forget that the right side should be left unchanged, and I accidentally perform operations from left to right.
It would be better if a parameter could be added, such as "--lock-right" which gives a view similar to the git conflict view where changes from left to right are prevented with a padlock symbol.
This would make it visually very clear that operations can only be performed from right to left, and avoid any possible changes to the right.
For reference, I am checking out my active branch (left) then doing git difftool against the reference branch (right) which is the one I want to be read-only in Meld:
`git difftool -d referencebranch`
This is my .gitconfig:
```
[diff]
tool = meld
[difftool]
prompt = false
[difftool “meld”]
cmd = meld “$REMOTE” “$LOCAL” --auto-compare
```
Thank you for your consideration! :smile:https://gitlab.gnome.org/GNOME/meld/-/issues/638Add filters to name diff2022-01-30T21:58:21ZDan BAdd filters to name diffI am comparing files on a local drive to files across a shared network. When there are characters like vowels with accents, they are seen as different. I am able to copy the files so they are both in the same folder at the same time, so ...I am comparing files on a local drive to files across a shared network. When there are characters like vowels with accents, they are seen as different. I am able to copy the files so they are both in the same folder at the same time, so they appear to actually use a different character, although they look identically the same. At the moment I'm trying to confirm this by listing the file names in hex or something, but I don't have a solution for that yet. Tile files were copied from each other, so I'm not sure if it's the drive format or the network transfer that caused the name change. However, ignoring these differences would be beneficial.https://gitlab.gnome.org/GNOME/meld/-/issues/637[Feature Request] Hotkeys for user actions (run program for current file and ...2021-12-30T21:48:32ZStanislav Berkov[Feature Request] Hotkeys for user actions (run program for current file and selected line)Implement ability to specify hotkeys for user commands. In Beyond Compare there is such functionality. You can specify hotkey and program/command to run. You can specify command line arugments such as file name, line number. We use such ...Implement ability to specify hotkeys for user commands. In Beyond Compare there is such functionality. You can specify hotkey and program/command to run. You can specify command line arugments such as file name, line number. We use such functionality to report codeview issues. User opens folder diff in diff-tool. Locates file, set cursor on a line and press Alt+K. As a result issue input box pops up.
![image](/uploads/009e0e2a2368ceaa737fba84dd9911a5/image.png)
(beyond compare configuration)
![image](/uploads/51d7c80f5dee34b3691e56c5aff753be/image.png)
(issue logging tool that received context from diff-tool)https://gitlab.gnome.org/GNOME/meld/-/issues/620No obvious visual indication that Diffing is done.2022-01-08T23:42:40ZDavid ChalcoNo obvious visual indication that Diffing is done.Running Meld (v3.20.2) on Ubuntu (20.04.2) VM.
Had a home LAN device FS mounted to my Ubuntu VM via `sshfs`.
Diffed a local HDD dir with a dir on said net-mounted partition.
Due to this, the diff was taking exceptionally long (> ~7m).
A...Running Meld (v3.20.2) on Ubuntu (20.04.2) VM.
Had a home LAN device FS mounted to my Ubuntu VM via `sshfs`.
Diffed a local HDD dir with a dir on said net-mounted partition.
Due to this, the diff was taking exceptionally long (> ~7m).
After selecting the two dirs to diff, it shows the first-level dirs as though it's done diffing, even though it's not necessarily done.
So I blindly thought that, "Oh, great, I can propagate diffs now" because there was NO obvious indications that the diff was NOT complete.
I blindly trusted Meld, and wasted ~5hrs because I was fooled into thinking my two dirs had no diffs, when in reality they DID have diffs but I didn't get to see them because it was taking exceptionally long. Bad customer experience.https://gitlab.gnome.org/GNOME/meld/-/issues/614Top buttons and screen edges, Fitts's law2022-08-15T15:26:11ZDrake HenfordTop buttons and screen edges, Fitts's lawI am using Meld 3.21.0 on KDE, and for quite some time now, I noticed the menu bar UI changed to a more "modern, touchy interface".
Here's how I remember it:
![meld-old](/uploads/653ae85576eab5b2ba984b0e026d2567/meld-old.png)
And her...I am using Meld 3.21.0 on KDE, and for quite some time now, I noticed the menu bar UI changed to a more "modern, touchy interface".
Here's how I remember it:
![meld-old](/uploads/653ae85576eab5b2ba984b0e026d2567/meld-old.png)
And here's now (top right corner):
![Screenshot_20210906_113302](/uploads/04592a4868e256e8e9b5c3d1cea8977a/Screenshot_20210906_113302.png)
The main issue I have is that the new layout does not allow the buttons to reach the screen edge, making them much harder to click, according to [Fitts's law](https://en.wikipedia.org/wiki/Fitts%27s_law). [This website](https://www.interaction-design.org/literature/article/fitts-s-law-the-importance-of-size-and-distance-in-ui-design) mentions why it's useful to do so:
> 2. The outer edges and corners of the graphical user interface can be acquired with greater speed than anywhere else in the display, due to the pinning action of the screen. As the user is restricted in their movements the pointing device cannot move any further when they reach the outermost points of the screen; fixing the cursor at a point on the periphery of the display.
Also, since all other windowed applications I use *do* respect it, Meld ends up breaking [consistency](https://www.nngroup.com/articles/consistency-and-standards/), which is doubly bad: I have to remember every time that, only when using Meld, I have to actually look for the button and click it.
Is there a way to make the buttons clickable on the screen edge? Either removing the top/right margin, or changing the UI to a "traditional desktop" one?https://gitlab.gnome.org/GNOME/meld/-/issues/604[FeatureRequest] .meldignore2022-04-06T10:28:21Zloynoir[FeatureRequest] .meldignore### background
Meld is really awesome.
But the only ignore filter meld accepted, as I know, is thru dconf, which is not so convenient, and can't do that per project
### Motivation
**git** accept `$HOME/.gitignore` + `<proj>/.gitignore`...### background
Meld is really awesome.
But the only ignore filter meld accepted, as I know, is thru dconf, which is not so convenient, and can't do that per project
### Motivation
**git** accept `$HOME/.gitignore` + `<proj>/.gitignore`
**prettier** defaults to `<proj>/.prettierignore`, and can custom by
```sh
prettier --ignore-path <proj>/myconfigs/$PROFILE.prettierignore
```
**fd-find**, a damn fast gnu-find [replacement](https://github.com/sharkdp/fd), defaults to `$HOME/.gitignore` + `<proj>/.gitignore` + `<proj>/.fdignore`, and can custom by
```sh
fd --ignore-file=<proj>/myconfigs/$PROFILE.fdignore
```
**the_silver_searcher**, aka [ag](https://github.com/ggreer/the_silver_searcher), a damn fast code searcher, defaults to `$HOME/.gitignore` + `<proj>/.gitignore` + `<proj>/.hgignore`, and can custom by
```sh
ag -p <proj>/myconfigs/$PROFILE.agignore
```
### feature request
It would be nice, if meld can accept a per project filter file from command line.
```sh
meld --ignore-path path/to/name.meldignore <Dir1> <Dir2>
```
And defaults to `<HOME>/.meldignore` + `<CWD>/.meldignore` or something else.