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

Colomban Wendling lists.ban at xxxxx
Tue Oct 2 13:01:55 UTC 2012


Le 02/10/2012 05:03, Lex Trotman a écrit :
> 
> 
> On 2 October 2012 00:43, Colomban Wendling <lists.ban at herbesfolles.org
> <mailto:lists.ban at herbesfolles.org>> wrote:
> 
>     Le 10/09/2012 06:36, Lex Trotman a écrit :
>     > Hi All,
>     >
>     > Its about that time of year when we have our annual discussion on
>     > separating session data from config/project data :)
>     >
>     > 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)
> 
>     TBH until proper multi-instance configuration sharing, I don't see
>     what's so great with "not rushing at quit time" since we already also
>     save one pref/project-prefs apply.
> 
> 
> Are all settings saved on apply? not just the prefs/project prefs ones?

I doubt we make a difference when saving the config file -- since as you
said yourself saving only a part of a keyfile isn't that easy --, but I
don't know for sure.

>  I thought there were some that still didn't for one reason or another,
> maybe that should be changed as a separate thing anyway, in which case
> you are right, the "rush" only applies to session data.
>  
> 
> 
>     > 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.
> 
>     Why would the session save go wrong?  There is no reason I can think of
>     that would make periodical session saving less safe than settings
>     saving.
> 
> 
> Read "not happen" for "go wrong" then.  Not happening because Geany is
> killed by the WM/user is the most common way saving settings/sessions
> goes wrong.

Again, I don't see the point.  If saving the configuration doesn't
happen because Geany get killed, if it was separated and still only
saved on change wouldn't change anything.

> If the save happens its unlikely to be a problem so long as
> its on a local disk which isn't full.  If the project file is on a
> network share or worse still, on a ftpfs/sshfs/httpfs file system then
> lots can "go wrong" and the chances are increased by periodic saving

Oh dear, configuration on an unsafe remote.  OK, that's an argument why
saving config periodically might not be that safe -- although normally a
network failures would result in *not* saving the file, not corrupting
it (given that we use an atomic write like g_file_set_contents()).

> (not to mention potential performance issues).

Well, performance issue is inherent to periodic saving, it being session
only or whole config doesn't change anything.

>     > The only disadvantage for user config (that I can see) is that it adds
>     > one file, say geany.session.conf alongside geany.conf
> 
>     That's definitely not a problem in the $GEANY_CONF_DIR.
> 
> 
> Agree, but I had to think of *some* disadvantage to seem fair and even
> handed :)

Hehe, you should've rather have listed advantages ;)

>     > 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.
> 
>     I agree with Dimitar, if somebody is able to add a file to a VCS she
>     must be able *not* to add that file.  Is there *any* VCS around that
>     adds files without asking before, unless explicitly told so?  Nobody
>     sane will do `git add .` or `svn add .` for committing changes.
> 
> 
> Well, git add is part of the normal workflow, editing .gitignore isn't.

Yeah, but you *choose* what you add, you don't add the whole project
directory but maybe on the first import.

>  But I guess if the project file is being stored in VCS then you would
> expect .gitignore (or whatever svn etc use) to be edited already to
> exclude .session and .gitignore to be stored in the VCS as well.
>  
> 
> 
>     > 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.  That way, when a project is
>     > opened, it is easy to uniquely find the session file if it exists.
>     > Using things like filenames, project names etc will always have
>     > clashes.  Libuuid is used by GTK so it will always be available on all
>     > platforms we use and so making the UUID is one call. (Pity GTK doesn't
>     > expose it though)
>     >
>     > 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.
> 
>     PLEASE, no.  This is IMO the easiest solution to make the fix worst than
>     the issue.  Not removing files would leave more and more useless files
>     (not an option), and cleaning is almost impossible to do well -- your
>     proposition might remove actually used sessions as easily as having >
>     MAX_SESSION projects (not an option either).
> 
> 
> Heh, heh, I was going to just say, sort by access time and delete the
> oldest one before creating a new one, but then I remembered that all my
> disks are mounted noatime :)

Even if access time was reliable you'll never know how many project
files one has, and you can't rely on the user changing some weird magic
value for them not to loose session data.

>     > This proposal isn't about a proper session management capability,
>     > there isn't one that works on enough platforms to be worth including.
>     >
>     > Any thoughts welcome.
> 
>     Reading my mail above, I see it might sound like I think $subject is
>     just a bad idea.  No, I think it would be a quite good thing, and for
>     weird people adding project files to their VCS [1] would be most
>     welcome.  I also think that separating session and settings will
>     probably help to someday improve the settings sharing between instances.
> 
>     The only problem is that I don't see immediate and tremendous gain, and
>     that I don't like the proposed solution -- not that I have a better one.
> 
> 
> Damn! The point of starting the thread was to see what other
> implementations there are :)  If I thought it was a perfect solution I'd
> have made a PR by now :)

No no, what I asked was "why is $subject useful?", because I thought
(and somewhat still think) that the arguments weren't for $subject but
for "periodic save" ;)

>      On the first point, I'd be happy to be proven wrong though, maybe I
>     just don't see the light.
> 
>     Regards,
>     Colomban
> 
> 
>     [1]  Yes, I don't really see the point.  OK, the settings we have in
>     project files might be useful for the project.  Indentation type & with,
>     and EOL style.  First two are saved in each file by well known editors
>     (vim, emacs).  Generally when people put project files in their VCS it's
>     because those project files are used as build system too.
> 
> 
> Yes ATM the main use-case is build system settings,

Hum, what I meant that our project files *are no* a build system, so the
current use case I see is only indentation settings and maybe line
ending settings.


Cheers,
Colomban

> but that could also change if it was easier to share project files.
> 
> Cheers
> Lex



More information about the Devel mailing list