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)