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

[Dimitar Zhekov]

On Thu, 11 Oct 2012 10:16:13 +1100
Lex Trotman <elextr at gmail.com> wrote:

> > > On 10 October 2012 06:58, Dimitar Zhekov <dimitar.zhekov at gmail.com>
> > wrote:
> > >
> > > > a project-less
> > > > build -> set build commands -> ok saves the changes under filedefs/
> > > > immediately ("save filetypes now" in the mailing list). Just fill some
> > > > commands, OK, and grep ~/.config/geany.
> > > >
> > >
> > > It doesn't save the config file though, so no non-filetype settings
> > saved.
> >
> > Yes. Curiosly enough, these are "ui prefs"...
> 
> Eh? not sure I understand you?  In case I wasn't clear if in the build->set
> build commands dialog you modify the make command to say fred, click ok,
> cat geany.conf it isn't stored, close Geany, cat again and it is stored.
> That is it is not saved on ok.

You were very clear, and your description is entirely correct.

Unlike the normal filetype settings, the non-project, non-filetype
settings internally belong to the ui_prefs, the same class as sidebar
position etc. They are not file type settings at all.

> > But not saving the file list in geany.conf, if we have a project open
> > and so the list is already saved in $project.geany, is _not_ actually
> > related to multiply instances. Maybe I should propose it again, it's
> > a very simple change.
> 
> Unless the project was open in multiple instances, then you can have issues
> with both geany.conf and project.geany, so no improvement I'm afraid.

The point of this change would be not to improve reliability, storage,
multiply instances or whatever, but to stop losing the project-less
file list by replacing it with the project file list, which is
completely unnecessary.

> So far the only algorithms presented so far are:
> 
> 1. sessions in the user directory and identified by UUID in the project file
> 
> Pros,
>   retains the session when working tree deleted,
>   minor VCS advantages,
>   single session even if multiple copies of project
> 
> Cons,
>   need to set .ignore,
>   when to delete the session files,
>   single session even if multiple copies of project
> 
> 2. Dimitars version of 1. with an extra indirection
> 
> Pros,
>   supports multiple sessions per project (though as said above may not be
> needed to support that)
> 
> Cons, as 1.
> 
> 3. put session file in the same directory as geany.conf or project.geany
> 
> Pros,
>   simple,
>   deletion of session files explicit,
>   multiple copies of the project can have different sessions
> 
> Cons,
>   loses project session file if the working tree is deleted,
>   sessions not shared by all copies of the project
> 
> In general 3. looks like the least worst, any further comments?

As I realized later, (2) is orthogonal to separation/storage, and can be
implemented even with the current files, for example by extending
[files] to [files_#]. So the real options are (1) and (3).

(It seems to me that, with an extra signal or two, multi-sessions can be
implemented as a plugin; but it should be written after the splitting,
if any, takes place.)

-- 
E-gards: Jimmy