[darcs-users] locking
Ketil Malde
ketil.malde at bccs.uib.no
Fri Feb 24 10:16:10 UTC 2006
"Stephen J. Turnbull" <stephen at xemacs.org> writes:
> The easier it is to commute syntactic patches, the
> more carefully you need to check semantic prerequisites
I'm not sure I follow you. Could you give an example (of a LaTeX
or other textual document) where commutation across a word based diff
would break something and be less desirable than a conflict? Would
this happen often enough compared to conflicts?
> I strongly suspect the reason that
> line-oriented hunks work as well as they do is that good style, if not
> syntax, in most languages is line-oriented.
In most *programming* languages. Conversely, the reason they work
poorly for e.g. LaTeX documents is that good style isn't line
oriented.
I'm (of course) not saying you should always do word-based diffs, only
for formats where line-based diffs work poorly.
> It's in the packages. Check M-x list-packages.
Didn't work. No matter, although I still don't see why a file format
somehow imposes restrictions on the diff algorithms. Inconveniences,
yes, restrictions no.
> more than handle line-oriented text is the wrong idea (unless you want
> to turn it into Yet Another Editor That's Smart).
I agree. Which is why I don't think it should do more, just do
differently.
> You can probably get that down to O(n lg n) or better on average by
Sure. I mean - do a linewise diff first, and then do a wordwise diff
on each hunk of changed lines. Even with O(n²) behaviour, the cost is
now only an additive factor of O(m²) over the normal diff, where m is
words per hunk.
> Which is another reason why the algorithms should be under control
> of a scriptable editor....
As long as I don't *depend* on the editor to manipulate (apply, pull,
push, record..) patches or depend on separately distributed
functionality.
-k
--
If I haven't seen further, it is by standing in the footprints of giants
More information about the darcs-users
mailing list