On Thu, 11 Oct 2012 10:16:13 +1100 Lex Trotman elextr@gmail.com wrote:
On 10 October 2012 06:58, 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.
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:
- 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
- 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.
- 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.)