[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why on earth is abbrev baked into the C code?
From: |
Stefan Monnier |
Subject: |
Re: Why on earth is abbrev baked into the C code? |
Date: |
Sun, 27 Feb 2011 22:18:56 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
> 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