`geany.conf and session.conf are basically hard coded (macro defines). This doesn't address splitting config/session in project files. `keyfile.c` and `project.c` are currently parallel keyfile management implementations. The session split doesn't do anything to unify them, and potentially makes unifying them more difficult. (Especially if there's resistance to changing code that's already been merged.)
A minor change that would make unifying geany and project sessions easier is to change the location and filename of `session.conf`. Instead of hard coding it, it could be stored in `~/.cache/geany/sessions` with filename `[basename]-[md5-of-path-of-original-conf].session.conf`. (This is somewhat based on how image thumbnails are cached.)
``` /home/user/.config/geany/geany.conf /home/user/.cache/geany/sessions/geany-e71b0fe665f2c7b4749ddd8bf10243ee.session.conf
/home/user/projects/example.geany /home/user/.cache/geany/sessions/example-6b433b8dd3405c5100ec3000f8e80d48.session.conf ```
So far a "project" is mostly a named session, with various extensions in the past to make it look more like something project.
I, too, would like to change that situation. Store the session part elsewhere (your suggestion is nice), so that the remaining project part is largely static and invariant across systems, so that can be checked in.
Likewise, my goal for the session split is to be able to store geany.conf in my personal "dotfiles" repository that I sync between laptop and workstation.
@elextr @eht16 @b4n is this something you'd agree with? If yes, then we should target that and I'd volunteer to help getting this done.
Store the session part elsewhere (your suggestion is nice), so that the remaining project part is largely static and invariant across systems, so that can be checked in.
This is good to know for when I attempt to extend the stash system.
Nobody is thinking big enough, I suggest an alternative option.
Remove all the project code.
Then make "projects" to use the equivalent of `geany -c ` but selected from the GUI. That way there is no duplicate code and __all__ settings can be setup for "projects" including tweaked filetypes. I have used `geany -c` for several projects I have done where I had to configure stuff not in the "project" files and which I didn't want for my other projects. The only thing needed is the ability to change config from the GUI.
A note on the OP, who will delete the session files? I remember @kugel- being worried about that when `geany.conf` and `session.conf` were side by side, although I don't remember the context of that discussion.
Remove all the project code.
* This will break multiple plugins. * This breaks how users interact with projects. * This is the removal of an existing capability. * Users aren't given any choice in the matter. * etc.
... who will delete the session files?
The same entity who deletes the thumbnail cache. The users, if they care enough about it.
It would be simple to keep a list (in `geany-[hash].session.conf`) of previously seen project files and to clean up session files (every restart, after *n* restarts, daily, weekly, monthly, yearly, never, whatever). (Users with lots of transient config files could choose longer cleanup intervals or "never".)
I remember @kugel- being worried about that when geany.conf and session.conf were side by side, although I don't remember the context of that discussion.
Apparently no longer an issue anymore since the session_split branch has been merged without addressing it.
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.
And to add, changes to stash would be instrumental to this changeover.
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.
You'll need to explain in a *lot* more detail what you have in mind.
Then make "projects" to use the equivalent of geany -c but selected from the GUI. That way there is no duplicate code and all settings can be setup for "projects" including tweaked filetypes.
That seems very... complicated and unweildy to use and implement.
Removing *all* or even just *existing* project code is essentially the removal of all/existing project functionality. That would mean, no more `.geany` project files. You appear to want to replace it with multiple copies of... the entire geany config folder? (Tweaking filetypes involves files other than just `geany.conf`.)
...
You don't appear to really mean "remove all [/existing] project code", but to modify/extend projects in some undefined manner.
And to add, changes to stash would be instrumental to this changeover.
What changes? How do you expect it will be used?
I don't like @elextr proposal. I want project files to be suitable for shipping it with the project itself. Carrying all user preferences (GUI-related or not) is not appropriate.
Apparently no longer an issue since the session_split branch has been merged without addressing it.
Guess @kugel- was persuaded enough not to worry.
Well the session split for projects is not implemented yet. My worries was about where to store <project><session>.conf.
@xiota idea is nice, but the I'm not sure if XDG_CACHCE_DIR is appropriate. Normally it contains files that can be regenerated by programs without user interaction, like your thumbnail example. @admorris wanted to work on it but he disappeared unfortunately.
I don't like @elextr proposal. I want project files to be suitable for shipping it with the project itself. Carrying all user preferences (GUI-related or not) is not appropriate.
I see I wasn't clear enough, sessions would still be split out from projects, which would only contain settings that were needed to be different for whatever the project the user was working on, not every setting but it _could_ change any setting, instead of the current limitations. The point however is to allow (but not force) projects to contain any setting, even tweaked filetype files if its appropriate to the particular project a user is working on.
@xiota this is a first suggestion of an idea, if you are looking for a complete design its not available, we will have to develop it, patience. There may be impossible obstacles, but its the way many other IDEs and other applications work, so I doubt its unimplementable. As to stash, the suggestion would be that stash supports overriding where sources of a specific setting override another. See for example how the [build menu](https://wiki.geany.org/howtos/configurebuildmenu) overriding works. At the moment it does not use stash since stash doesn't support the capabilities it needs, but as you say, there is no reason not to expand stash to do so.
but its the way many other IDEs and other applications work, so I doubt its unimplementable
Do you have an example?
Do you have an example?
Eclipse, depending where I invoke the preferences window from. it asks me if I want to edit the setting in the workbench or the project. I don't know if _every_ setting is overridable, its got far more than Geany, and I'm only a baby Eclipse user.
I'm not sure if XDG_CACHCE_DIR is appropriate. Normally it contains files that can be regenerated by programs without user interaction...
* Same folder as project file – This feels like clutter to me. Why split project files if they're going to be kept together anyway? But depending on what settings are considered "session", it could make sense. * Don't split project file into config/session. If projects are migrated to the stash system, depending on how stash is extended, not splitting project files could be configured as an option. * Add another paths option. Chicken-or-egg problem, for people who consider paths to be "session" settings. * `~/.cache/geany/sessions/` – I suggested this location because the types of settings I'd expect to be categorized as "session" are what Geany manages on its own. There's little consequence if MRU, geometry, position, etc are wiped out. There's some inconvenience if currently open files are lost, but they can be reopened. The cache directory is also long-lived, so session settings wouldn't normally be lost. * `~/.config/geany/sessions/` – This location may be difficult to find to remove left-over session files when project files are renamed or deleted. It wouldn't matter if Geany removes session files for project files that no longer exist. * `/tmp` – This location is potentially wiped out at every boot. "Sessions" should probably be able to persist across reboots.
-----
As to stash, the suggestion would be that stash supports overriding where sources of a specific setting override another. See for example how the build menu overriding works.
#3000 (will be split into ~6 PRs) includes an override for non-GUI settings in stash. I wrote it with plugin use in mind, but it (or something similar) could also be used for projects, sessions, etc.
When I said I'm unsure about XDG_CACHCE_DIR this means: 1) it doesn't mean .session and .geany is next to each other 2) even if it was, you could add .session to .gitignore but .project not 3) you can still convince me, basically I'm undecided between `~/.cache/geany/sessions/` and `~/.config/geany/sessions/`
it doesn't mean .session and .geany is next to each other
I just listed the major options I could think of at the time.
basically I'm undecided between `~/.cache/geany/sessions/` and `~/.config/geany/sessions/`
It depends on what you consider "session" settings. It seems different classification schemes are being mixed up under the "session" banner. For instance, @elextr stated that only settings affecting edited files are config and all GUI settings are session. That seems to better fit division by shared/personal. In a project, settings that affect edited files could be shared, while GUI settings are based on personal preference.
I consider any setting Geany automatically manages as "session", while settings users explicitly set in preferences as "config".
* window geometry and position are managed by Geany/window manager/etc, *not* explicitly set by user in preferences ⇒ session * sidebar/msgwin position, also determined by Geany, though *implicitly* set by user ⇒ session * sidebar/msgwin location (left/right, bottom/right), *explicitly* set by user in preferences ⇒ config * gray area – sidebar/msgwin visibility. There is a setting in preferences. But Geany uses it to save state. Since Geany manages it, I would consider it session. A couple ways to resolve this: + Save the *explicitly* set preference as "config". Save the auto-managed state in "session". Session normally overrides config, but when session is reset, the config is used as the default. + Add a setting for whether to save/restore state or always use the explicitly set config. + Just pick one (config/session) and consider it an "exception" to usual rule.
Using this guideline, pretty much anything in session can be regenerated without consequence (since they'd all be auto-managed). If the session file is lost, the worst that would happen is the user would have to reopen some files. So `~/.cache` would be suitable.
But if "session" files contain a lot of settings that can't be regenerated, `~/.config` might make more sense. But then the config folder could become cluttered with orphaned session files (whose original project files have been moved or deleted). So it would be a bit more important for Geany to be able to periodically clean up the session folder. (Clutter in `~/.cache` is more tolerable, but I'd still want to eventually add cleanup capabilities to Geany.)
I didn't go through the whole discussion so I maybe missed something, just noticed this:
[basename]-[md5-of-path-of-original-conf].session.conf
Does it mean the session information will be lost if the project directory is moved somewhere else? The whole point of #3021 is to preserve the session when the project directory is moved to some other place (which, right now, is quite annoying).
Does it mean the session information will be lost if the project directory is moved somewhere else? The whole point of #3021 is to preserve the session when the project directory is moved to some other place (which, right now, is quite annoying).
If the project config and session are split, any scheme that is able to distinguish projects with different paths, but same basename, will risk allowing the session to be orphaned.
* There could be an option to *not* split the session from the project. In that case, relative paths would continue to work. * The scheme may be extensible to allow it to work with relative paths, at the risk of being unable to distinguish between projects that share the same basename. * If Project Preferences is extended to be able to move project files, the session files could also be updated. * Project files could contain a copy of the hash to enable locating and moving old session files. * You can suggest other ideas.
Well, what's actually the reason for this split? What problem does it try to solve? To me it seems it just introduces its own set of new problems.
Well, what's actually the reason for this split? What problem does it try to solve?
@kugel- Has [described](https://github.com/geany/geany/issues/3015#issuecomment-975987322) it this way:
Store the session part elsewhere (your suggestion is nice), so that the remaining project part is largely static and invariant across systems, so that can be checked in.
Likewise, my goal for the session split is to be able to store geany.conf in my personal "dotfiles" repository that I sync between laptop and workstation.
As I've [noted](https://github.com/geany/geany/issues/3015#issuecomment-979876697), there are ways to preserve your use case.
Store the session part elsewhere... so that the remaining project part is largely static and invariant across systems, so that can be checked in.
But does anyone actually want to check in that? To be specific, when this change happens, will we, developers of Geany, want to have the project file checked in the Geany repository? I personally would say no. And I assume that one of the reasons why you store your project files outside the project directory is that it isn't version-controlled so you actually aren't a user of such a feature anyway.
There could be an option to not split the session from the project. In that case, relative paths would continue to work.
Either do it or don't do it for everyone - having to deal with settings that are hard to explain to users and having to maintain 2 different modes of session storage isn't exactly what Geany needs.
The scheme may be extensible to allow it to work with relative paths, at the risk of being unable to distinguish between projects that share the same basename.
No idea what this means.
If Project Preferences is extended to be able to move project files, the session files could also be updated.
Won't work if you move the whole project directory to a different location. (Not even talking about moving it to a different machine.)
Project files could contain a copy of the hash to enable locating and moving old session files.
This is probably the only sane option but then you are facing problems like sharing session files by 2 different projects when you have one `original_project` and make its copy to `project_backup` - both will then share the same session files.
Nobody prevents us to write code like that but I would leave such features to editors like Eclipse. Geany is a simple editor, we should come up with simple solutions that are easy to reason about and easy to explain to users.
Store the session part elsewhere... so that the remaining project part is largely static and invariant across systems, so that can be checked in.
But does anyone actually want to check in that?
Apparently @kugel- does.
To be specific, when this change happens, will we, developers of Geany, want to have the project file checked in the Geany repository?
1. Maybe. Depends on how it's implemented. 2. Geany devs deciding not to use it this way doesn't mean *all* other developers also won't. 3. 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. + Options could be stored in different config files with some files overriding others. (@elextr has mentioned being able to change "any" setting in projects...)
And I assume that one of the reasons why you store your project files outside the project directory is that it isn't version-controlled so you actually aren't a user of such a feature anyway.
I store projects in a centralized location so I can easily switch among them. I'm not against checking in a project file if the issues are resolved. If a suitable project file were version controlled, I'd be able copy or symlink it. This makes new-project creation easier for new users because they don't have to do it at all.
* 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. * Even if I don't use projects a particular way doesn't mean others won't or that I won't in the future.
There could be an option to not split the session from the project. In that case, relative paths would continue to work.
Either do it or don't do it for everyone - having to deal with settings that are hard to explain to users and having to maintain 2 different modes of session storage isn't exactly what Geany needs.
Different people have different preferences, so I am for having more options, provided the program logic they control is not too complex. The current config/session split implementation is likely not the end. With appropriate changes, preferences could very easily be moved around in different files.
Project files could contain a copy of the hash to enable locating and moving old session files.
This is probably the only sane option but then you are facing problems like sharing session files by 2 different projects when you have one original_project and make its copy to project_backup - both will then share the same session files.
* I would guard it with an option because it affects version control. (The hash would be stored only if the option is enabled.) * The hash for different projects would be different. When the project file is copied to a new location: + Geany would recognize that the stored hash differs from the generated hash. + Geany would locate the old session file via the stored hash and copy it to a new file using the new hash. + The sessions for the two projects would then be allowed to diverge.
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.
Geany is a simple editor, we should come up with simple solutions that are easy to reason about and easy to explain to users.
Simple? Have you seen the [74-page manual](https://www.geany.org/manual/current/index.html)?
See #3022
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.
To be clear, I mostly dislike the design that sessions are stored somewhere deeply in `.config` about which users don't know and which is quite fragile. To be honest, I suggested the very same thing here
https://github.com/geany/geany/pull/450#issuecomment-87497461
but had 6 years to realize it was a bad idea ;-). (No, frankly, basically I abandoned #450 because I realized this isn't a good match for Geany.)
If it turns out turns out that splitting projects/sessions has some big benefits (and I don't see that myself now), I would much rather see `project.geany`, `session.conf` side by side in the same directory. I'm not super-thrilled about having one more file to care about but I could live with that.
I like options because they preserve different use cases. Save location is extremely easy to change. If you want side-by-side files, you can have it via an option. Let other people store their sessions elsewhere. If you insist on not providing options, you're bascally saying everyone should be forced to use your personal preferences.
I mostly dislike the design that sessions are stored somewhere deeply in .config about which users don't know and which is quite fragile.
That's part of why I suggested `.config`. It's a well known location that's easy to find and not deeply nested.
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.
I use Geany also for work and there we happily accept editor-specific files in the repos if it helps our engineers to get their job done. This is especially true for Windows and OSX stuff where we commit the whole VS and Xcode project metadata (multiple files).
I also wouldn't take it as a given that each and every FOSS project would stone you to death, that seems extremely exaggerated. I can imagine a lot of project maintainers aren't opposed if it helps on-boarding contributors or making their lifes any easier. After all, it's just a text file that doesn't hurt anybody else.
If we accept geany.geany within Geany itself it would indicate that the scheme is working as intended, so I wouldn't say no.
I use Geany also for work and there we happily accept editor-specific files in the repos if it helps our engineers to get their job done.
Good employer :-).
This is especially true for Windows and OSX stuff where we commit the whole VS and Xcode project metadata (multiple files).
Yes, but this is a necessity - in XCode for instance the project itself defines how to build it and I, too, have it committed for the macOS launcher of Geany here:
https://github.com/geany/geany-osx/tree/master/Launcher/geany/geany.xcodepro...
Geany, on the other hand, doesn't define the build process itself and the way I see it, it's a bunch of personal preferences of how to run the build process or launch your project and these may differ user to user. I gave the example with `make -j 2` vs `make -j 9` (and yeah, this will be gone if we move to meson - kudos for your work in this area btw.), plugin settings and I think that nobody wants to see the Geany project file as modified in git permanently if he customizes it to his needs.
Or to tell it in another way in terms of XCode:
xcode project ~~ autotools or meson build system and is committed xcuserdata directory ~~ Geany project - personal settings
Since the way I see Geany projects is personal preferences only, I don't see much need for the project/session split (and having to deal with the various problems discussed above).
github-comments@lists.geany.org