On 2011-05-06 09:19, Hans-Emil Skogh wrote:
>>>> 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)?
>>> Hmm. Good question. I would spontaneously suggest to disable the splitter
>>> and fix it at 50% when "Wrap long lines" is enabled.
>> I have started feature request as you have seen
> I ment to force it to 50%, disabling the possibility to change it when in line-wrap-mode: To prevent strange diffs. But I guess this could be OK as well. But it will probably lead to more edge cases to fix along the way.
We have to start with something, we can ask for that later as soon as
we'll find it "only missing peace".
>>> Another suggestion would be to just make the whole line-wrapped block
>>> behave as a single block when it comes to the diff. That is, show the
>>> all the lines that makes up the wrapped lines as changed, if any part
>>> of the lines is changed. Not as useful or elegant, but it's a
>>> possibility...
>> Sorry don't get what you mean ... Is it not like today ?
> No. Let's say that I have a single long line that is being wrapped into five new lines. Today each of those five lines will be handled independently by TortoiseMerge when it comes to color coding. I would then suggest to color code all five lines as a whole, since they are part of the same line.
>
> However: This would give less information than fixing at 50% and leaving the color coding as today...
I played with wrapped lines and found what you meant. In line diff
coloring is performed on displayed line (called screenline) not file
line (called viewline).
While this is good idea - and I think must have - it is not that easy to
implement. Wrapping is quite young (in term of used hours) introduced
July 2010 so it have some child illness. And we talk just about one of
them now. I have fixed some of them (and probably introduced others :( )
like editing does not works at all till now in wrapped mode.
I would like to speed things up by caching inline diff too however this
is not that simple task. In fact inline diff (and some other stuff) is
made just while drawing line, this makes things not that fast as I would
like to have, but for your case it is fastest way as building long line
diff may take a while and it have to be performed after any change -
every typed char.
So not sure yet what is solution here.
>>>>> 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.
>>>>
>> However don't see any real way how to make it better while keep readability.
> To me it seems like the in-line diff does an excellent job of analyzing the changes in a single line. It's just a matter of bringing that information into play when breaking long lines and I think we will get excellent readability of them as well.
So: something like break it on same place of common characters should
work? So common parts will be on same line and line which need wrap
(common part) will enforce wrapping on same place of common part.
Not sure if my English (or whatever language) can express what I mean.
This sounds good for 2-pane view, but I have found that we never talk
about 3-way thing.
I have no idea how it should work in resolving mode.
--
Oto BREZINA, Printflow s.r.o., EU
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2732680
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-05-08 21:48:24 CEST