Apparently @kugel- does.
I don't know, maybe @kugel- has more to add, but I can't imagine I'd go to some open source project and suggest adding the Geany project configuration file - I'd be stoned to death because everyone uses a different editor. And I can't imagine I'd want that for Geany itself (which is probably the editor we all here use for Geany development). For instance, with my 8 core machine, I use `make -j 9` in build commands and someone else with a 2 core machine uses `make -j 2` and we won't be happy about each other's settings. Similarly, I use the ProjectOrganizer plugin that stores its configuration in the project but someone else doesn't - should it be committed with or without this configuration?
There are IDEs where you simply have to include the project in VCS because these IDEs define how to build the project. Geany is not such an IDE - there has to be an external build system which is independent of Geany. Geany's project is just a selection of your personal preferences how to invoke the build system and this is not something that should be forced to others.
Could you point me to a project that version controls VS Code, Sublime Text (or similar editor of your choice) to VCS?
Geany devs deciding not to use it this way doesn't mean all other developers also won't.
But we should decide what feature is a good idea and what feature isn't. Blindly implementing every single feature users suggest without considering its implications isn't good for Geany.
Question: did anyone ever actually wanted this feature in those 700-ish open issues we have?
This isn't the only benefit of the config/session split. It is just one of kugel's motivations. A couple possibilities:
Multiple configs could share a session or multiple sessions could share a config. This depends on implementation and the scheme I suggested would need to be modified to support it.
Could you clarify what this is good for?
Options could be stored in different config files with some files overriding others. (@elextr has mentioned being able to change "any" setting in projects...)
If we decide to change any Geany settings in projects, we can do this already.
Projects are not version controlled now because they're cluttered with personal settings, absolute paths, and frequently changing settings that aren't suitable for being shared across multiple users.
As I said, nothing in Geany projects is suitable for sharing among multiple users - it's all personal preferences. And if you want to be able to change any settings in projects as stated above, things will get even worse.
Even if I don't use projects a particular way doesn't mean others won't or that I won't in the future.
If there appears some compelling reason in the future that overweights the drawbacks of of the current design, let's implement it then. But until then it's just the drawbacks and things like "it might be useful" without saying exactly what for.
For moving to a different computer, I suggested having a preference to store the session in the project file. If you don't like having the option, you don't have to use it.
You seem to be a fond of solving everything by adding new configuration options - but if we added configuration options at the rate you suggest adding them, everything would get quickly out of control. And this is even more true with configuration options that are specific to our internal implementation - when there's a configuration option "use CRLF for line endings", everyone knows what it does. If you add configuration option "store session information into project files", nobody knows what it does and what implication it has because it's specific to our implementation.
Simple? Have you seen the 74-page manual?
I've been around much longer than you and I have contributed to that manual too so yeah, I have seen it. And we don't want to convert that file to a 1000-page manual by adding new and new configuration options.