Auto Save All Buffers After A Delay #9732
Conversation
|
Sorry, I don't understand the use case if helix already has
Can you explain more about hot reloading usage? Do you want to automatically save every second or what? |
|
This is definitely useful but it shouldn't be implemented with the idle timeout we will remove that soonish (once all items in the tracking issue #9629 are done) |
|
Resolves #3451 |
@woojiq Yes, helix does already have auto-save. However if enabled it's only triggered by changing focus away from helix. This change would allow for buffers to get saved after a certain amount of time has elapsed without any new input. Before I was using vscode as my text editor and got used to it there. https://code.visualstudio.com/docs/editor/codebasics#_save-auto-save For the hot module reloading stuff I was thinking about sveltekit, and how it's nice making changes to my frontend and seeing it near real time without having to navigate away from my editor. https://kit.svelte.dev/docs/faq#how-do-i-use-hmr-with-sveltekit |
@pascalkuthe Can you point me in the direction of some code samples that use the event system? I can work on updating my pr to use it instead of the current ad-hoc method. |
the-mikedavis
added
the
S-waiting-on-author
|
Moving to a draft for now. I've started working on porting the idea over to the event system. |
@pascalkuthe I realized that my initial pr description wasn't clear. I am not piggybacking off of idle timeout, however I do depend on the Is |
|
All of that is going away. Eberything is getting its own async handler with its own timout. Moving around should not prevent autosave. You should be registering documentdidchange handler and start a (fairly long like 5s) timeout there that will trigger autosave when finished. Like kirawi said look at how the signature help handler is implemented (just that you don't care about mode and selection changes) |
|
Initial port to the event system, implementation is currently half-baked. I need to iron out the user experience, and to get it working consistently. |
|
|
||
| #[derive(Debug)] | ||
| pub(super) struct AutoSaveHandler { | ||
| trigger: Option<AutoSaveInvoked>, |
There was a problem hiding this comment.
There is no need to keep the trigger around , you don't actually use this
| context.editor.set_error(format!("{}", e)); | ||
| } | ||
|
|
||
| if let Err(e) = context.block_try_flush_writes() { |
There was a problem hiding this comment.
I don't think thsi should be here, this is only intended for shutdown. We don't want to freeze the editor while writing to disk
| idle_timeout: Duration::from_millis(250), | ||
| save_delay_timeout: Duration::from_millis(1000), |
There was a problem hiding this comment.
Maybe the default should be longer like 5s?
There was a problem hiding this comment.
For me the primary benefit of auto saving after a delay is updating lints from LSPs such as rust-analyzer. IMO one second is the best default for this use case. This also seems to be main use case mentioned on #3451. 1s is also the default in vscode and it works well there.
|
closing in favor of #10899 |
The feature I would like to introduce with this pull request is the ability to auto save one's work after idling. I've found it to be a great editing experience, especially while working with a stack that offers hot module reloading.
My implementation works similarly to
idle_timer, that is once mysave_delay_timerhas reached zero anEditorEvent::SaveDelayTimeris returned causingEditorView::handle_eventto handle that timeout and save the buffers.Any feedback is greatly appreciated.