Global Settings

Yes, though I think Selective Sync only works at the folder level. I don’t think you can tell DropBox to, say, sync your .obsidian/plugins folder but not the .obsidian/workspace file. Still, it’s probably worth a shot to see if it works well for you.

:fire: But make a backup first! :fire:

I personally copy the hidden obsidian folder with my required settings to any new vault or copy back.

2 Likes

Ah that’s too bad about Dropbox.

SyncThing, which is free and open-source, does support file or folder exclusions. And plus doesn’t even need the cloud since it can just sync two folders on your local machine and run in the background at all times.

Please please please don’t pollute the home directory. Following an open-source standard and using the XDG Base Directory structure to store user-level files. Every OS has this idea as a way of avoiding home directory pollution. If Obsidian were an open source project I would expect these types of options available:

Path Description
XDG_CONFIG_HOME/obsidian User-level configuration options found in the current vault-level files appearance.json, app.json, community-plugins.json, core-plugins.json, graph.json, hotkeys.json.
XDG_DATA_HOME/obsidian This directory should hold the downloaded data for all plugins and themes. The path vault/.obsidian/plugins/... seems an inappropriate place for this data.
vault/.obsidian Vault-level overrides and extensions to those at the user level.

Optionally, having flags to override these values when calling the Obsidian binary would be helpful in creating one-off vault configurations. Something like:

$ /usr/bin/obsidian --config-dir ~/custom/obsidian/configs/ --data-dir ~/custom/obsidian/data
3 Likes

global HotKeys, please
even just a save to / load from global hotkeys woudl be enough to manage multiple vaults

I’ve read a lot of these topics to understand the developer’s rationale and I’m still confused. Per-vault settings are inane. Do we really have to write out use cases and justifications for something so obviously needed?

No, because there are hundreds of high-demand requests that many find obvious. They just need to expand their team.

I see this is still not implemented. Just created 4 new vaults and I wanted the settings from the first one copied across with plugins etc. However when i copy the .obsidian directory the new new vaults have the notes listed from the first vault which is NOT what i wanted. Which of the many files in the .obsidian directory lists the notes so i leave that one out from the copy?

They came from the recent files plugin! if i don’t copy that its fine.

1 Like

Also don’t copy the workspace.json file!

1 Like

I use a File/Folder Comparison/Sync app (DeltaWalker because I happen to have a license, but it’s not very intuitive) between my main vault and other vaults.

These are the things I include:

  • The .obsidian folder
  • My templates folder which I call _templates

These are the things I exclude:

  • workspace, workspace.json, workspaces.json, starred.json, graph.json, backlink.json, cache
  • In appearance.json, I copy everything except the line cssTheme because I want to have different themes so I can quickly distinguish the vaults. (You could just keep the accentColor different instead)
  • Some plugins’ data:
    screenshot.2022-10-31T094945Z
2 Likes

Instead of using a sync-app, why not using symlinks like @mano suggested?

I am still not sure which folders/files I can link without might going into any issues.

With other words: which files/folder under .obsidian are vault-independent? and can be changed from any current vault I am in?

Symlinks are very risky, especially for obsidian settings: How Obsidian stores data - Obsidian Help

Before I sync, I make sure to close Obsidian

4 Likes

getting back here. since i have a few new vaults, and i forgot to copy all Hotkeys … but i don’t remember which vault was the original source one … so i have 12 vaults each with different hotkeys :slight_smile:

Haha, that’s a good example, have you already located the config which you need to sync between vaults?

So as the help says

  • Symlinking things under the .obsidian/ directory in order to share them between vaults has a high chance of corrupting your settings, unless you really really know what you’re doing. If you decide to go this way, at least have backups.

I just need someone who really really knows the configs! :smiley:
Done anyone know such guy? :sweat_smile:

A list of all things/configs (inside .obsidian) that are safe to symlink between vaults would be much appreciated.

