
If you work with a text editor like Microsoft Visual Studio (maybe also Eclipse, don't know), each text editor has its own undo/redo history. However, when you perform refactoring - like renaming a function - this becomes an undo/redo on multiple files together, so in a sense these changes are part of a global history. You can combine these two different kinds of mutations, and undo/redo still works as expected. I don't know how hard this is to implement, but it looks like this problem is somehow is related to Darcs theory of patches (which I don't know yet :-)

Hi Peter,
On Fri, May 8, 2009 at 8:33 AM, Peter Verswyvelen
If you work with a text editor like Microsoft Visual Studio (maybe also Eclipse, don't know), each text editor has its own undo/redo history. However, when you perform refactoring - like renaming a function - this becomes an undo/redo on multiple files together, so in a sense these changes are part of a global history. You can combine these two different kinds of mutations, and undo/redo still works as expected. I don't know how hard this is to implement, but it looks like this problem is somehow is related to Darcs theory of patches (which I don't know yet :-)
I have thought about applications of patch theory like this as well. I could imagine applying it to the undo stack in GIMP. Allowing you to undo things on different layers. I think one of the things you need for this to work, is a graphical representation of the undo history. You could commute the change you want to undo to the top of the stack, undo it, and then you have a branch in the history. Because this could get complicated, you need to display this branched history to the user so they are able to continue working with it. If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5]. Thanks, Jason [1] http://darcs.net/manual/node9.html [2] http://en.wikibooks.org/wiki/Understanding_darcs/Patch_theory [3] http://files.codersbase.com/thesis.pdf (see chapter 3) [4] http://wiki.darcs.net/DarcsWiki/Talks [5] http://bugs.darcs.net/issue1149

On Fri, May 8, 2009 at 12:43 PM, Jason Dagit
Hi Peter,
On Fri, May 8, 2009 at 8:33 AM, Peter Verswyvelen
wrote: If you work with a text editor like Microsoft Visual Studio (maybe also Eclipse, don't know), each text editor has its own undo/redo history. However, when you perform refactoring - like renaming a function - this becomes an undo/redo on multiple files together, so in a sense these changes are part of a global history. You can combine these two different kinds of mutations, and undo/redo still works as expected. I don't know how hard this is to implement, but it looks like this problem is somehow is related to Darcs theory of patches (which I don't know yet :-)
I have thought about applications of patch theory like this as well. I could imagine applying it to the undo stack in GIMP. Allowing you to undo things on different layers. I think one of the things you need for this to work, is a graphical representation of the undo history. You could commute the change you want to undo to the top of the stack, undo it, and then you have a branch in the history. Because this could get complicated, you need to display this branched history to the user so they are able to continue working with it.
If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5].
Thanks, Jason
Also good and highly relevant: http://byorgey.wordpress.com/2008/02/04/gobby-haskell-and-patch-theory/ -- gwern

I have thought about applications of patch theory like this as well. I could imagine applying it to the undo stack in GIMP. Allowing you to undo things on different layers. I think one of the things you
Don't know about the GIMP, but in Emacs, you can select a region of text and undo just the changes in that region. Stefan

Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit:
If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5].
Is libdarcs the same as the darcs library package on Hackage (which exports the darcs API)? Best wishes, Wolfgang

Wolfgang Jeltsch wrote:
Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit:
If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5].
Is libdarcs the same as the darcs library package on Hackage (which exports the darcs API)?
Yes. Ganesh =============================================================================== Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html ===============================================================================

Wolfgang Jeltsch
Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit:
If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5].
Is libdarcs the same as the darcs library package on Hackage (which exports the darcs API)?
The Darcs package (both on Hackage and elsewhere) builds two things: the darcs(1) binary, and libHSdarcs. The latter is what Jason was referring to. Note that currently it just exposes all our internal functions, rather than providing a coherent (or stable!) API.

Am Mittwoch, 13. Mai 2009 02:55 schrieb Trent W. Buck:
Wolfgang Jeltsch
writes: Am Freitag, 8. Mai 2009 18:43 schrieb Jason Dagit:
If you wanted to work on this, I would encourage you to read more about patch theory[1,2,3,4] and also try out libdarcs[5].
Is libdarcs the same as the darcs library package on Hackage (which exports the darcs API)?
The Darcs package (both on Hackage and elsewhere) builds two things: the darcs(1) binary, and libHSdarcs. The latter is what Jason was referring to. Note that currently it just exposes all our internal functions, rather than providing a coherent (or stable!) API.
I know. My students, who worked on a darcs GUI frontend, already experienced this. ;-) Best wishes, Wolfgang

