vcmiraldo

Copy just copies once. The need for duplicate is clear if you're trying to diff something like `t = [a]` and `u = [a, a]`. You could copy `a`, but you'd have to decide whether to copy it on the first or second position; the second one would be classified an "insertion" by any ins/del/cpy-algorithm. If you instead opt to NOT make that choice, you can say: pick the source `a` and duplicate it instead

omg!! I really should have left that typo somewhere in there! What a missed opportunity! xD

Indeed, we also designed a brand new generics library to work around that. Performance was really not an issue! :)

Efficiency is not the issue at this point. My prototype diffing algorithm was linear and there have been improvements on it already (I think something called "truediff" is linear but an order of magnitude better! I could be misremembering the name, don't quote me :) ).

The real difficult part is in how you represent AST-level changes, which will limit what your merging algorithm can do. In particular, working around moving "the same subtree" into different places is difficult. Imagine the following conflict:

([1,3], [4,2,5]) <-- q -- ([1,2,3], [4,5]) -- p --> ([1,3], [2,4,5])

Both p and q move the same thing to different places so they need a human to make a decision about what's the correct merge. Depending on your choice of "what is a change", even detecting this type of conflict will be difficult. And that's because we didn't add insertions nor deletions. Because now, say p was:

([1,2,3], [4,5]) -- p --> ([1,3], [2,5])

One could argue that we can now merge, because '4' was also deleted hence the position in which we insert '2' in the second list is irrelevant.

If we extrapolate from lists of integers to arbitrary ASTs the difficulties become even worse :)

I really like the idea of focusing on producing patches for human consumption. I studied the problem of merging AST-level patches during my PhD (https://github.com/VictorCMiraldo/hdiff) and can confirm: not simple! :)

> 2. Also left handed. I just turn off the menu when I'm drawing/writing [...]

I know, but I often forgot to turn off the menu when annotating a pdf, and would close the pdf as soon as I touched the screen. After a few dozen repetitions it got quite annoying!

> [...] However, what annoys me is that the pen's mark on the screen is about 0.2mm off from the tip of the contract point, to account for the angle of the pen and the thickness of the screen glass. While it's a subtle problem, it is noticeable.

Interesting! I don't think I noticed that

> 3. I don't think this is a cost issue, it's battery life. I'm happy with their choice, and you certainly can't please everybody

You can always turn the light on or off, preserving the battery life. I found that reading something on a rainy day could be challenging depending on where I sat on the house. For a 500 euro device, I thought it was a bit of a shame.

Interesting, thanks, I didn't know this one!

I did find a few similar projects back when I had the reMarkable, but none quite worked well for me. I'm sure this will help some other people out there though! :)

I bought one, then returned it. For the price they're selling it at, the following points were a deal breaker for me:

1. Custom file system: this means I can ssh into it, but I can't rsync my bibliography into it, since it won't display regular pdf files whose name is not hashed and registered in some sort of index. Moreover, the lack of a Linux client meant it was very hard to put my pdfs on it, or extract my notes from it.

2. Left hand support is ridiculous. They just flip the screen left-to-right; which means you lose the nice bevel and it becomes very uncomfortable to use in "handheld" mode. Finally, the "close" button gets placed on the top-left corner of the screen, which is the first place a left-handed writer touches.

3. The lack of some sort of backlight and slightly gray background means I can't read under suboptimal light. Sure, I get it, its e-ink; but for the price they charge, it would be a very nice-to-have feature.

I ended up returning mine and went for the Samsung Galaxy Tab s7 and that thing is amazing! Plus, I get to follow through bibliography immediately without needing to go back to my computer and get another article then do the whole sync'ing dance again.

Thanks for the reply Wilfred! I was not familiar with Autochrome, I will certainly have a look!

That's interesting, I like the idea of not worrying about patching nor merging, giving you a tool that is focused on "communicating the differences to a human", and indeed, it means you don't have to worry about a whole bag of problems.

One insight that I came across (more info on Chap 5 of my thesis) is that not considering or handling duplication means you incur a quadratic slowdown in your search algorithm. For example, say you're diffing `A` against `Bin A A`. If you can't understand that `A` was duplicated, which `A` do you copy? You have to evaluate both options even though it really doesn't matter which one you copy.

One good middle ground for speeding up your algorithm while not having to worry about displaying duplications is to have an intermediate step where first you diff with duplication detection, but then you just go over the result and make arbitrary choices about which duplicate to copy and which to insert/delete.

you'll probably enjoy the patience diff: https://blog.jcoglan.com/2017/09/19/the-patience-diff-algori...

From you description it seems like we're just computing the standard insert-delete tree-edit-distance. These tend to be slow.

This implies that the patch language only supports insertion, deletion and modification of nodes, which is a shame since refactorings, moves and duplications are also common operations in the source-code domain. Additionally, if the patch language only supports insertion, deletion and modification, the merging algorithm will perform poorly.

That is a really difficult problem for more reasons than what fits in this comment :) In fact, I got my PhD studying this very problem (https://victorcmiraldo.github.io/data/MiraldoPhD.pdf).

I did not find any description of how your diffing algorithm works nor how you represent a patch. I'd be really curious to know more.