When editing a multi-part project (like a Python project with several modules), I frequently forget to save a module's file before running the main program again. So I have to either ctl-shift-S, then retry, or go back to the changed tab, save, back to the main, and try again.
Would it be difficult to implement a way, such that, on execute, all changed tabs get saved? I considered: - Adding an option in the build command lines - Implement a %-variable (say %! or so) which does the saving, and can be included in the build command
Or maybe I'm just missing something?
There have been discussions in the past about saving all, not just current. They were some time ago and I can't find any issue or PR that seems related, maybe the discussion was on the mailing list.
I remember that there were objections about unintended saving of other modified files, and I guess the fact that it hasn't been done indicates that it was decided against, or nobody found it compelling enough to do it.
My thoughts are:
1. save nothing - causes annoyance but can't do any damage, everything is still in the Geany buffers and the files unchanged 2. automatically save current - can lose data by overwriting the current file with the modified buffer when the user didn't intend it, but only one file, and may be recoverable using undo in the buffer to get the unchanged file 3. automatically save all - can lose data of an arbitary number of files, with no warning, or with warnings which become very annoying when the user intends to save.
Because option 3 is most useful when a lot of files are open, its also most dangerous then because of the lack of visibility of what is happening. Examples include when intending to build with a version of a file checked out of VCS, but that marks the buffer as modified since it no longer matches the file, so it would be saved over, and the build would not use the checked out version. IIRC it was these sorts of subtle and unexpected problems that were the most concerning about automatic save all on build.
Basically there are so many workflows that I think the three options above are very blunt tools for matching Geany behaviour to the workflow. Better to be safe by limiting the damage with options 1. and 2.
OTOH the save actions plugin provides autosave all on a timer, that may meet your requirements, or since there is a [signal](https://www.geany.org/manual/reference/pluginsignals_8c.html#a38a77ff848ecb0...) on build start (which actually notes a possible use is for a plugin to implement "save all") somebody could provide a PR to add a "save all on build" option to the save actions plugin.
OTOH the save actions plugin provides autosave all on a timer, that may meet your requirements, or since there is a signal on build start (which actually notes a possible use is for a plugin to implement "save all") somebody could provide a PR to add a "save all on build" option to the save actions plugin.
That sounds like a great idea. I already had the _Save actions_ plugin installed, but had disabled it - if I recall correctly, because each 'save' also activates the 'remove trailing spaces' (if enabled). That means while I'm typing, trailing spaces get removed unexpectedly on each auto-save - but that's another issue...
Cheers!
also activates the 'remove trailing spaces' (if enabled)
Well its saving the file, it might not be saved again, so it has to do the selected file save preferences otherwise the file will not be in the normal saved state.
github-comments@lists.geany.org