[Geany-devel] Separating session file lists from config (again)

Dimitar Zhekov dimitar.zhekov at xxxxx
Mon Sep 10 18:30:18 UTC 2012

On Mon, 10 Sep 2012 14:36:32 +1000
Lex Trotman <elextr at 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):
> 1. 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.)

> 2. 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 at 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...)

E-gards: Jimmy

More information about the Devel mailing list