#12

This would be great, ideally it’d be great to have one dotfile generated only for the hotkeys, this file could easily be shared accross vaults and to other people.

Currently, what I do to share my hotkeys accross vaults is to copy the .obsidian file (a hidden file in the vault)

this not only copies hotkeys, but also all settings, such as plugins and editor settings.

This is a workaround and I’m still not sure if I’m missing downsides to this approach.

In mac, for showing this hidden file in finder, go to your folder of the vault that has the shorcuts and press

Cmd + Shift + .

now you can copy this file to your other vault.

If you are in Windows or linux just search “how to show hidden files or dotfiles”

hope that helps, I’d love to know if there’s a better approach

2 Likes
#13

afaics each vault is a separate instance. I don’t think there’s much that’s ‘global’.

#14

Yes, but as I suggested above, Obsidian could e.g. support a per user hotkey configuration in ~user/.obsidian in addition to vault/.obsidian. Each vault’s instance would first lookup the per user configuration and then merge in the configuration from its vault. Of course, global configurations could also be stored under /etc or in the Windows registry.

2 Likes
#15

Hi all! I just installed Obsidian today by the recommendation from a colleague. So far it looks great but I’ve ran across a few annoyances, this being one. I spent a considerable amount of getting the shortcuts right for me. I was quite surprised to find the shortcuts didn’t work in the “help vault”.

As already suggested, it would be great if one could define global settings under ~/.obsidian or ~/.config/obsidian which could then be overriden by the vault specific settings. Then again this complicates things as it wouldn’t then be straightforward to edit global/default settings vs. vault specific. It would require something like VSCode’s settings management.

For me the keyboard shortcuts matter the most. It would already help if the keyboard shortcuts would be defined in a separate file from config. This way you could create a symlink to this file between projects (as a workaround).

1 Like
#16

I agree, @ristomatti specially with what you said on making the shortcuts a separate config file. This way it can easily be shared with others (and across vaults) without having to copy the whole .obsidian directory.

And like you said, from there symlinks could be created without any issues.

1 Like
#17

Is there any solution to restore default setting for hotkeys?

#18

Came here looking for a solution for global settings, saw this thread. +1 to this feature. :heart:

2 Likes
#19

Same here, I’m starting out and only have 2 vaults and the frustration of “why isn’t this working I already changed the hotkey (or some other editor setting)” has already bitten me.

A home directory to store the global settings that are overridable by each vault setting sounds great to me.

1 Like
#20

I’d like to expand this to include Plugins, CSS etc… It seems to me that all of this should be stored in a global obsidian repository, and then vault-level preferences select/apply what is wanted/needed. If I’m not mistaken, VS Code is basically like this - Extensions, Themes, Settings etc… get applied per Workspace.

As it stands, I have different plugin versions installed in different vaults, when you’d think that updates would be applied globally (along with being able to select which plugins are turned on for each vault, and how their settings are configured in each as well)

#21

Are there any benefits to having the per-vault settings (hotkeys, plugins, css etc)? I can’t come up with a single one.

1 Like
#22

Well, there’s no reason to activate the daily notes plugin in a vault with no daily notes, Zettelkasten where you’re not using Zettelkasten, file explorer in a completely flat vault, etc. etc. You might want different themes to visually distinguish your vault windows. On and on and on…

That being said, having a global hotkey configuration is an excellent idea, as is the ability to specify plugin default settings and global defaults.

I’ve been thinking a bit about making a settings-sync plugin that would let you update vault settings to match changes in a per-user file, and vice versa. It’s potentially quite doable, but certain aspects are challenging because Obsidian and its plugins save all settings, even ones that are still in the “default” state, and there is no way to distinguish between “this setting is still in the default state” and “this setting was deliberately set to the default”… which is kind of important for such a thing.

That can be worked around, though, by the plugin keeping a local record of what it has or hasn’t “published” to the main config and what settings have been chosen to “override” the local settings.

The other big complication is naming/documenting settings, as plugin’s settings .json files aren’t documented in a way that a settings sync plugin could use to provide a helpful UI.

1 Like
#23

But is there really any harm in Daily Notes being active even if you’re not using it? Just don’t use it - same for ZK etc. The tiny amount of extra memory used is a small price to pay vs. having to reconfigure these plugins for every vault.

On your other point about different themes for each vault, yes I can see that being useful. Theme and individual CSS snippet toggles should be a per-vault setting. The CSS snippets repo itself however, should be global.

I admire your ambition to want to roll your own plugin to handle this, but I think something this close to the core should be done natively and with full support of the devs behind it. Anything less will most likely just lead to bad things happening.

1 Like
#24

