Rendered at 18:20:05 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
mikolajw 3 days ago [-]
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.
metaketa 3 days ago [-]
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.
mikolajw 2 days ago [-]
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)
ivere27 3 days ago [-]
good. it would be good to have 'size limit'(such as ring buffer).
(or future feature - TTL,expiration)
- 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)