At Fri, 8 May 2009 17:33:25 +0200, Peter Verswyvelen wrote:
[1
] [1.1 ] If you work with a text editor like Microsoft Visual Studio (maybe also Eclipse, don't know), each text editor has its own undo/redo history. However, when you perform refactoring - like renaming a function - this becomes an undo/redo on multiple files together, so in a sense these changes are part of a global history.
If you read this paper, you will find an undo system for a colloborative editor complete with a theory that looks like a primitive version of darcs patch theory (complete with the dreaded merge bug of darcs 1): Undoing actions in collaborative work: Framework and experience by Prakash and Knister http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.48.6443&rep=rep1&type=pdf You will probably find these papers informative as well: Recognizing creative needs in user interface design by Terry and Mynatt http://www.cc.gatech.edu/fce/ecl/projects/openEnded/pubs/creativeInterfaces-... A Selective Undo Mechanism for Graphical User Interfaces Based On Command Objects (1994) by Thomas Berlage http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.755 Flexible Conflict Detection and Management In Collaborative Applications (1997) by Keith Edwards http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.5439 Undo Any Operation at Any Time in Group Editors (2000) by Chengzheng Sun http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.6266 And, of course, you can use citeseer to find more papers that reference those. - jeremy

Una Merge does real-time merging and has per user undo. And it can do lots of stuff that seems darcs-like, though I don't know enough about darcs to say for sure (e.g. moving a user's own edits after other edits). http://www.n-brain.net/una_merge.html Regards, John A. De Goes N-Brain, Inc. The Evolution of Collaboration http://www.n-brain.net | 877-376-2724 x 101 On May 8, 2009, at 1:35 PM, Jeremy Shaw wrote:
At Fri, 8 May 2009 17:33:25 +0200, Peter Verswyvelen wrote:
[1
] [1.1 ] If you work with a text editor like Microsoft Visual Studio (maybe also Eclipse, don't know), each text editor has its own undo/redo history. However, when you perform refactoring - like renaming a function - this becomes an undo/redo on multiple files together, so in a sense these changes are part of a global history. If you read this paper, you will find an undo system for a colloborative editor complete with a theory that looks like a primitive version of darcs patch theory (complete with the dreaded merge bug of darcs 1):
Undoing actions in collaborative work: Framework and experience by Prakash and Knister http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.48.6443&rep=rep1&type=pdf
You will probably find these papers informative as well:
Recognizing creative needs in user interface design by Terry and Mynatt http://www.cc.gatech.edu/fce/ecl/projects/openEnded/pubs/creativeInterfaces-...
A Selective Undo Mechanism for Graphical User Interfaces Based On Command Objects (1994) by Thomas Berlage http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.755
Flexible Conflict Detection and Management In Collaborative Applications (1997) by Keith Edwards http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.49.5439
Undo Any Operation at Any Time in Group Editors (2000) by Chengzheng Sun http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.6266
And, of course, you can use citeseer to find more papers that reference those.
- jeremy _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (9)
-
Gwern Branwen
-
Jason Dagit
-
Jeremy Shaw
-
John A. De Goes
-
Peter Verswyvelen
-
Sittampalam, Ganesh
-
Stefan Monnier
-
trentbuck@gmail.com
-
Wolfgang Jeltsch