Recent Emacs breakage

Avoid splash screens

When emacs is started, a splash screen is displayed and one has to hit Control-L before one can start editing. Of course nobody is interested in such a delay. There is a command-line option --no-splash but probably more useful is the .emacs line
;; prevent silly initial splash screen
(setq inhibit-splash-screen t)

There is a long, long thread at emacs.devel where one learns that RMS thinks that one should start emacs only once per login session, while David Kastrup thinks otherwise. That this nag screen has been there for a long time, but only now starts causing complaints because earlier it would be shown only when emacs was invoked without parameters while emacs22, when called with a filename, refuses to do what the user tells it but first shows RMS's advertisement. Every user who has the habit of invoking emacs with a filename now wastes some time figuring out how to shut up this welcome screen and then all is well again.

Select a proper font

I find that if I start emacs, my Hebrew is by default displayed as empty rectangles. Earlier all was well. In particular that means that all the required fonts are present, but that emacs decides to use a font without Hebrew support. The line below fixes this for me.
;; needed to get Hebrew - by default some font without Hebrew glyphs is used
(if (equal window-system 'x)
    (set-face-font 'default "fontset-standard"))

For more information about fontsets, see emacswiki.

Indentation of C code

Recent cc-mode does not handle nested flow-of-control constructs on a single line. Earlier one would get
	for (x=x0; x<x1; x++) for (y=y0; y<y1; y++) for (z=z0; z<z1; z++)
		do_something(a[x][y], b[x][y], c[z], x, y, z);
but now (with emacs-version: 22.1.1, c-version: 5.31.4) one gets
	for (x=x0; x<x1; x++) for (y=y0; y<y1; y++) for (z=z0; z<z1; z++)
							    do_something(a[x][y], b[x][y], c[z], x, y, z);
Similarly, when a block follows, one would get
	for (x=x0; x<x1; x++) for (y=y0; y<y1; y++) for (z=z0; z<z1; z++) {
		do_something(a[x][y], b[x][y], c[z], x, y, z);
		do_something_else(a[x][y]-b[x][y], x+y+z);
	}
but nowadays this gives the peculiar
	for (x=x0; x<x1; x++) for (y=y0; y<y1; y++) for (z=z0; z<z1; z++) {
				do_something(a[x][y], b[x][y], c[z], x, y, z);
				do_something_else(a[x][y]-b[x][y], x+y+z);
			}
An easy solution is to downgrade to cc-mode 5.28. (No other fix is known. The maintainer suggested a workaround that improves the first but not the second example.)

See also cc-mode at sourceforge and emacswiki.

Ancient Emacs breakage

Emacs likes to be context-sensitive. If the context in which emacs behaves differently is encountered infrequently then the behavior can come as a surprise and cause bugs or inconvenience. (I recall with displeasure that emacs changes behavior when editing a file somewhere below the /tmp directory: no backup is made.) There is one case of context-sensitivity that is frequently encountered and still is annoying.

Transpose characters

I like a transpose-characters function with two properties: (i) it is not context-sensitive, but always does the same, and (ii) it squares to the identity - if I hit Control-T twice the original situation is restored. Unfortunately, the default emacs function has neither property. At the end of a line it transposes the two characters before the point, but when not at the end of a line it transposes the characters before and after the point and moves one position forward. Since there may be blanks at the end of a line, one cannot infer from the screen image what the GNU emacs transpose-chars will do. Goslings emacs did this right. Here a version that always transposes the two characters before point.
(global-set-key "\^T" 'gosmacs-transpose-chars)
(defun gosmacs-transpose-chars ()
 "transpose chars before dot"
 (interactive)
 (forward-char -1)
 (transpose-chars 1))

Next line

The key Control-N runs by default the command next-line. Also here a bad design mistake. Keys used for cursor movement should not modify a file, but next-line used to have the context-sensitive effect of moving the cursor one line down, and, if there is no further line, to insert a newline character into the buffer. Yecch. Today (since Emacs 19) there is a variable that stops the old unfortunate behavior, and most installations make this the default.
;; do not modify the data when asked to move the cursor
(setq next-line-add-newlines nil)

Undesired modes

Nobody likes the CapsLock key on a keyboard. It does only harm. In a similar way, but worse, the Overwrite mode in emacs only does harm. Nobody wants to kill his text overwriting it with something else. So, it should be difficult to get into Overwrite mode, but by default that is easy: just hit the Backspace or Delete key inaccurately so that Insert is touched.

There are other obscure commands that one never wants and that therefore are protected behind a "disabled" flag. By default the Insert key invokes the command overwrite-mode, and one can add this mode to the collection of disabled commands by

;; no overwrite mode
(put 'overwrite-mode 'disabled t)
On the other hand, for all these disabled commands I do not want to get a dialog that I have to reply to, I want to get a beep and have the keystroke ignored. So:
;; beep and ignore disabled commands
(setq disabled-command-hook 'beep)