Re: Passing a single directory or file to meld

[Kai Willadsen <kai willadsen gmail com>]

On 20 March 2013 20:40, Angel Ezquerra <angel ezquerra gmail com> wrote:
> On Tue, Mar 19, 2013 at 10:13 PM, Kai Willadsen <kai willadsen gmail com> wrote:
> > There's no way around this, and I'd rather not add more command line
> > options if we don't have to. I've seen this dealt with on Gnome +
> > Nautilus by having an extension that allows you to queue up items for
> > comparison. See for example:
> >     http://my.opera.com/bachkhois/blog/2011/07/19/compare-files-with-meld-from-within-nautilus
>
> That is similar to what Araxis Merge does and it works very well. The
> drawback is that, as you said, it requires to write an explorer
> extension.

Right, but the drawback for doing anything else is that I have to
write and maintain the code and ABI forever more. And in the end, the
result will still be significantly less useful than an explorer
extension.

> > I have no idea what the limitations of the Windows 'Send To' command
> > or explorer extensions are. Would it be possible to have some kind of
> > similar queuing implementation there?
>
> The nice thing about the "Send to" menu is its simplicity. You simply
> add a shortcut to your executable in the "SendTo" directory (which is
> in "%userprofile%\SendTo" in WindowsXP and in
> "%APPDATA%\Microsoft\Windows\SendTo" in Windows 7) and the shortcut
> appears in your Windows Explorer context menu.
>
> When you right click on a file and select a SendTo entry it will
> simply execute the program that the shortcut points to and pass the
> name of the file as its only parameter. If you need more parameters
> you can set them on the shortcut itself.
>
> So with a SendTo shortcut you can only pass one or more files or
> directories, and they must be on the same directory because you cannot
> select files or directories from different directories using Windows
> Explorer.

So it's identical to having multiple open commands? In that case why
not just make an open command that does what you want?

> > Either way, the problem is that giving Meld a single directory is
> > inherently ambiguous. You'd have to have "Send To -> Meld as folder
> > comparison" and "Send To -> Meld as VC comparison" entries, which
> > seems like overkill to me.
>
> I think this is precisely a very good reason why I think melds needs
> to let the user tell it what to do. Since the operation is ambiguous,
> meld should not have to guess. Currently it always "guesses" that the
> user wants to do a VC comparison, which is not useful if you do not
> want to use the VC functionality of meld (as in my case).

Unfortunately, that's because you're trying to do something that's a
very minor use case. Meld's VC functionality is the *most common way*
that comparisons are launched with Meld (other than direct
invocations, or VC-initiated merges).

> Another use case for being able to open a diff with a single file is
> when you want to compare a file with some text that you want to write
> or perhaps when you want to compare a file with what you have on the
> clipboard. Sometimes you may want to compare two parts of a file using
> copy/paste, for example. This is something that I often do, and which
> is easy to do with many diff tools (e.g. araxis, WinMerge) but is not
> possible (or not easy) with meld.

I don't see how your proposal would help with that at all. We already
support starting blank comparisons for files; for folder comparisons
we sort-of do, but the fallback for missing directories means that it
doesn't necessarily do what you'd expect.

> So I think it would be great to have a way to tell meld to open "an
> empty comparison" or to diff a single file with an "empty file" that
> you may edit yourself (by typing, using copy paste, etc).

You can already do this. You can start a comparison with only one
entry by just passing a second empty entry, e.g.,
meld directory/whatever ""

> It seems
> that this would require an extra command line option, but in this case
> it seems that there would be a good reason to do so.

I really don't see what you would expect to happen in this case that
is a significant improvement in terms of work flow. Maybe you could
give an example of what the user would see?

cheers,
Kai