It blew my mind that I spent all this time setting up obsidian only to discover that it only works for the particular project I had open when I was setting it up. These are general application settings that have nothing to do with the project and have no business being scoped to the project. I can’t imagine why anyone would ever want to scope things like keyboard shortcuts and gui themes for one individual project. I expect an text editor to have the same basic behavior regardless of what text file I am editing. Look at literally any other test editor. Now I need to memorize a different set of keybinds for every single project? What kind of insanity is this? Can we please give users a reasonably consistent experience so they can have a realistic opportunity to learn how to use the application?

Forget about per-project configuration. It’s not important. Just move all the configuration to be globally scoped. That’s the simplest approach that the small dev team should be able to handle easily. Per-project configuration is a “nice to have” that can be added on top of global configuration, but it’s pretty limited in utility. I doubt the vast majority of users would be interested in it. So let’s not worry about the complexity from managing separate configuration sources for now. Just make it exclusively global. Should be trivial for established users to migrate settings from a project folder to a global folder.

3 Likes

Not everyone’s vaults are scoped to project level.

1 Like

I have a simple command-line tool I wrote in Python a while ago to help manage the settings files in the .obsidian folder: Obsidian Settings Manager (OSM).

OSM can:

  • list all your Obsidian vaults (I have more than three dozen, lol)
  • copy settings from one primary vault to the other vaults
  • execute a command against all vaults (e.g., git status)

I never made a big deal of announcing it, because the right way to do this is in an Obsidian plugin, rather than an external script.

But it is public and open source, and perhaps still of use. I haven’t updated it or stress-tested it in 1.5 years, but it still generally works. I can’t provide much user support for it, but I am happy to receive bug reports / feature requests in the OSM repo’s issue tracker, and would be happy to review pull requests. (Or to see it rewritten as an Obsidian plugin!)

Check it out: https://github.com/peterkaminski/obsidian-settings-manager

Please read the warnings and disclaimers before using Obsidian Settings Manager.

2 Likes

I realize a lot of the ideas below have been posted above, but it makes for difficult reading for half of this to be “as [username] said”.

$HOME/.obsidian

This will be exactly the same as the current per-vault directory, however all plugins and themes which are installed from any vault will have the actual js/css/manifest stored here. There will also be a data.json here, which will use the same developer API as the current per-vault one, just via Plugin.saveGlobalData/Plugin.loadGlobalData instead of the existing ones (no breaking change is an added bonus).

Also no workspace.json or other vault-dependent fields.

$vault/.obsidian

This remains mostly unchanged. The main difference will be that the plugins directories contain only the data.json file. It would be nice for plugin devs to have access to a Plugin.loadMergedData rather than being required to do their own comparisons and object merges should they need to handle hierarchy, which would also reduce plugin bundle size and execution times.

Changing and loading settings

Could do a deep merge on the JSON with every change, could do that with some fancy caching to save execution time,
Probably best to load the global configs, then iterate the local ones and set those for this app session. This ties in with the point below about global-first settings.
Additionally, when a setting is changed, no matter if local or global, Obsidian can just do what it’s doing now and set it on the fly without additional processing.

For storing the settings then, a toggle at the top of the settings subwindow (and other subwindows within such as themes or plugins) can have a simple toggle at the top for switching between changing globally and changing locally.
I would argue this should default to global, and if you close the settings then open them again, it should reset to global. To edit settings locally should require opening settings, and clicking a toggle.
My reasoning for this is because every other piece of software I’ve come across has global-only settings. People are used to changing a setting and it applying for all uses of the app. It’s the same reason content scrolls vertically and double-tap is like; everyone knows how it works, so working in the same way reduces friction. If a user changes something locally, works for an hour, then decides to change a setting, they won’t necessarily recall that they’re in local mode, even with the activated toggle.
The toggle should be labelled of course, “global settings” when off, “vault settings” when on, and an on-hover/focus tooltip on that text briefly explaining what it’s for an a link to the relevant section in the docs.

This toggle’s status should be made available on Plugin.vaultSettingsMode so plugin developers can have a signal for when their plugin might want to use Plugin.saveData vs Plugin.saveGlobalData.


It’s been two and a half years since this feature request was opened.
If developer time is an issue, I’ll happily come in temp and implement this for you as quickly as possible (email me).
If it’s a design choice to continue to not have this feature, that’s frustrating for a lot of us.

1 Like