MathGroup Archive 2007

[Date Index] [Thread Index] [Author Index]

Search the Archive

Multiple UNDO - a simple proposal

  • To: mathgroup at smc.vnet.net
  • Subject: [mg77803] Multiple UNDO - a simple proposal
  • From: David Bailey <dave at Remove_Thisdbailey.co.uk>
  • Date: Sun, 17 Jun 2007 06:04:22 -0400 (EDT)

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 Bailey
http://www.dbaileyconsultancy.co.uk


  • Prev by Date: Re: MIDI and MATHEMATICA
  • Next by Date: is there a better way to iterate this?
  • Previous by thread: Re: numerical integration problem
  • Next by thread: Re: Multiple UNDO - a simple proposal