From: julio@diegidio.name   
      
   On Monday, 4 April 2022 at 15:02:24 UTC+2, Julio Di Egidio wrote:   
   > On Monday, 4 April 2022 at 14:23:58 UTC+2, Julio Di Egidio wrote:    
   > > On Monday, 4 April 2022 at 10:49:05 UTC+2, Malcolm McLean wrote:    
      
   > > > That is how a lot of programs work. But it means the undo/redo system   
   dominates the design    
   > > > of the program.    
   > >    
   > > No no, I would certainly expect the whole thing to be orthogonal to normal   
   operations: don't we just need a "definition file" where we say what maps to   
   what, plus hooks wherever relevant actions happen? And then again, this (what   
   needs to be tracked)    
   is not usually "just everything".   
   >    
   > To be clearer, I mean mapping property values within the program to keys   
   ("paths") for tracking: then you'd use the key to add to the undo stack (where   
   you'd know which key you need because this "derives" from the specific action   
   that is originating it)   
   , and when restoring state from the stack, you'd again use the key to,   
   viceversa, know which action it refers to whence which property value to   
   change/restore... That's what I end up with.   
      
   In fact, "again use the key to, viceversa, know which -- property value to   
   change/restore", no need to now about actions at all, this is all about   
   property values.  The only reason I can think of to, a this point, also record   
   the name of the action with    
   every entry in the stack, is to be able to show it it to the user or similar...   
      
   Anyway, details apart, I'd think that's pretty much it: the only open question   
   on my side is what you mean by "program state" and why...   
      
   BTW, sorry for being a bit messy.   
      
   Julio   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)