spacemacs-cache-directory is ignored in dotspacemacs/*-init

zabbal commented 5 years ago

Description :octocat:

spacemacs-cache-directory variable is ignored when set in dotspacemacs/user-init or dotspacemacs/init After closing Spacemacs the .cacheis created in the old location with auto-save subdirectory and spacemacs-buffer.el files If that's the expected behavior and it should be set someplace else than it would be great to get this documented.

Reproduction guide :beetle:

Set spacemacs-cache-directory in dotspacemacs/user-init to non-default value, for example "~/.cache/emacs/"
Close Spacemacs

Observed behaviour: :eyes: :broken_heart: .cache is re-created at old location

Expected behaviour: :heart: :smile: The value of spacemacs-cache-directory should be used.

System Info :computer:

OS: gnu/linux
Emacs: 25.2.2
Spacemacs: 0.200.13
Spacemacs branch: master (rev. c7a103a77)
Graphic display: t
Distribution: spacemacs
Editing style: emacs
Completion: helm

Layers:

(helm auto-completion better-defaults emacs-lisp git github markdown jabber semantic ibuffer mu4e emoji c-c   csv emacs-lisp ess go graphviz haskell scala shell-scripts org themes-megapack command-log finance pandoc pdf-tools restclient systemd search-engine
  (shell :variables shell-default-height 30 shell-default-position 'bottom)
  spell-checking syntax-checking version-control)

System configuration features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11

ViktorHaag commented 4 years ago

This might be because the default location of the cache directory gets set in core-load-paths.el (and the location of spacemacs-auto-save-directory and pcache-directory gets set based on that initial value), so if you reset it later (in dotspacemacs/user-init or dotspacemacs/init), the auto-saves and pcache will still go into the original location, I'd expect.

zabbal commented 4 years ago

So there's another variable in addition to spacemacs-cache-directory which governs the location, sets differently and has higher priority? That's highly confusing and seems like a bug to me - it's better to have single source of truth for this kind of stuff.

ViktorHaag commented 4 years ago

So there's another variable in addition to spacemacs-cache-directory which governs the location, sets differently and has higher priority?

What I mean to say is that spacemacs-cache-directory gets set in /core/core-load-paths.el, and then

spacemacs-auto-save-directory gets set to its string value, via expand-file-name
pcache-directory uses its value, via (concat "pcache/")
the cache directory gets created if it doesn't already exist

These things all happen before (presumably) user init configuration can happen in .spacemacs, so the directory will get created, containing the pcache, and auto-save directory set there.

Presumably, then, if you wanted to do something else via .spacemacs, you'd need to move three things not just one, and I'm not sure if spacemacs uses any of these directories before your user settings happen (it's possible stuff could get cached in pcache, maybe?).

In my fork (on the develop branch), I rearranged core-load-paths.el and built the cache directory relative to user home, and not relative to spacemacs-start-directory, but not everyone would be comfortable tweaking the core engine that way, I would guess...

Given the way that spacemacs seems to be organized, I'm not sure there would actually be a better way to set the cache directory for user preference without messiness... I guess that there could be a higher level setting exposed in .spacemacs which, if set, spacemacs would move things around after the fact (but that seems really messy)... there may well be a reason that spacemacs core needs to set and have ready the cache directory so early in the init process.

zabbal commented 4 years ago

I wonder if XDG support in upcoming Emacs 27 could help to resolve this.

github-actions[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

zabbal commented 3 years ago

The issue is still valid.

lebensterben commented 3 years ago

The issue is still valid.

@zabbal Does this problem exist on develop branch?

ViktorHaag commented 3 years ago

@lebensterben -- I believe it does, yes; my remarks above were all made in the context of using the develop branch... (I've edited my remarks above to make that more clear).

zabbal commented 3 years ago

What's the point of reporting issues if they'll be closed by some bot regardless of the comments anyway?

duianto commented 3 years ago

This one fell through the cracks, and we didn't remove the stale label in time. Sorry about that.

A recent commit seems to indicate that this might be handled automatically in the future: [CI] remove stale label when issue updated https://github.com/syl20bnr/spacemacs/commit/a862d1ac5f76fca79dffdc2f12e901e98645eb68

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

github-actions[bot] commented 4 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!

pataquets commented 4 months ago

Feeding the stalebot here. Issue still valid. While I'm at it, cross-linking to @puzl's #4018 related which also got closed by stalebot. Also, notice #7818 is related, although it seems to me the reverse of this, which may be of interest.

pataquets commented 4 months ago

Anyway, @zabbal, you're welcome to let us know if the issue still stands. If it does not, we can just let the stalebot run next time and the above linked issues will serve as redirects for those getting here from Google.

smile13241324 commented 2 weeks ago

We will need to reorganise the loading process a bit to make this possible. Right now the cache directory is set according to your user-emacs-directory.

I assume the most elegant way would be to add a new var to the dotfile but this is read to late right now. Lets see if I can get up with something.

syl20bnr / spacemacs