Keep up to date with config changes with "Store config.edn modifications in a separate file"

Feedback Feature Requests
1

Instead of having users modify the config.edn file, have a user-config.edn file that supersedes the defaults. This way any updates or changes to config.edn will automatically be made when Logseq is updated without the user needing to occasionally download a new config.edn file and copying over previous changes.

2

@Luhmann Agree this workflow could be improved. A workaround until we have something in the app is to look at the latest commits in the authoritative config.edn - History for templates/config.edn - logseq/logseq · GitHub

@cannibalox has some other interesting solutions to this workflow too

1 Like
3

+1
if it’s ever implemented, I’d prefer to see the file named config-user.edn rather than user-config.edn though, to keep the alphanum sorting close to config.edn.

backlinking my related post from the other topic:

copy pasting a related post from discord (01/03/2022 ) :

The config.edn template workflow has always bothered me : newer settings introduced with a new logseq version can’t be seen in existing graphs as the config.edn can’t be updated automatically.

Currently the only way to ‘update’ a config.edn with new settings is by checking changelogs, then manually comparing with the current github source, or by creating a new empty graph to generate a new default config.edn, then compare/edit.

There should be a way to automatically get new available setting/config options after an update.

short-term / medium-term proposal :

Maybe there should be a separate config.edn and a config-user.edn similar to style.css vs custom.css ? or similar to how config files are set-up in sublimeText or VSCode (default settings, user settings, workspace settings) :

  • the default config.edn would contain all available options + comments and gets updated automatically, user is not supposed to edit it manually.
  • the config-user.edn would override contents of config.edn and contains specific user-settings that differ from the default of config.edn, journal queries, etc…

I realize this is only a short-term/medium-term solution that is not great in terms of user-friendliness/ux,

long term / ideal solution :

ideally a GUI should handle all options, with maybe an additional freeform textarea for advanced users who want to manually add specific flags/overrules (similar to a custom.css textarea in most website builders) .
Users should not have to edit config.edn at all, only add additional settings via the textarea.

1 Like