Re: Multiple UNDO - a simple proposal
- To: mathgroup at smc.vnet.net
- Subject: [mg78075] Re: Multiple UNDO - a simple proposal
- From: carsten_herrmann1 at gmx.net
- Date: Fri, 22 Jun 2007 06:42:56 -0400 (EDT)
- References: <f531d6$1uf$1@smc.vnet.net>
let me express a "feeling" - I know that here is not really the place for feeling s - the problem of missing undo may als be related to the missing process completion status bar for Mathematica evaluations could that be the case ? carsten On 17 Jun., 12:11, David Bailey <dave at Remove_Thisdbailey.co.uk> wrote: > Much has been written about the complexity involved in implementing > multiple undo in a Mathematica notebook. > > Obviously a notebook can receive changes from several sources - the user > typing, and various forms of data emanating from the kernel. However, > 99% of the time, the user is concerned with recovering his input cells > that he may have spent hours crafting. Computers are so stable nowadays, > and multiple undo is so effective in most applications, that many users > no longer think in terms of saving their work regularly. In past > versions of Mathematica, any crashes were pretty much confined to the > kernel, but with 6.0 it seems to be easier to crash the FE - and with > it, any unsaved work! > > Why not compromise and say that no cell will have an undo chain if it: > > 1) Contains Dynamic constructs. > > 2) Is an Output cell. > > 3) Contains any other specified features that WRI find cause problems. > > Undo points will only be placed at points where the kernel is at idle. > As an additional simplification, possibly the user would have to choose > between the multiple undo feature and the freedom to continue typing > while the kernel is executing a command. > > I would suggest that the undo information should be buffered on disk at > frequent intervals so that an FE crash would be less disastrous. I > suspect that the occasional FE crash is an inevitable consequence of the > very dynamic coupling between kernel and FE that now pertains. Indeed, > it was one such crash that prompted me to write this post! > > David Baileyhttp://www.dbaileyconsultancy.co.uk