On 11 October 2012 06:06, Dimitar Zhekov
<dimitar.zhekov@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.
> > Save on Quit is needed for the interface preferences, such as View ->
> > Show Sidebar, and the project-less file list. Unfortunately, the file
> > list is saved even with a project open, but attempts to fix it trigger
> > a "multiply instances" discussion.
> >
>
> Yes, Geany does *not* do multiple instances properly, therefore being
> ignored for now. If you do multiple instances with the same project or
> config file it will break (ie not do what you wanted), its just a matter of
> when.
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 ones from save_ui_prefs(). You can't reasonably expect a file save
> > each time the side bar is shown/hidden, or the main window is
> > moved/sized...
> >
>
> 1. why not?
Why not save the document in a temporary file on each SCN_MODIFIED?
You will never lose a single edit action, and surely a current document
content is no less important than, say, the sidebar state. :)
Ok, but why not save the entire program state after each instruction :-D
> 2. which is why they should be in the session file not the prefs file,
> also, to me, if I arranged windows to fit what I was looking at, it would
> be good it that was restored with the project session as well.
Definitely, from using xsm, I know very well how convinient per-project
interface is. But it doesn't really require a session file - we can
store the ui_prefs in our current project file, which is saved on
project close and geany quit.
Agree, though its a separate discussion from this one about separation. (and much simpler)
(Now that I think of it, multiply sessions per project do not require a
session file either.)
Agree
Splitting has it's own merits, of course, and if implemented, the ui
prefs should logically go in the session file.
Agree
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?
Cheers
Lex