Remove all the project code.
Ok, "remove all the __existing__ project code", obviously there is then new code based on my suggestion to be added.
This will break multiple plugins.
Why? Plugins should not be writing to these files directly, they should be writing to the `g_key_file` structure obtained from Geany, as `project-organiser` does. It doesn't matter which file that structure maps to if it has the settings in it.
This breaks existing API.
Why? We can leave project related functions, they just have to act on different structures inside Geany. Then they can be deprecated for a few years, then they can be removed at a point that the ABI is broken anyway.
This breaks how users interact with projects.
Why? I havn't even mentioned what the GUI should look like, and to be clear I would want it to be at least the current capability (but with a more intuitive `New Project` dialog).
This is the removal of an existing capability.
No, it is the extension of an existing capability to be much __more__ capable, projects would be able to set _any_ setting.
Users aren't given any choice in the matter.
Because there is no choice to make, unless for some reason a user wants to remain straight jacketed by the existing projects capability. As I said above, it is not removing any capability so it doesn't need a choice by the user.
Apparently no longer an issue since the session_split branch has been merged without addressing it.
Guess @kugel- was persuaded enough not to worry.