zyedidia
feature: add option to only autosave on window focus lost, tab change, or split focus change
Timer for auto save is the most naive way of doing it, it's bad and waste ful
Most editors do it on focus loss, either changing tab, changing split focus or when window is loosing focus
or when window is loosing focus
Micro (or any other terminal-based editor) has no way to know if the terminal window it is running in is focused or not.
Anyway, micro doesn't naively save the file every time when the timer fires, it only saves the file if it has been modified (at least since https://github.com/zyedidia/micro/pull/3356). So what's the problem?
or when window is loosing focus
Micro (or any other terminal-based editor) has no way to know if the terminal window it is running in is focused or not.
That's not entirely true, some (many?) terminals support xterm's focus events ^1 which can be enabled with CSI ? 1 0 0 4 h. It's probably not worth spending time on though because the improvement to autosave logic would be rather marginal.
That's not entirely true, some (many?) terminals support xterm's focus events 1
Ok, didn't know that (or forgot about that).
Anyway, yeah, I see no advantages of doing that (and a bunch of disadvantages).
It's probably not worth spending time on though because the improvement to autosave logic would be rather marginal.
you never want to auto save in the middle of typing, you only ever want to save when context changes
this is because you may be listening to file changes to do some tasks, and you expect file to be valid
you never save an invalid document, you only ever save after you commit your sentence/logic
current way is naive since it doesn't care about user intent, nor does it care about document correctness
and a bunch of disadvantages
aka, you have no clue
there is a reason why most editors auto save on context change, and never on a timer.. sigh
If you "may be listening to file changes to do some tasks, and you expect the file to be valid," you should deactivate autosave if you are depending on file correctness.
What if you switch windows with an "invalid document" and without "committing your sentence/logic"?
What if none of those events are triggered?
If you "may be listening to file changes to do some tasks, and you expect the file to be valid," you should deactivate
autosaveif you are depending on file correctness.
Exactly. Or more precisely, you should not activate autosave. It is disabled by default.
What if you switch windows with an "invalid document" and without "committing your sentence/logic"?
Yep, or for example if you "committed your sentence/logic" but didn't switch windows (for example, just walked away from the computer).
What if none of those events are triggered?
Yep, for instance, the terminal emulator may not support those focus events, or there may be no "window" to begin with (i.e. micro may run in an actual bare terminal, without a windowing system).
I wonder if any of those "most editors that auto save on context change" are terminal-based editors.
FWIW, I don't use autosave myself (and doubt it usefulness TBH, since micro saves backups), but IIRC there are users who use it and even deliberately set the autosave timeout to 1 second (!).
Possibly more realistic approach would be for micro to provide hooks for onFocusIn and onFocusOut events so the desired behavior could be easily implemented as a plugin (without messing with the built-in autosave). I'm not personally invested enough in that feature to implement it, but would it have a chance to be merged if eg. @bangbangsheshotmedown was to create a pull request?
Possibly more realistic approach would be for micro to provide hooks for
onFocusInandonFocusOutevents so the desired behavior could be easily implemented as a plugin
Yep, I also thought about exactly that (and that was also already suggested several times in the past in different contexts). We already have onSetActive, we could also add onSetInactive and so on.
We already have
onSetActive, we could also addonSetInactiveand so on.
If onSetInactive is implemented it will be called next to onSetActive, right?
Instead couldn't the "old pane" be an extra arg for onSetActive?
If
onSetInactiveis implemented it will be called next toonSetActive, right? Instead couldn't the "old pane" be an extra arg foronSetActive?
Unfortunately we need to preserve compatibility with the existing (not the most fortunate) onSetActive interface...
But I've just recalled that actually yes, luckily, we can add an extra argument while at the same time preserve compatibility (the existing plugins will keep working, just ignoring this extra arg): https://github.com/zyedidia/micro/pull/3779#discussion_r2160073615
Ye, I had that in mind. Overall do you think it's a better idea over creating onSetInactive? It would be less bloat IMO. But IIRC there's already some sort of problem with onSetActive right?
Yes, reusing onSetActive seems better.
But IIRC there's already some sort of problem with
onSetActiveright?
Which problem? (apart from its name)
Which problem? (apart from its name)
Not being raised in every bp change. https://github.com/zyedidia/micro/issues/3563
What's up w the name?
Ok, those are problems with the implementation, not with the interface? I.e. we can just fix them.
Right, it seems there's already a patch for it https://github.com/zyedidia/micro/pull/3584