On Mon, 10 Sep 2012 14:36:32 +1000 Lex Trotman elextr@gmail.com wrote:
Its about that time of year when we have our annual discussion on separating session data from config/project data :)
Let's not forget the multiply instances that share their configuration to (some) extent. We love to discuss them. :)
By session data I mean the list of currently open files and MRU list.
The advantages (that I can see):
- Save config/project as its changed and not rushed at quit time (and
the quit save doesn't happen in the absence of a working, portable, session management capability)
All settings in Edit -> Preferences and Project -> Properties are saved ASA the dialog is confirmed. Some time ago, Build -> Set Build Commands were modified to be saved immediately as well.
The only settings that are really saved on exit are the interface ones (check/radio menu items, find/FIF settings etc.). The Preferences and Properties are still saved on exit, but only because nobody cared to separate them. (There is more to it, but I don't want to start the multiply instances discussion now.)
- Save session data periodically, or as it changes, or whenever,
without touching the config/project files. So the config isn't at risk if the session save goes wrong.
Would be nice, but saving the session only (without the settings) in the current files is completely possible. In what situation saving the session will damage Geany configuration, but saving the interface sessings on exit will not?..
The only disadvantage for user config (that I can see) is that it adds one file, say geany.session.conf alongside geany.conf
For project sessions just using another file in the same place as the project file is more of a problem since project files can be in the project tree and some people like to save them in VCS. So users would have to make sure that their git.ignore (or whatever the other VCSes use) is edited each time so that the session file isn't saved in the VCS.
A better option, especially since sessions are inherently user related, is to store them in the user config location (or subdirectory thereof). But how to link these files to the project files?
The proposal is that each project gets a UUID generated when it is created (or when its opened without one) which is saved in the project file. This uuid is the name of the session file in the ${GEANY_CONFIG}/sessions directory. [...]
The number of session files can be left to grow like weeds, or can be trimmed to a (configurable) maximum number deleting the oldest when needed.
Oh c'mon. Is adding a file to git.ignore so serious problem that we need to implement redirection and bother to control the list of session files? The "ignore" in VCS-es is specifically _designed_ to ignore files. The users that prefer to keep their foo.geany in the project directory, but don't want them in the VCS, have already exlcuded it. The ones that prefer to keep foo.geany in the VCS will not ignore the .session file either. So we are only speaking about the ones that want the future settings-only project file, but not the session. Surely they can make a little effort to achieve that?..
This proposal isn't about a proper session management capability, there isn't one that works on enough platforms to be worth including.
Unfortunately. The situation has improved a bit, now that Xfce will have proper sm, and handling the quit message under Win~1 is only a matter of somebody writing it (not me, I don't use Geany inder Win~1). I'm sure that MAC notifies the programs too, but have no idea how.
On Sun, 09 Sep 2012 21:50:02 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
By session data I mean the list of currently open files and MRU list.
I guess it could support some other stuff too like window/find dialogs geometry/position, active tab, position within the file, etc.
So that with periodic save, in the situations that Lex will describe (#2 above), not only the session, but your interface options will break too. OTOH, geany.config and the project files will be very stable...
But why stop half way? Let's have the current geany.conf/foo.geany for the Preferences and Properties respectively, a *.session file for the session and active tab [position within the file and the per-file settings are always stored along with the file name], and an *.interface file for the interface settings. This is the most logical solution, corresponding exactly to the different groups of settings. (Should I add a :) here? Hmmm...)