Is there a way to write .emacs that will always support upstream compatibility?

Question

I have been using Emacs since version 18. Emacs Lisp is not my usual programming language, but many years ago I spent some time learning it before creating .emacs, which is better (for me) than any GUI IDE today.

It was a one-time job, and since then I completely forgot how to program in lisp.

Alas, every time I update Emacs (18> 19> 20> 21> 22> 23), something in my .emacs breaks and I end up spending too many hours (sometimes days) fixing them.

In many other languages ​​that I program regularly, you can write code that never expires. In emacs, on the other hand, I can never predict how things will change. For example, [M-TAB] , which worked before version 21.4.1, no longer works in version 23 and should be replaced with "\M-\t" . Another example is dired-omit-toggle , which was used to work in version 21, but stopped working in version 22, being replaced by dired-omit-mode .

Now I know that if .emacs doesn’t do much, you can write "almost empty" .emacs, which may (possibly) remain compatible with future versions.

But my .emacs are huge, designed to work on many different operating systems (and their various versions, versions and versions, including systems without a GUI) without a single change. We would like to have an API core or a subset guaranteed always.

Is there any way to write .emacs that will always support upstream compatibility?

If so, where can I find a cookbook or authoritative recommendations for this?

Answer 1

Use (when (boundp 'some-variable) …) or (when (fboundp 'some-function) …) around any piece of code that uses a specific function. (While you're on it, start with (require 'cl) for those older versions that don't have a built-in when .)

If all else fails, highlight emacs-major-version , emacs-minor-version and running-xemacs (defined as (string-match "XEmacs\\|Lucid" emacs-version) ).

Avoid syntax and library functions that are only supported in newer versions.

Rarely does something break when you stick to documented interfaces. Therefore, try to find a way to do what is mentioned in the manual, and only lean back on changing some random non-configurable variable if you do not see another way. In my experience, there is always a fairly simple way to get something to work in all versions (at least with GNU Emacs, XEmacs, sometimes the hardest to please) if you allow random conditions.

For example, "\e\t" always worked for M-TAB . With dired-omit-mode return to dired-omit-toggle if the first does not exist:

 (set (if boundp 'dired-omit-mode 'dired-omit-mode 'dired-omit-toggle) t) 

Yes, it's a little painful, but not as dramatic as you do. I support .emacs , which has been working with anything since 19.23 (IIRC, it's been a while since I tested with something older than 19.34) on all DOS, Windows and unix. Windows compatibility is actually more of a burden than changing GNU Emacs versions.

As for the cookbook, most of the differences between the versions are related to features that are not very widely used (otherwise developers would attach greater importance to a strict increase in compatibility). Since Emacs is large, there is undoubtedly a lot of it that you use, but the cookbook writer has not heard. You will have to play by ear. Fortunately, this is not too complicated.

Answer 2

Since it is impossible to predict future changes of anything, no one can guarantee compatibility in the future.

I think the following points are some of the many common ways to make it easier to support .emacs or init.el (which I am currently practicing.)

• install .emacs.d / version control (MUST one)
• split the initialization file into several small files.

• use when to load specific settings for the emacs version.

  eg:

  (when (= emacs-major-version 24)
  ;; load my settings for 24
  )

Answer 3

I sympathize, and I share your pain. The answer is no, there is no such holy grail, I am afraid. As you said, if your initialization file is simple enough, you may not need to change anything. In fact, even this is not the case: the name of the initialization file and where Emacs looks for it have changed over time.