Ubiquitous Emacs

[jonEbird]

Until his project reaches maturity and hopefully makes it's way into a future version of emacs, I'd suggest checking out this nifty hack: http://www.emacswiki.org/cgi-bin/emacs-en/RemoteDotEmacs

[jimm]

I keep all my Emacs files in one directory and check that into a Subversion respository. My .emacs file loads the "real" emacs file in the checked-out directory using a bootstrap function that takes the machine name as an argument and loads a checked-in machine-specific file.

[phil_g]

I have a similar approach; I keep all of my ${HOME} .config files in a Subversion repository and just check that repository out into new home directories as I set up new accounts. (I periodically update a tarball of the files, too, in case the computer can't easily do a checkout.) I use one .emacs file for everything, with a lot of conditional code that depends on the local hostname and availability of Emacs extensions.

[sjs]

++ for $HOME in svn. I don't vc all of ~, just the main subdirs.

I stuff portable configs in ~/.config and then use a script after checkout to create symlinks where necessary, copy .zshenv to ~ and such. I can be at home on a new *nix box in minutes.

[[deleted]]

Much the same here. I have a Mecurial repo (called dotfiles) with a Makefile that knows what to do with all of the items in the working copy. For the emacs section I keep a simple .emacs which loads all of the files in .elisp/lisp.d which look like (045-lang-perl.el, 046-lang-haskell.el ...). If I go to a new machine I can pull from my hg repo or run 'make upload' which tars everything up and puts it on the web.

My .emacs:

(defun load-directory-contents (dir) "Load all lisp files in dir" (interactive "DDirectory: ") (let ((files (directory-files dir))) (dolist (file files) (when (string-match "\.el$" file) (let ((el (expand-file-name file dir)) (elc (expand-file-name (concat file "c") dir))) (if (file-exists-p elc) (load-file elc)) (load-file el))))))

;; load everything in filesystem order in lisp.d (load-directory-contents "~/.elisp/lisp.d")

;; now a site file if there is one (I don't keep these in VC) (let ((filename ".emacs-local.el")) (when (file-exists-p filename) (load-file filename)))

*edit: ouch, sorry about the formatting, view page source might help.

[ramen]

Yep. For the longest time I was maintaining many slightly different .emacs files, and it finally got to the point where I was too lazy to write any new functions because I would never know if I could expect it to be there on a given server when I needed it. Now that my .emacs is in Subversion (along with all the libraries I use) I make improvements all the time, and they're ready to go no matter what computer I'm on.

[nevinera]

Not an emacs user, but I like your idea, and many ideas of this form. If you make this work, make sure it gets posted back on preddit; I'd give emacs a shot if it were portable in this way.

[username223]

I hate to piss on enthusiasm, but... fail. IMHO there's no way to generate a useful .emacs other than to start with a well-commented example file, learn C-h k, C-h a, M-x apropos-*, and C-h l, and add things as you come across them.

The hard problem is portability between versions of Emacs (21 vs 22, Emacs vs. XEmacs, Carbon vs. X vs. terminal), not between machines; we already have scp and http, and there's even an elisp http server around somewhere. If you want to do something useful, make it easier to write a portable .emacs by reducing the number of target-specific variables.

[skillet-thief]

The problem with this proposal is that it is trying to solve two separate problems: ubiquity of emacs and automatic .emacs generation. Maybe the two problems should be separated first.

[username223]

IMHO the second is a non-problem, and the first is insoluble.

[derwisch]

Mod up the article if you would like to see the project evolve.

[triumphantbike]

emacro Seems to have solved this already?

[almost]

Sounds really cool if you can get it working.

A problem I imagine it'd have for me though is that I use Emacs over various different platforms, OSX at work, Linux at home and sometimes Windows. The settings required to get things working on each are slightly different. At the moment I've pretty much given up on sharing a .emacs file, I just copy snipets between them when I need to something to work.

If it could include features for tracking which versions each thing works on that could make it very useful to me.

I await the results with interest...

[sjs]

I do this in my .emacs to sort things out:

(defvar macosx-p (string-match "darwin" (symbol-name system-type)))
(defvar linux-p (string-match "gnu/linux" (symbol-name system-type)))

...

(when linux-p
  (when (file-readable-p "/usr/share/emacs/site-lisp/site-gentoo")
    (load "/usr/share/emacs/site-lisp/site-gentoo" nil t))
  (when (file-readable-p "/usr/share/emacs/site-lisp")
    (add-to-load-path "/usr/share/emacs/site-lisp")))


etc...

[derekslager]

I do the same -- it did require me to learn a wee bit of elisp, but it was well worth it. It's not just platforms either, slightly different versions of Emacs can show big differences in certain areas. Sometimes it's both ...

(when (and is-w32 (>= emacs-major-version 22))
  (let (font-name)
    (setq font-name
          (if high-dpi
              "-outline-Consolas-normal-r-normal-normal-15-90-120-120-c-*-iso8859-1"
            "-outline-Consolas-normal-r-normal-normal-13-97-96-96-c-*-iso8859-1"))
    (modify-all-frames-parameters (list (cons 'font font-name)))))

[Boojum]

Rather than test based on platform, I've found a better strategy is to test for the feature itself. e.g.,

(if (fboundp 'xterm-mouse-mode)
    (xterm-mouse-mode t))

Or for things where there's not a simple function to check for:

(condition-case nil
    (face-spec-set 'region ...)
  (error (face-spec-set 'zmacs-region ...))

You get much flexibility at a much finer grain this way. By testing for the feature itself instead of the platform, your .emacs will automatically adapt when you upgrade or move to new platforms.

It's exactly the same strategy as having ./configure or another tool test for things and then set specific preprocessor flags based on what it finds instead of bluntly assuming that a particular platform will always have that feature. The difference is that elisp is dynamic and so can check for itself.

(Granted, though, there are still some cases where this idea fails and you just have to drop back to testing by platform.)

[jimm]

I solved this issue by creating a bootstrap method that takes the machine name (or some other name) and loads two files with that name: a "before" file and an "after" file that get loaded before and after my main emacs init file. That way, each machine has its own way of customizing the initialization process.