Re: Why on earth is abbrev baked into the C code?

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I was looking into abbrev.el to figure out how to code up a change I
> wanted to make (having undo undo the abbrev expansion without undoing
> the self-insert-command that triggered the expansion),

You should be able to use abbrev-expand-functions for that (it's
a wrapper hook, so it has complete control over the expansion, like an
`around' advice).

> when I realized
> to my surprise that abbrev is actually baked into the Emacs C core. 

Until Emacs-22, the abbrev code was even all coded in C.

> This defies common sense: why can't abbrev.el be a standalone module
> that uses post-self-insert-hook or post-command-hook?

E.g. because post-self-insert-hook is brand new and post-command-hook
is inappropriate?

BTW, I haven't moved it to post-self-insert-hook because it is hooked
a bit more intimately into self-insert-command (e.g. the successful
expansion of an abbrev can prevent the char from being inserted and the
post-self-insert-hook from being run), so it is difficult to move it to
post-self-insert-hook without changing some of the subtle points of its
semantic.

> I realize we're not supposed to use hooks to communicate between
> components that are part of GNU Emacs, but the alternative in this
> case seems unnecessarily invasive.

Actually post-self-insert-hook is not nil by default, so this convention
is already broken for this hook.

> (By the way: the comment in front of self-insert-command is no longer
> valid; ISTR that dubious optimization was removed a while ago.)

Indeed, thanks.  Please install the patch,


        Stefan