Re: Meld 3.11.3

[Kai Willadsen <kai willadsen gmail com>]

On 27 August 2014 20:02, Kai Willadsen <kai willadsen gmail com> wrote:
> On 25 August 2014 22:22, Angel Ezquerra <angel ezquerra gmail com> wrote:
> > I believe I could open these files with Meld 1.8. I can open them fine
> > with every text editor I've tried. I don't think meld should expect
> > the files to be in a particular encoding. This problem is so serious
> > that I cannot use this version of meld at all.

See below for the workaround.

<snip>
> > 2. I cannot get syntax highlighting to work (tab completion was
> > disabled on the preferences by default, but enabling it did not fix
> > the problem).
>
> I'm not sure why syntax highlighting isn't working, but we've
> definitely never supported tab completion.

I'm pretty sure that syntax highlighting is not working for the same
reason as Open Externally. I suspect that we're not getting the MIME
type back from gio, and therefore can't set the highlight language.

> > The reason is that TortsoiseHg expected to find an entry on the
> > registry that would tell it where to find the meld executable (either
> > "SOFTWARE\Meld\Executable" or "SOFTWARE\Wow6432Node\Meld\Executable").
> > It is possible to manually fix this problem since you can tell
> > TortoiseHg the exact location of meld. Also, I am a member of the
> > TortoiseHg team, so we can change that so that TortoiseHg looks for
> > the meld executable by location (in
> > "${ProgramFiles(x86)}/Meld/meld.exe"), but having a registry entry (as
> > many other diff tools on windows do) seems better, since it would let
> > the user install Meld somewhere else.
<snip>

So that registry path seems to be something that Keegan provided in
the old bundle. I'm okay with trying to reproduce that, but is there a
standard place to put this information on Windows?

<snip>
> On Windows, this is equivalent to running 'start <path>'. According to
> a comment I don't remember writing, file type detection with gio on
> Windows is broken, so if you're expecting to see some more specialised
> behaviour then that could be the issue.

Yeah I think this is the problem. Open Externally works fine on
Windows for directories (because we don't try to find the file type)
but apparently something weird happens for other files, even though we
try to fall back. I'll investigate in case it's an easy fix.

> You should be able to 'fix' this manually by setting the
> (unsupported!) gsettings key at /org/gnome/meld/detect-encodings to
> ["utf8", "latin1"] or similar. I don't actually know how to do this on
> Windows however. I believe that gsettings on Windows backs on to the
> registry, but can't tell you anything else about it.

At the key HKEY_CURRENT_USER\Software\GSettings\org\gnome\meld, try
adding a SZ value of detect-encodings with data ['utf-8', 'latin1']. I
haven't tested this but I imagine it should work.

cheers,
Kai