Re: Windows support

[Vincent Legoll <vincent legoll gmail com>]

On Wed, Apr 15, 2009 at 10:57 AM, Stephen Kennedy <stevek gnome org> wrote:
>> No sf.net account, I like meld.sf.net though, clean & simple...
>
> Yes, I'd like to keep the meld.sf.net address, especially since
> it has been around for so long. Maybe just embed the wiki page
> into the sf.net one?

Adding a menu entry that link to the wiki would do it easily.

>> I would love to get rid of the dialog for "no match found"
>> Dialogs are evil !
>
> Agreed, I've added it to the todo.

Cool thanks.

>> - toggling VC filtering buttons change multiVC combobox
>>  back to the first VC plugin, which is counter intuitive, but
>>  that may be hard to fix cleanly.
>
> Ah, because of toggled->refresh->set_location->choose_vc
> How about storing the last chosen vc name in vcview? Then
> choose vc can default to that one next time. It might even
> be worth persisting in preferences (but no gui for it).

I've thought of that, and wanted to have other's opinions before
starting to do it. I'll look at it then.

An implementation detail, though... You ultimately would like
VC choice persistence to be per-location, wouldn't you ?

>> - I've reproduced bug 578303 and tested proposed patches
>>  looks OK, highlighting diffs at EOF (particularly \n) is fixed
>>  by the first patch. Code looks right (I don't know the
>>  internals of diffutils.py at all)
>> - I'd change the default value for the "automatically provide
>>  \n at EOF" preference, with the same rationale as for "ignore
>>  change that insert or delete withespace": Default to show
>>  everything that changed unless asked not to. Like the
>>  attached.
>
> OK, these two go together - the preference was a hack because
> of the strange boundary behavior of gtktextview at the eof. Also
> c++ (and maybe more languages) insists that the last char in a
> file is "\n". As you say though, it should be an opt-in preference.

Eh, reproducing the bug & testing it fixed made me think about that
preference as related, so I checked the patch with/without the option
checked. And then thought about that default behavior thing we
discussed in the other thread...

On the C++ need for \n at EOF, this would hold if meld actually
modified the file content to then have the added \n and saved it,
but I looked at the code, and it does not seem to do that...

I even thought that this should be implemented by a file content filter
regex instead of a particular preference. But first filters that change
the numbers of lines should be made to work... Or do they ?

So what do we do ?

Are we including the patch (first one) if somebody else checks that
it fixes the bug. And then ditch the hack-preference ?

The second patch I don't understand, and the description in the bug
report does not help, we'll need better than that for a commit log
I think. I forgot to ask the reporter to clarify that...

-- 
Vincent Legoll