countvajhula
commented
2 months ago This issue is essentially about iteration conditions/triggers.
We could have each session define a containing session along with a corresponding trigger, so that there are two triggers, one for iteration of the current session and one for merging into the containing session (more precisely, each session/branch could have an associated trigger, and contained sessions should be aware of the containing session triggers so that they can propagate triggers "upwards").
E.g. if the local trigger is "on buffer change", then every time there is a bounded edit that Emacs considers a single edit, it records a commit. Then, if the merge trigger is "save-buffer," when we save the buffer, the set of commits is squash-merged (anonymously) into the containing session branch.
Likewise, on that containing branch, we could define the containing trigger to be Emacs's generic compile function. Finally, the containing branch here could have a null containing branch, meaning that there is no merge trigger.
You could work on the lowest-level branch, and have each action commit appropriately at higher and higher levels implicitly (question: can we create Git commits programmatically without switching branches?). We could potentially require commit messages if iteration propagates up to certain levels.
We could add support in begin-session to indicate the type of session or to allow selecting from a list of standard and user-defined triggers, and that would imply appropriate iterate and merge triggers.
This could scale up and down as we like, and it may be necessary to define more complex triggers at high levels, like "successful" builds or "passing tests" or "successful deployments."
As an assessment of the above, this is quite intriguing but seems tricky to implement and there are many unknowns. Probably something for later.
Currently, mindstream is designed around a feedback loop at a certain scale -- modifications of a buffer at natural bounding points (a kind of "Poincare section" of the user's flow).
But there are smaller feedback loops (expression-level, REPL interactions, or Vim-like semantic edit commands) and larger ones (rebuilding and testing the whole project across multiple files and directories) and still-larger ones (deploying working code to production) that have the same Poincare-section-like cyclic quality.
Can a meaningful UX be designed that would usefully scale up and down in this respect, which might naturally subsume existing development workflows?
At a minimum, this would entail decoupling the notion of "session" from changes to a specific buffer. We could potentially use Git branches to model iteration at different scales (e.g. one branch for changes in any project buffer (i.e. current Mindstream behavior), and another "develop" branch that tracks changes at the normal level used in Git repos, viz. semantically connected changes across many files, and another "main" branch that tracks "deployed" code).