>
> 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 didn't mean that only part of the file was changed, I meant that the configuration save is triggered by *all* the dialogs and menu items that can change settings, for eg unless I missed it, the set build commands dialog doesn't trigger a configuration save after an ok (though it does save filetypes).
> 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.
>
Every UI or programatic change to a setting needs to be checked that the configuration/project is saved, unless you have already done that?
I agree that we should do that but its another discussion, although it does affect this one.
[...]
> 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()).
For project files in the tree it is reasonable that they may be on the remote, and well, on those funny file systems, g_file_set_contents() doesn't work :(
My cunning? implementation puts the session file in the user config directory, which *hopefully* is local, or at least on a fast reliable nfs/samba share.
> (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.
But only the session needs to be periodically saved, and that should be local in my split implementation.
[...]
> > 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.
>
What I mean here is that I agree that putting a session file in the same directory as the project file isn't a big issue.
>
>[...]
> 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 :)
files one has, and you can't rely on the user changing some weird magic
value for them not to loose session data.
I wasn't being so complex as you seem to think, I was just saying keep the last N project related sessions, like the recent files list, we could even use the recent projects list and only keep sessions for those?
> > 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" ;)
Heh, yeah the two issues are a bit mixed,
1. as I said to Dimitar, the main reason for the proposal is to put projects in VCS without the noise from session data while still allowing users project sessions.
2. any possible improvements to the reliability of session saving via periodic save or even save on file open/close are a secondary (but still useful) by product.
> 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.
I don't understand what you are saying here, the project files *do* store build commands, if your project uses different tools, eg scons not make, then that is stored in the project file and gets restored in Geany whenever you open the project file. This is *very* useful and is the original reason I extended the Geany "build system" back in 0.19. And having that information in a project file in VCS distributed with the project source is then *very* useful as well, but ATM you have to turn off project sessions to avoid lots of noise commits, and so we are back to the original reason for the thread :)
Cheers
Lex
Cheers,
Colomban