Alright, I've been working on this on and off for a while now, so I figure I should put down a bit of an update:
There's a sort-of working implementation in my repository at http://darcs.hoelzro.net/darcs. This implementation will allow you to edit a file at a given hunk, and it'll build a new hunk list for that file when you're done. However, the new hunks won't make it into the recorded patch, and any old hunks that you may have removed during your edit are still there (More on this below). There are more notes about the limitations of my implementation in the patch's comment section, but they aren't as bad/difficult to solve as the problem I'm about to discuss. The reason my implementation hasn't made any progress in the last month is that I've been trying to figure out how to create a new PatchChoices object to reflect the new set of hunks. The problem with this is that if I were to make a new PatchChoices object, I would lose all of the user's previous selections, which makes hunk editing pretty much useless. So for this feature to progress, one of the following needs to happen: - I need to be proven wrong in my conception that there's no way to import the choices from one PatchChoices object to another. I base this on the idea that a Tag from one PatchChoices object only identifies its associated hunk in that PatchChoices object, and not in any other PatchChoices object. - The PatchChoices facility needs to be retooled so that each hunk has a unique ID across all PatchChoices objects. I feel this could be implemented with something like a map, with a hunk's checksum as the key. Normally, I'd proceed along option #2, but I'd rather have my thoughts reviewed by more experienced Darcs hackers before I make large code changes. Thanks, Rob
signature.asc
Description: PGP signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