@luckman212: I totally understand where you are coming from. But perhaps there is a solution that could address both of our concerns. You asked about:

Although I probably am in the minority opinion for this, I like the option of having the ability to install a few plugins for a specific vault then back that up onto an external hard drive and keep my current operating system drive only with vaults that have no plugins.

Then, when I want to use a certain plugin feature with that specific set of content, I can connect the external drive while offline, and use it to accomplish a goal knowing my important vaults on my operating system are locked down and encrypted during this process. I also know that none of my important vaults are affected or have to install new updated versions of plugins just for this purpose.

I am sure there are other reasons why separate vault settings are helpful. But if I knew installing a plugin meant having to “reinstall” it for all vaults and regularly letting them connect to the internet, I’d be less likely to install some plugins.

I know I am a bit paranoid in this sense, and do understand there are very few limits on what electron apps can access, but this at least makes me feel I am doing my best to be careful. I figure that as time goes on with no issues arising, more trust can be established and things will change for me.

Thanks

#25

Virtually every plugin I make is like that, actually. Hot-reload, symlinks, note folder autorename… even Tag Wrangler. Definitely the ones I haven’t released yet (like Pane Relief). I’m not really sure what “bad things happening” you mean, either.

But as far as syncing settings go, a plugin for that isn’t even all that ambitious, so long as you reload the vault after importing new settings. I’ve previously written a modular configuration management system for Wordpress, which has, shall we say, a far less elegant and uniform approach to plugin configuration. (For example, in WordPress there’s no way to programmatically tell what settings belong to which plugin.)

Anyway, if I can do that without the WP core devs “full support”, I don’t see why I’d need it for Obsidian. (Not that I have any plans to do it any time soon; my Pane Relief plugin is much higher up on the priority list for finishing and publishing, once I get per-pane history done and maybe an option to prioritize activating existing panes over opening new ones.)

#26

Currently, if I have a custom theme that I use in 2 different vaults, any change I want to make to the theme I will have to make to the obsidian.css file in each of the vaults.

It makes more sense if it were possible to direct Obsidian to access custom themes in just the 1 folder.

1 Like
#27

Not sure about Windows, but on Mac and Linux you can just create a hard link to the .css file which will ensure that editing either will update both as they are just one file in the filesystem existing in multiple locations.

#28

@Rishi: I am on a Mac!! So, that gives me hope. I tried to create a symlink but that does not work, Licat confirmed Obs does not accept symlinks.

Say I have a folder that is my vault, let’s call it Vault1. I also have another called Vault2.
Then I have a folder with custom themes, let’s call it Themes. In there I have a custom theme that is called obsidian.css, of course.

Now, how do I create a link in Vault1 and Vault2 to obsidian.css in that Themes folder?

#29

Symbolic links are soft links ln -s source target. We need hard links for this I think.

Make sure to have a backup before following any of the actions below:

I just tested and can confirm this works with one caveat. So, with your example of three folders Vault1, Vault2 and Themes, you’d do something like,

cd /path/to/Themes
ln obsidian.css /path/to/Vault1/obsidian.css
ln obsidian.css /path/to/Vault2/obsidian.css

It would be simpler if you didn’t need to have a separate themes folder and assuming you already have an obsidian.css in Vault1 but none in Vault2, then you’d just use this,

ln path/to/Vault1/obsidian.css path/to/Vault2/obsidian.css

This will create an obsidian.css in all the vaults which will seem like separate files but will be essentially the same. So if you edit something in one file, you can open the other to confirm that it’s changed as well.

The one caveat is if you have both the vaults open in Obsidian and then modify the obsidian.css file, Obsidian will only update to show the changes in the vault whose file you opened. For the other vault, you’d need to close and reopen for it to fetch the updated file. I am guessing this is because it might be due to some internal caching. But the only thing you need to remember is to close/reopen the vault after making any changes to the obsidian.css.

2 Likes
#30

@Rishi: OK, I used situation 2: no themes folder and an obsidian.css in Vault1 but none in Vault2

That’s funny: for the part path/to/Vault2/obsidian.css I get “Operation not supported”.

Update: I understand why it is not supported: my vaults sit on a virtual drive (VeraCrypt), so the “ln” command does not work. It does work between 2 folders in the home directory (I tested it between ~/Documents and ~/Downloads), it does not work either if one folder is in the home directory and the other on the virtual drive :disappointed:

#31

Oh that’s something I didn’t consider. Hard links only work inside the filesystem they are in. In your case, I think the best solution might be to setup a file sync which automatically replaces the older one in either folder with the newest one. Not sure of the VeraCrypt system, but on a Mac the easiest way to do it would be using Folder Actions which I use often or something like Hazel.

1 Like