Closed Distantoff closed 3 weeks ago
(you can ignore this bot's feedback for now, it's just to flag anything else i might want to look at)
@greptileai
hm after taking another look at vim_state and the command_tx registration, i think it might be better to always initialize vim_state with a pointer to a function in editor.rs that does the message sending instead since it already has the command_tx initialized.
i can make the edits directly after doing some testing if you dont mind
hm after taking another look at vim_state and the command_tx registration, i think it might be better to always initialize vim_state with a pointer to a function in editor.rs that does the message sending instead since it already has the command_tx initialized.
i can make the edits directly after doing some testing if you dont mind
editor.rs
Yes of course! Perhaps this is the best solution
i couldn't get it to work with giving the vim_state a function pointer or closure to a function in editor, so i'll stick with your approach of having the command_tx registered in vim_state :)
did some profiling and cloning the command_tx every transition doesnt have any performance impact
i couldn't get it to work with giving the vim_state a function pointer or closure to a function in editor, so i'll stick with your approach of having the command_tx registered in vim_state :)
did some profiling and cloning the command_tx every transition doesnt have any performance impact
Yes, cloning command_tx as far as I know just copies the reference, so the number of sender can be created a lot
Included in release v0.2.8
Hello! Thank you for your project, I liked it, but immediately I came across that the clipboard of the system was not working. I found the reason why this happens - the instance of arboard clipboard must run throughout the lifetime of the entire program.. Instead of copying text, signals are sent in the vim module, which are processed in the app, as well as components.