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

[Thomas Martitz]

Am 18.11.2013 10:12, schrieb Lex Trotman:
>
>
>
>     Reviving this old thread because the annual discussion naturally
>     came up again this year.
>
>
> It must be the change of season that triggers it, and it wasn't even 
> one of the usual suspects this time :-)
>
>     Your proposal lists issues that are rather orthogonal to
>     separating the session file list, thus I think these should be
>     dealt with later. As a first step I would propose we split out the
>     session file lists to separate files (normal session: in the same
>     folder as geany.conf, for projects in the same folder as
>     $project.geany). This should solve the problem checking project
>     files in as well as enabling to sync geany.conf across machines
>     without affecting opened files.
>
>     If one made such a patch, would it be accepted? It should be
>     relatively trivial, only complicated by backward compat code to
>     read session informations from the old location.
>
>
> I think we got fairly close to an agreed solution on IRC, but I don't 
> think there was an exact common understanding.  Since the IRC 
> discussion was fairly noisy (communication wise) I have tried to 
> describe my best understanding of the most agreed with solution.
>
> Please note this is what I think the majority agreed with, its not 
> necessarily any individuals solution.
>
> The basic idea is to separate the user session files list into a 
> separate file.  The discussion applied mostly to the projects, since 
> only the OP who triggered the discussion is trying to store user 
> config in a VCS.  For the user config it is expected that simply 
> having a session.conf file containing the session specific data (files 
> list, open project at least) stored in the same directory as 
> geany.conf is a suitable solution.
>
> Since there are lots of project config files, and they can be stored 
> in ~/projects or in the project trees (or anywhere) and because 
> existing projects are single files the solution is more complex.  The 
> majority agreed:
>
> 1. instead of being a single file, the project config becomes a 
> directory like the user config
>
> 2. various names were suggested, but no clear winner emerged, 
> suggestions included $project.geany, geany.$project and 
> $project.conf.d.  Objections included $project.geany is the existing 
> name and may be confused or overwritten by an old version of geany and 
> $project.conf.d is ugly.  Making it a define was suggested, which is 
> fine during development, but a permanent solution must be selected 
> prior to merging the change.
>
> 3. initially that directory contains the config file (which is the 
> existing project file without the session files list) and the session 
> files list file.  Retaining the $project.geany name for the config 
> file or changing it to geany.conf to match the user config were 
> suggested, no conclusion was reached.  Similarly using 
> $project.session.conf or just session.conf were suggested for the 
> session file.
>
> 4. over time more data can be added to the project directory, possibly 
> becoming pretty much the same as the user config directory.
>
> 5. the user is responsible for setting their .gitignore (or equivalent 
> for other VCSes) to ignore the session file.
>
> I say again, this may not be anybodys exact solution, but its what I 
> think was agreed by the majority.  If you think I have misunderstood 
> then shout, but don't complain just because its not your personal 
> solution.   I am posting this because I don't think we all had the 
> same understanding of what we were agreeing.


That matches my understanding: For each Geany project a directory is 
created that follows the $HOME/.config/geany layout, except that 
geany.conf is replaced by $project.conf (but I agree it could be just 
fixed at project.conf). Initially this is only for the specific issue at 
hand: the session file list and the rest of $project.geany. The layout 
would also allow plugins to store project-specific stuff plus 
potentially allow projects to override some $user config (though this is 
not something we have talked about yet).


>
> Now for the further discussions.
>
> Assuming the above to be correct I suggest:
>
> 1. Project and user session file formats should match to allow the 
> same code to store both.  The fact that the storing the current 
> project in the project session file is not needed doesn't matter.
>

I agree.

> 2. For user config, keeping the same name for geany.conf is ok since a 
> new geany can simply ignore session info in the geany.conf file if the 
> session.conf is present.  Accidently overwriting geany.conf with an 
> old version won't damage anything but won't update session.conf.
>
> 3. For project config the new version should use names that don't 
> match existing project file names since the new config is a directory 
> and an old geany trying to read it would get very confused.  An old 
> geany may also overwrite the directory with a file if its the same 
> name.  Also I see no point in including the project name on the config 
> and session files inside the project config directory, its just more 
> filepath manipulation needed for no gain, use the fixed names 
> project.conf and session.conf.  The project config file should not be 
> geany.conf as it is currently not the same format.
>


Old Geany couldn't read it since it's a directory, and I don't think you 
can possibly overwrite a directory with a file, even accidentally. You'd 
need to delete the directory first. But it may be confusing to the 
users, indeed.


> 4. Although partly orthogonal to the current discussion, we should 
> find any places in Geany where config is not stored on each change and 
> fix them so the now separate config file does not need to be saved at 
> quit.  So only the session file needs saving on quit and we don't lose 
> config changes when the desktop shuts Geany down abruptly (or the rare 
> crash :-).
>


Right but this should be a separate step. Let's get this separate 
session file up first.

> Personally I would be willing to accept the above solution despite my 
> misgivings about the need to .gitignore the session file and previous 
> attempts to work around that need.
>


Awesome.