On 2 October 2012 00:43, Colomban Wendling lists.ban@herbesfolles.orgwrote:
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):
- 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 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.
- 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. 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 (not to mention potential performance issues).
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 :)
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. 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 :)
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 :)
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, but that could also change if it was easier to share project files.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel