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

Lex Trotman elextr at xxxxx
Mon Sep 10 23:17:52 UTC 2012

On 11 September 2012 04:30, Dimitar Zhekov <dimitar.zhekov at gmail.com> wrote:
> 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. :)

Well, thats the *next* discussion :) (no its not)

>> 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.

The idea is that anything in geany.conf (or project.conf) would be
saved on change.

(There is more to it, but I don't want to start the
> multiply instances discussion now.)

Me neither.  For me thats dangerous and deprecated :)

>> 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.

Sadly its not, keyfiles re-write the whole file, not just the bits
that are changed.  So to save something by itself it has to be in
another file.

 In what situation saving the
> session will damage Geany configuration, but saving the interface
> sessings on exit will not?..

Did I say the current situation was right? Thats why I am proposing to
change it :)

>> 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.

Yes, and I would expect that to be everyone who keeps a project file
in *public* VCSes, nobody else in the world cares which files you had
open last time you did something on the project.

> Surely they can make a little effort to achieve that?..

Clearly you are not one of them or havn't had to try to repair commits
that have included extra files because you forgot to edit .gitignore
or equivalent. :)

>> 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.

The word *portable* still applies, but if you create
then maybe :)

> 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.

Which settings are session and which are config is somewhat arbitrary,
but I think at least some of the interface settings could profitably
be per session, the others saved on change.

> OTOH, geany.config and the project files will be very stable...

Which is the idea :)

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

What? Why not a file per setting, then it would all work fine.  Just
make geany.conf a directory and switch to project.geany directories.


> --
> E-gards: Jimmy
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel

More information about the Devel mailing list