Closed dyerti closed 1 year ago
Sorry for being late. That'd be interesting and useful!
What we have to think would be:
Which type of register should be covered? Numbered only, or as you suggest, numbered and named? Numbered register is simpler and intuitive, and may be easy to implement IMO, on the other hand named register offers more flexible way to manipulate files.
How should we think about the data structure? Now registered
field is Vec<ItemInfo>
, but with the register feature that may be BTreeMap<Usize, Vec<ItemInfo>>
or BTreeMap<Usize, Vec<ItemInfo>>
: This would vary based on the register type.
I was thinking numbered and named, so using something like BTreeMap<String, Vec<ItemInfo>>
.
I could start with numbered for the PoC and still use BTreeMap<String, Vec<ItemInfo>>
. It would make the changes needed in event loop smaller.
Yeah, that's good if named is planned.
(vec_deque
would be enough if numbered only though)
I'm ready to implement it, but what's your thought? Can I assign myself to this?
Sounds good. Go for it!
Implemented by #215.
It needed much refactoring but it feels now way, way better than before! Thank you.
If you're interested, please build from feature-reg
branch and tinker with it.
After debugging I'll release new version.
Merged & released as v2.4.0.
Is there any interest for support registers? I'd be open to contributing if there is interest.
My use case would be disjoint file manipulation and it seems like it would be a natural extension of the existing support.
Existing yank and put would modify the
""
register. Named registers ("a
) could be used to collect file selections when coupled with register appending ("A
).