[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: TortoiseMerge line breaks request

From: Oto BREZINA <otik_at_printflow.eu>
Date: Thu, 05 May 2011 10:31:27 +0200

On 2011-05-05 09:46, Hans-Emil Skogh wrote:
>>> Would it be possible to let TortoiseMerge make a somewhat more
>>> informed decision on where to break long lines? Right now I see
>>> some files where a long line is broken differently in the left
>>> and right pane, and therefore getting a lot of false differences.
>> Wrapping/braking lines should not affect diff engine, however it
>> may make visual differecting harder.
> Yes. Pretty much the whole point of having a visual diff tool like TortoiseMerge is to make visual differencing easier, not harder. :-)
I agree, but diffing single looong line is not primary use case, or?
Just wonder, what is format of your files/line ? XML ? there may be some
good (up and down) formating tools to make diffing easier. Not perfect,
but may help.
> I would consider it a bug when a line with identical content is broken on different positions in the left and right pane, since it makes the program show differences that aren't there. Agreed?
I thought about it. It is quite hard question even it does not looks like.
There is split line you can move. You are saying that when you make left
view narrow and right wide the small one wins (in term of number of
chars per line)?
Or any logic suggestion ?
I'm not saying that current situation it is perfect nor ok - there are
some bugs to fix, but even content is identical there are some aspect
you have to decide how to handle.
> In addition, I think it would be good if TortoiseMerge could try to make the visualization of broken lines more readable by considering inline difference information (that we already have) when deciding where to break the line.
Sounds good, however if you add one char - that char should take line?
or same space should be inserted into other view? If second there are
different char sizes (KANJI) and same differs in size by content nearby
(FARSI), so that easy, and readability of such expanded text would be
heavy affected.

If you see any solution for this which can works for all cases, and most
user let me know.

> Hans-Emil

Oto BREZINA, Printflow s.r.o., EU
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-05-05 10:31:35 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.