To answer the usual question these days: the library, including the README which you can read, was written by hand, without LLM usage. I only played somewhat with Codex later on when creating derive macros and with some tests and examples, but that was all also highly manual.
This is awesome and I've needed it often. Could it hypothetically support filtered undo? For example in a collaborative app where not all edits are owned by the user.
I think you can do that with undoredo by doing all the following:
- Having one history bistack for each user or permissions group to enforce ownership;
- Giving each new object's a unique key (e.g. from a counter, possibly a persistent one) to prevent key collisions by avoiding ever trying to fill the same container slot more than once;
- Storing the objects in a sparse container such as BTreeMap, BTreeSet, HashMap, HashSet to avoid visiting emptied slots when iterating over all the elements.
I have not tested this, but it could be a nice case to add to examples.
(having used a bullet list I immediately feel the need to explain myself: this message was whole written by hand)
good. it would be good to have 'size limit'(such as ring buffer).
(or future feature - TTL,expiration)
To answer the usual question these days: the library, including the README which you can read, was written by hand, without LLM usage. I only played somewhat with Codex later on when creating derive macros and with some tests and examples, but that was all also highly manual.
This is awesome and I've needed it often. Could it hypothetically support filtered undo? For example in a collaborative app where not all edits are owned by the user.
I think you can do that with undoredo by doing all the following:
- Having one history bistack for each user or permissions group to enforce ownership;
- Giving each new object's a unique key (e.g. from a counter, possibly a persistent one) to prevent key collisions by avoiding ever trying to fill the same container slot more than once;
- Storing the objects in a sparse container such as BTreeMap, BTreeSet, HashMap, HashSet to avoid visiting emptied slots when iterating over all the elements.
I have not tested this, but it could be a nice case to add to examples.
(having used a bullet list I immediately feel the need to explain myself: this message was whole written by hand)
good. it would be good to have 'size limit'(such as ring buffer). (or future feature - TTL,expiration)