Edit-Commit

  • typing commands changes the output live, but only as a preview
  • there's another command to commit (store) the changes
  • I like how this is similar to REPL, but not really, because changes are not permanent until explicitly committed by the user, so everything happens in kind of a sandbox
    • curious how it would work when combined with time-travel
  • related research:
    • Unison and its way of working with scratchpad
    • Yoshiki Schmitz's research

      As you're typing them they're in a live editing preview mode, but when you press enter they get applied "permanently".

    • s-ol's research

      (...) you don't have to hit enter or a button to make it execute, and you don't have to undo if it didn't do what you wanted it to. The code is continuously parsed and interpreted as it is edited (as long as it is valid). The function-invocations register themselves with the editor UI, which draws these visualisations and keeps state for them as long as the editing session exists and the function invocation is not removed. This lets the user tweak the code and make sure it works, as well as tweak the selections etc. Once the user is happy with the result, they can commit the changes.

Creating-Curating
  • Edit-Commit in programming, where editing is like creating, and committing is like curating
Future Of Coding
  • Edit-Commit systems as a way to (in)directly manipulate without fear of messing up current state
Modes
  • this seems to interplay with edit-commit, maybe edit could be a temporary mode
Tensions
  • Edit-Commit - difference in editing something to play with it and experiment vs commiting to that change