emacscollective/no-littering

Some themed variables break when used across devices

Closed this issue · 5 comments

Hello,

My .emacs.d is synchronized between several machines, and I have recently run into problems with org-publish, where it would complain about not being able to find some files. It turns out that it stores cache information in org-publish-timestamps-directory, and that this cache information contains absolute paths.

The default value of this variable is ~/.org-timestamps, which is safely out of the synchronized .emacs.d, but with no-littering, it was now shared between all my devices, and breaking.

I don't think that it means that this variable (and all paths used to store a device-specific cache) shouldn't be themed: users who do not use the same configuration folder across devices will not have a problem. But maybe there could be a user-level setting to theme them or not?

Do you just git add -a? You should probably decide on a case by case basis and when you decide not to track a file, then you should add it to .gitignore so that you don't have to think about it again in the future.

The folder is synchronized in the cloud and/or on a USB key. What I don't want to synchronize, I place (or leave) outside of the .emacs.d directory, that's a lot easier than figuring out how to (persistently) set ignores for my cloud provider or for rsync.

I also use git, but for those files which I don't mind making public, so basically a few .el and some selected package settings.

that's a lot easier than figuring out how to
(persistently) set ignores for my cloud provider or for rsync.

I'm afraid you'll have to do that anyway and once you have done it you should add a note to the wiki so that others who are in the same situation don't have to figure it out for themselves.

No, the only thing I had to do was (setq org-publish-timestamps-directory "~/.org-timestamps") after loading no-littering. Definitely easier than settings up ignores.

It would be cleaner if no-littering kept track of the previous setting of the value of each variable, but in this case I don't expect any breaking change from future updates.

If it's only that one path, it's not worth it of course, but if other cases come in the future, I suggest thinking about at least implementing a blacklist. ;)

I'd gladly edit the wiki to let other users know to be wary about this variable, but... what wiki exactly do you have in mind?

This wiki, which... oh wow... has just one page and it is already about this subject, more or less: https://github.com/emacscollective/no-littering/wiki/How-to-synchronize-only-some-files-between-machines. So you don't even need to add a new page. 😃