[REQUEST] Option to not overwrite config file

[reitzig]

Is your feature request related to a problem? Please describe.

I keep my btop config as part of revisioned dotfiles. There, I configure my "basic"/"default" btop preferences.

Now, sometimes I open a "specialized" instance -- for instance a stripped down window tucked in the corner to keep an eye on memory usage of expensive computations:

Whenever I quit such an instance, my config gets overwritten, if only with the selected frames. While I can restore my "defaults", it's annoying.

Describe the solution you'd like

I would like -- by CLI option and, ideally, config file setting -- to turn off config-save-on-close.

It may be useful to have an explicit save function from the settings menu, but I'd be fine to turn the new option off when I want to, say, change the theme.

Describe alternatives you've considered

None

[deckstose]

What about btop -c <file>? Would that work for you?

[reitzig]

I don't think so. I don't want to maintain multiple config files; I want all instance to read the same config, but not to write to it automatically.

[deckstose]

https://github.com/imwints/btop/tree/push-uzslmpmwoztp

[ghuh]

Yeah, I agree, this would be an awesome feature. I keep all my configs in a git repo that I sync between machines so having this update automatically is really annoying.

I'd prefer to just turn it off by default, but a save option in the menu would be a nice bonus.

[nickjj]

Indeed, this is an issue all the time for common things:

• Open btop
• Sort processes by memory to troubleshoot something

At this point a git diff is created if you happen to have btop configured to sort by cpu by default. In this case I didn't want to rewrite my config, I just wanted to sort things to find a 1 off process for that session.

I'd like to see save_config_on_exit = True added as a new config option to remain backwards compatible but if folks want to disable that they can. Maybe over time it can default to False.

[WieeRd]

+1 for this.

There are options I want to have saved and applied on every launch, and options I tweak on the fly while using Btop and want to have it discarded on quit. Btop saves everything every time. It also recreates the whole config file along with other options. I strongly prefer having only the small set of non default options saved in my dotfiles.

@reitzig

I want all instance to read the same config, but not to write to it automatically.

Inspired by this, I'm currently coping with chmod u-w ~/.config/btop/btop.conf to lock the config intact. It's a duct tape solution with a bit of inconvenience, but it does work.

[danrneal]

+1 for this.

I see three pretty good options that would solve this:

1. Allow us to configure options by env vars (eg. HTOP_THEME="tokyo-night"). This would mean that saving btop.conf in our dotfiles would no longer be necessary, we could just save our overrides as env vars.
2. Have an option in btop.conf. AUTOSAVE=false. Then when we commit it with our dotfiles without the annoying diffs.
3. Allow us to use multiple confs like this: htop -c btop.conf -c btop-overrides.conf. Then we would only need to commit btop-overrides.conf which wouldn't change and still use btop.conf which would change but is uncommitted.

[deckstose]

For 1. and 3. we don't have the foundation to do this. But 3. seems much simpler to implement right now.

For 2. we can discuss whether my proposed solution

https://github.com/imwints/btop/tree/push-uzslmpmwoztp

would work or if we need a config option, or both, a config option and a CLI flag.

Maybe you guys can react to this message with what would work for you, and also share what you are trying to achieve.

CLI	Config	Emoji
✔️		👍🏽
	✔️	❤️
✔️	✔️	🚀

[danrneal]

Speaking for myself with what I'm trying to achieve.

I use https://www.gnu.org/software/stow/ to backup many configs (such as .zshrc, kitty.conf, etc.). That way when I'm on a new machine, I can simply git clone dotfiles and then run my setup.sh script which calls stow. Now my terminal is MY terminal. I have all my aliases, I have all my tools, I have all my configs, everything is themed the way I like.

I am pretty sure your config solution that you cited, actually solves this problem best.

[nickjj]

The only concern I have with the flag is it requires you to call btop in a different way than normal. Instead of btop it would be btop --lock-config. That requires everyone to either alias btop or wrap btop in ~/.local/bin/btop.

Having save_config_on_exit = True in the config allows you to call btop the same way with both approaches but I think we can do better.

My perfect world solution would be:

• btop always has its own default config that's referenced internally with no need for a config file on disk
• If a config file exists in a known location, read it
• Allow the config to be partial so you can overwrite the settings you want to differ from the defaults
• Never write a new config to disk automatically

Basically always merge a user's config into the btop defaults. No new flags and no new config options necessary.

Lots of tools work in this way as danmeal mentioned, it's the "override" model. I only suggest we don't depend on env vars.

[deckstose]

You are right, and this is how modern software should work. Ideally this is what we do from the beginning.

I was just trying to find the easiest solution possible without too much changes, the current implementation is very inflexible and would require a rewrite for almost anything else. Aristocratos said earlier this year that he wanted to make changes to the config system that already exist somewhere but couldn't publish yet, so I was hesitant.

[nickjj]

Ah I wasn't aware of that conversation.

If that rewrite is going to be on hold for a long time maybe the flag approach is good enough for now?

• For folks who have dotfiles (the target audience), defining an alias or wrapper script is not a big deal
• For folks who don't care, nothing changes for them (they probably won't know the flag exists)

Seems like a very reasonable solution in the short term?

[aristocratos]

@deckstose @nickjj The configuration rewrite will take some time. In a perfect world C++ would already have reflection (which would make configuration code alot better). This is slated for C++26, but will likely be a long time before the default compilers in most distributions support this.

There is some libraries that emulate this behavior that I'm experimenting with.

But in the meanwhile adding a save_config_on_exit option (default: true) would be trivial. Could also add functionality that toggling this option from false to true in the menu immediately triggers a config save.

That way you could set up your desired options and then toggle this option from false to true back to false to save it.

[nickjj]

But in the meanwhile adding a save_config_on_exit option (default: true) would be trivial. Could also add functionality that toggling this option from false to true in the menu immediately triggers a config save.

This sounds great. As an end user it would solve the problem.

Especially with https://github.com/aristocratos/btop/pull/1399 being recently merged.

With both features working together, a workflow could be:

• Set save_config_on_exit to false in your config
• Commit your btop config to your dotfiles
• Using btop doesn't ever change your config on exit
• After updating btop, you can run diff <(btop --default-config) ~/dotfiles/.config/btop.conf to see what changed so you can ensure your local config is up to date with the latest options

Thank you for such a wonderful tool btw.

[aristocratos]

@reitzig @nickjj Added in e969f43

New release pending later today.