Move config files and cache files to ~/.config/logseq for following the XDG Base Directory Specification.
The XDG Base Directory Specification (XDGBDS) unifies the location of commonly needed kinds of files, such as configuration files, data files, caches.
Now, the plugins and settings of Logseq located in ~/.logseq. It would be nice to move ~/.logseq to ~/.config/logseq for following the XDG Base Directory Specification.
It seems that Logseq will call get-ls-dotdir-root for searching the path.
I'm by no means a clojure expert(in fact this is the first clojure program I've written) but I think something like this should work.
We first check if XDG_CONFIG_HOME is defined or else we check if $HOME/.config directory exists else we create logseq folder in home folder
(defn get-ls-dotdir-root
[]
(let [lg-dir (cond
(System/getenv "XDG_CONFIG_HOME") (str (System/getenv "XDG_CONFIG_HOME") "/logseq")
(fs/existsSync (str (.getPath app "home") "/.config")) (str (.getPath app "home") "/.config/logseq")
:else (str (.getPath app "home") "/.logseq"))]
(if-not (fs/existsSync lg-dir)
(and (fs/mkdirSync lg-dir) lg-dir)
lg-dir)))
It is recommended to put plug-ins, configurations, and so on into a note library, as obsidian does.
Yes please! writing into the bare ~/ directory is restricted in my environment. Please support XDG_CONFIG_HOME!
Any updates?
This should be a priority!
I'll take a look at this but no promises on a timeframe. In the meantime PRs are welcome.
@Bad3r What do you think of @shubham-cpp's solution?
@Haze-sh taking a look at it and will test and see. idk if @shubham-cpp tested it.
The issue here is that this might be a breaking change. Will have to figure out how the team wants to handle that.
A simple sloution would be to check if ~/.logseq exists and XDG is defined then move the folder to XDG.
Or we can just check if the folder exist and use it. Leaving it up to the user if they decide to move it
@Bad3r I didn't test it, since I don't have proper clojure environment setup. This was just a quick and dirty solution I came up with
Or we can just check if the folder exist and use it. Leaving it up to the user if they decide to move it
This sounds like a reasonable solution to me!
Thank you for letting me know. BTW, ~/.config/logseq ($XDG_CONFIG_HOME/logseq) already exist if you didn't know. It just that the folder structure is not clear to me completely.
~/.logseq might need to be moved to $XDG_CACHE_HOME/logseq
related issue for xdg-open: #7471
Thank you for letting me know. BTW,
~/.config/logseq($XDG_CONFIG_HOME/logseq) already exist if you didn't know. It just that the folder structure is not clear to me completely.
~/.logseqmight need to be moved to$XDG_CACHE_HOME/logseq
The stuff in $XDG_CONFIG_HOME/Logseq (case-sensitve in some filesystems) is just misc. electron files and won't interfere with the config and plugin folder (ex.: discord stores its settings there as well).
The solution by @shubham-cpp won't work unfortunately since you can't access System/getenv in clojurescript (You have to use nodejs apis).
If it's fine i will work on this issue with the approach of checking for a existing $HOME/.logseq folder and using $XDG_CONFIG_HOME/Logseq otherwise.
@sallto sounds great. Please do and keep us updated
If it's fine i will work on this issue with the approach of checking for a existing $HOME/.logseq folder and using $XDG_CONFIG_HOME/Logseq otherwise.
So we can move our logseq folder $HOME/.logseq to $XDG_CONFIG_HOME/logseq and keep continue to our life. Btw keep the name of the folder with small letter on $XDG_CONFIG_HOME/logseq.
flatpak logseq $XDG_CONFIG_HOME is $HOME/.var/app/com.logseq.Logseq/config
@queeup flatpak package is not official. Follow the official logseq standards by using Logseq with a capital L
@Bad3r, not officially but usually linux $HOME/.config directory folders use lowercase letters. That flatpak referance just for info. What I was telling you not about flatpak.
@sallto , This is from XDG Specification
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used.
Better to add $HOME/.config too because for example my Fedora Silverblue $XDG_CONFIG_HOME is empty.
@Bad3r, not officially but usually linux $HOME/.config directory folders use lowercase letters. That flatpak referance just for info. What I was telling you not about flatpak.
I understand. Still remains a capital L must be used. This is the name format used by logseq for all operating systems. Please maintain convention with the code base as much as possible.
You are using big L folder name for configuration folder with Windows&Mac because their specification is that. Linux is lowercase. I don't care lower or upper case. Just I want to point this.
You are using big L folder name for configuration folder with Windows&Mac because their specification is that. Linux is lowercase. I don't care lower or upper case. Just I want to point this.
Many projects such as Thunar, VirtualBox, VeraCrypt, USBGuard, Bitwarden capitalize the folder name in .config.
Not sure where it specifies that the path should be in lower case
Right but most of the programs follow lowercase. If we're already using lowercase folder name($HOME/.logseq) then why not keep it consistent.
Better to add $HOME/.config too because for example my Fedora Silverblue $XDG_CONFIG_HOME is empty.
Yes, I think the check should be check for $HOME/.logseq then $XDG_CONFIG_HOME/logseq and finally check for $HOME/.config/logseq
Right but most of the programs follow lowercase. If we're already using lowercase folder name(
$HOME/.logseq) then why not keep it consistent.
Because $XDG_CONFIG_HOME/Logseq already exists
Yes, I think the check should be check for
$HOME/.logseqthen$XDG_CONFIG_HOME/logseqand finally check for$HOME/.config/logseq
The first two should be swapped.
As per the spec:
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used
So, the correct algo would be:
- Check if
$XDG_CONFIG_HOME/Logseqexists - Check if
$HOME/.config/Logseqexists - Check if
$HOME/.logseqexists
Use the first one found. If none exist then:
- Use
$XDG_CONFIG_HOME/Logseqif$XDG_CONFIG_HOMEis defined - Otherwise use
$HOME/.config/Logseq
@Ramblurr $HOME/Logseq (step 2) should not be checked. This folder will never be created or used by logseq. It's possible that a user created a graph named Logseq and placed it in their home directory. In that case this check will cause unexpected behavior
@Ramblurr $HOME/Logseq (step 2) should not be checked.
You are correct of course. Sorry, I wrote that comment on my phone, which was a mistake. I've updated my comment to reflect what I really meant!
Yes, I think the check should be check for
$HOME/.logseqthen$XDG_CONFIG_HOME/logseqand finally check for$HOME/.config/logseqThe first two should be swapped.
As per the spec:
$XDG_CONFIG_HOME defines the base directory relative to which user-specific configuration files should be stored. If $XDG_CONFIG_HOME is either not set or empty, a default equal to $HOME/.config should be used
So, the correct algo would be:
1. Check if `$XDG_CONFIG_HOME/Logseq` exists 2. Check if `$HOME/.config/Logseq` exists 3. Check if `$HOME/.logseq` existsUse the first one found. If none exist then:
1. Use `$XDG_CONFIG_HOME/Logseq` if `$XDG_CONFIG_HOME` is defined 2. Otherwise use `$HOME/.config/Logseq`
I think in our case, we should deviate from the standard and check for $HOME/.logseq first, since for all existing installations both $HOME/.config/Logseq and $HOME/.logseq exist, but only the latter contains the important config files. Otherwise all existing installations will reset to default settings.
Any update on this?
This is a breaking change, as new config directories will be set to XDG_CONFIG_HOME. We need the fully discussion & acknowledgement from the whole community about the default value. (not only GitHub - GitHub is just covering a small portion of users) Better we should make this as a list that easy to be expanded
I think it better suit the feature-request as it's a relatively big changing and might potentially break existing user settings.