Amirreza Ask <raskarpour@xxxxxxxxx> [2020-10-02, 16:47 +0330]:
I think our cube definition should be in form of a data structure with allUnder the hood, Cubes will update the status monad via a hashmap or
keybindings and bindings and everything,
and cube runner uses this data structure to change the state.
I didn't get your point about cubes being callable ?
On Fri, Oct 2, 2020 at 4:00 PM Sameer Rahmani <lxsameer@xxxxxxx> wrote:
I'd like to discuss the specification of the Cubes as we discussed
I describe my idea of cubes and lets discuss them.
1. A Cube should be a unit of configuration for a specific
ability. For example we might have a cube for flycheck.
2. A Cube can have other cubes and dependencies or may conflict
with some other cubes
3. A Cube should be callable
4. A Cube should be idempotent and deterministic
5. Cubes should be composable
6. A Cube can be combosition of different cubes
7. Cubes by themselves shouldn't change the world. We need a Cube
runner that takes a composition of Cubes and changes the world
8. Cubes need to use some sort of api to interact with the world.
For example in order to define a keybinding they have to use a
specific api and not the one provided by emacs itself. Because
they shouldn't change the world. That api should provide a way
for any Cube to describe what changes has to be made to the
Based on these specs I think it makes sense to create a state monad
that represents the state of the world and each cube returns a monadic
function and a runner function which applys the state within the state
monad to the world aka setup the editor based on that state.
This way we can create some functors to help users dealing with the
I'd like to hear your feedback and idea on this.