feature request: partial-context diff

[Jamie Peabody]

I was afraid that it would screw up the markup (fancy drawings).  It might
be possible to handle the disappeared line numbers with a margin
annotation.  I wouldn't mind seeing a screen shot of what you have...


On 22 April 2015 at 14:45, Sam Jaques <sam.jaques at gmail.com> wrote:

> Hi Jamie
>
> It does make sense and it works with a small amount of code :)
>
> I see that line 1 is always shown with some characters of previous line
> from the first unchanged code block, even if I start collapsing from line:0.
> Probably I stumble upon a fix later...
>
> Now the fancy drawings in the middle are not aligned to the changes.
> It seems I have to adjust the changes' y-coordinates (lhs-y-start,
> lhs-y-end, etc.) which is a harder challenge without having the knowledge
> of the 'equal' lines.
>
> Also a line, or better the disappeared line numbers could be shown (like
> in a diff view: -6,7 +6,6
> As an extra, a nice feature would be to uncollapse the whole code simply
> by clicking on a button between the collapsed code.
> That would acquire some more in depth of the code but it's certainly worth
> a try.
>
> In the end, I'll add the collapsed mode as a new option for Mergely and
> update the readme.
>
> Kind regards
> Sam
>
> On Tuesday, April 21, 2015 at 5:04:23 PM UTC+2, Jamie Peabody wrote:
>>
>> Hi Sam,
>>
>> I haven't done any work on this.
>>
>> It is not function that returns "equals".  The unchanged lines would be
>> the inverse of the changed lines.  My gut-feeling approach would be to
>> extend this loop at 1195
>> <https://github.com/wickedest/Mergely/blob/master/lib/mergely.js#L1195>
>> to also add "equal" changes (the opposite of changed).  E.g. if I had a doc
>> with 100 lines, and deleted one line at 50, then my list of changes would
>> be the lhr and rhs changes, plus marking text inverse the change:
>>
>> marktext.push([led, {line:0, ch:0}, {line:49, ch:to_ln.text.length}, {
>> *collapsed*: true}]);
>> marktext.push([led, {line:51, ch:0}, {line:99, ch:to_ln.text.length}, {
>> *collapsed*: true}]);
>>
>> Make sense?  It's worth a go, even just to see if it's the right strategy.
>>
>> Jamie
>>
>> On 21 April 2015 at 12:58, <sam.j... at gmail.com> wrote:
>>
>>> Hello again Jamie
>>>
>>> Thank you for the info you provided so far.
>>> About the non-changes; I see they are not yet available in the code, do
>>> you know in which function to get them the best? I assume this function
>>> should return something like: [changes, equals].
>>>
>>> Thanks,
>>> Sam
>>> On Thursday, February 12, 2015 at 10:21:46 PM UTC+1, Jamie Peabody wrote:
>>> > Yes, markText is probably the right way to do it.
>>> >
>>> >
>>> > Around 1195, it iterates through the list of changes and builds an
>>> array of marktext.  That marktext is used on line 1251 and 1259 to apply
>>> markup.
>>> >
>>> >
>>> > I think the right way to do it would be to something similar for
>>> non-changes.  E.g., if line 6-10 changed, then non-changes would be 1-5 and
>>> 11+.
>>> >
>>> >
>>> > Anyhow, it's a good start.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Mergely" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mergely+u... at googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Mergely" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mergely+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20150422/76e65428/attachment.html>