Copying Emacs from one computer to another

I have been following the system crafter's tutorial and playing around with the config through my `init.el` file in my `.emacs.d/` folder. I wanted to use the same configuration on my windows and mac computers. Is it sufficient to simply upload my `.emacs.d` folder to my github and download it onto my other computers and have emacs work the same way? Basically, are there any other folders I should be aware of in order to copy over everything correctly from one computer to another?

copying your .emacs.d and your .emacs file should get you pretty close Starting from there, you could update your .emacs to not just load existing packages, but use something like use-package to also install packages as needed. I have a historically grown .emacs file that I'm slowly, but steadily converting to use use-package for everything, so all I need to copy is the .emacs file and the .emacs.d folder will populate itself automatically.

Don't commit `.emacs.d/` into git. Just copy/commit your `.emacs` or `init.el` which ever you have. What I do is I have a repo with `init.el` and `emacs.org`. `init.el` tangles `emacs.org` and loads it. My `~/.emacs` just contains a `(load-file "~/source/emacs/init.el")` statement. All files live in git [1]. Emacs will populate `~/.emacs.d/` as needed on each OS/Machine. [1] https://github.com/nakkaya/emacs/

It will depend on whether you have anything that is Windows (or Mac) specific in your config. If so, you can condition those parts of your config on which system you're on. There are several ways to do that. Here is [one example](http://xahlee.info/emacs/emacs/elisp_determine_OS_version.html). If you really are copying your entire .emacs.d folder, then that would include your "elpa" directory which has your installed packages. But it would be more efficient to write your config in such a way that it installs missing packages for you. That way, you wouldn't waste cloud storage on stuff that could be downloaded from MELPA instead. u/anaumann already mentioned using `use-package` for that. Another way you can do it is to call `package-install-selected-packages`. If your packages were installed from the package menu, that command will look for and install any that are missing. Lastly, you might also have some system apps that your Emacs packages depend on. For instance, pdf-tools and lsp-mode depend on non-Emacs programs. The [system-packages](https://gitlab.com/jabranham/system-packages) package is meant to handle that, but I don't know if it works on Windows. This might be one part of it that you'd want to handle manually.

Few sparse things: - to copy your Emacs profile (like any other sw profile home dir) you do not need nor to version it nor someone else computer (like GitHub), an incremental sync tool might speed things but even if that's the most reasonable solution even that is not mandatory. You can even keep your profile on common storage (with eventual filesystem limitation); - copying per se works, but you might find issues with different Emacs version on different systems and something in your personal config that dislike a specific version, different paths for non-Emacs things used from Emacs, ranging from keybindings on different keyboards to org-mode linked files with incompatible paths. Long story short: it *might* work depending on your config/usage or it might not. You can develop a "multi-homed" config that for instance store some paths in variables and assign them depending on the host you are in, like "if hostname == foo and platform win32 then ..." however that's can be tedious to maintain. My general choice is: ok for multiple machines, but with the same environment, at least on OS terms. If that's not possible well... Be reassured that's possible in principle but might be a long path to get it right. About how to sync: if you are in LAN/have a server rsync works almost everywhere, it's monodirectional, you sync from A to B or the reverse, NOT taking into account modifications eventually happened on both sides, but it should be ok. Unison do bi-directional sync, so you change a file in A and another in B you get the correctly most up to date one on both (and you can see differences, decide what to do before acting, per file if you need), but is *nix only, so no Windows (unsure for WSL). Another option, a far different one, but still automated and autonomous is SyncThing (distributed P2P sync). manual upload and download is not a good idea in general because you can always forgot to upload something from A, then upload from B than back to A loosing changes.

This must be the Twilight Zone where the phrase "cloud storage" exists, and yet the available storage space is so tiny that we're worried about how many emacs lisp files we have :) Honestly, I don't think that's a concern. > it would be more efficient to write your config in such a way that it installs missing packages for you I think it's *less* efficient if Emacs then has to go and request and install and byte-compile all of those packages from ELPA (even trusting that there's never any problem doing that). More efficient is having your whole config already installed and working at step 1, without needing to download anything else at all.

use-package just makes sure a package is installed at all(if you tell it to), not necessarily at the latest version. So it might take a few attempts, but the system will end up at the desired state eventually :D I found this quite workable moving between linux and macos a lot..

If they're using a newer version of Emacs with native-compilation, Emacs will have to recompile it all anyway. They're using Github, so you're probably right that the amount of space shouldn't be a concern. When I was using a free Dropbox account, it was enough to push me over the limit.

I also prefer "upgrading a package" to be a completely independent action to "installing my config". If I'm *installing* my config, the only thing I care about is that it works. If I'm *upgrading* something and it breaks my config, I'm prepared for that and can roll back. I'd never recommend combining those actions, as there's then a risk that you'll install a broken config. It depends on whether you're happy to assume that risk of course; but newcomers might not be thinking about that at all.

I upgrade all installed packages quite regularly, so there is usually little difference between what I'm running on my main machine vs what's running on a fresh install... But I get your point.

You don't really wish to commit *everything* in your .emacs.d, just your configuration files. You can [take a look here](https://github.com/amno1/.emacs.d) for an example of what I have in my GitHub repo. Probably more interesting is what I *don't upload* to GitHub than what is in the repo (no packages, temporary files, no private keys, etc), see .gitignore to give you an idea. I don't use use-package nor straight, and I also use hacked package.el and several private repos, some of which are currently not in my GitHub repos (I think), so you can't just clone my setup and use it, but it can give you a picture. Generally I keep in repo just configuration needed to bootstrap my configuration. I also install and upgrade my packages "out of session", which means I do it separately, not when Emacs starts as is commonly done with use-package. When it comes to creating a configuration that works across multiple computers and OS:s, a tip is to keep your .emacs.d as self-contained as possible, keep paths relative to your .emacs.d as much as you possibly can too, and be sure to abstract those you can't into some variable which you can set appropriately either when you generate your init file (if you use literate org setup) or when you start your Emacs by probing for system, computer name etc. That also mean keeping tabs on Emacs own system-dependent behavior where needed. Also try to create your environment to be as similar as possible to each other (programs in your paths, shell scripts you use, etc). It sounds like a lot, but it isn't that hard to achieve.

There are lots of ways to do this but here’s one perspective based on what works for me: - if you already know git, then it’s probably the easiest, widely available sync tool and it provides granular control and versioning - yeah, you can just make a repo with all of your .emacs.d! I find this works well for me as long as I take a few precautions. - what about all the packages installed in elpa/ or manually? Yes, I just put them all in git too. Storage is cheap. And it means I don’t need to worry about the package install process doing something different on different machines. I’ve got byte for byte the same .el files everywhere. I can also use git to rollback bad package updates or bad package upgrades. This is much easier for me than learning some custom way to do this with a special emacs package that might be out of fashion in 5 years. I already know git and this is what git is for, no? - So what about the precautions? I gitignore anything that’s compiled on demand and might be os- or architecture-specific. I gitignore the .elc files, and the compiled binary produced by the emacsql-sqlite package (architecture specific). - I also gitignore certain files in emacs.d/ which essentially record history related to a session of work. For example, the cache files maintained by tramp and the records maintained by bookmarks and other caches maintained by completion tools like ido. Another advantage of just dumping it all in git is you get familiar with what happens in that directory and you spot the 3-4 cases like this pretty quick. - Also, I do need to take care not to install packages that require an emacs version higher than the lowest version I use on any host. - also, I do have some conditional code in init.el, which is mostly there to adapt my initialization to find helper executables and documents which are in different places in different hosts. Basically, I put it all in git, but gitignore build products and host-specific caches and records. Works for me.

not `use-package` but `:ensure`

as I said, it will take care of the installation, if you tell it to ;)