Why on earth is abbrev baked into the C code?

Why on earth is abbrev baked into the C code?

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

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), when I realized
to my surprise that abbrev is actually baked into the Emacs C core. 
This defies common sense: why can't abbrev.el be a standalone module
that uses post-self-insert-hook or post-command-hook?  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.

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

=== modified file 'src/cmds.c'
--- src/cmds.c    2011-01-26 08:36:39 +0000
+++ src/cmds.c    2011-02-27 03:02:04 +0000
@@ -263,8 +263,6 @@
 
 static int nonundocount;
 
-/* Note that there's code in command_loop_1 which typically avoids
-   calling this.  */
 DEFUN ("self-insert-command", Fself_insert_command,
Sself_insert_command, 1, 1, "p",
        doc: /* Insert the character you type.
 Whichever character you type to run this command is inserted.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

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

[Stefan Monnier]

> 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

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

[Daniel Colascione]

;; This hack works for me, but there must be an easier, safer way.

(defun qtmstr-expand-abbrev-wrapper (orig-func &rest args)
  (if (and qtmstr-abbrev-mode
           (eq this-command 'self-insert-command)
           (not executing-kbd-macro)
           (not noninteractive)
           (not (window-minibuffer-p (selected-window)))
           (characterp last-command-event))

      ;; Our own implementation of expand-abbrev
      (destructuring-bind (&optional sym name wordstart wordend)
          (abbrev--before-point)

        (when sym
          (let ((value sym))
            ;; Now sym is the abbrev symbol.
            (setq last-abbrev-text name)
            (setq last-abbrev sym)
            (setq last-abbrev-location wordstart)

            ;; Do what the self-insert-command would normally do
            (insert-char last-command-event 1 t)
            (undo-boundary)
            (delete-char -1)

            ;; If this abbrev has an expansion, delete the abbrev
            ;; and insert the expansion.
            (abbrev-insert sym name wordstart wordend))))

    ;; Otherwise, let the original expand-abbrev do its thing
    (apply orig-func args)))

(add-hook 'abbrev-expand-functions #'qtmstr-expand-abbrev-wrapper)

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

[Richard Stallman]

    Why on earth is abbrev baked into the C code?

For speed: I did not want SPC to run Lisp code in the usual case.
Maybe nowadays it would be acceptably fast.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org, www.gnu.org

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

[Stefan Monnier]

> ;; This hack works for me, but there must be an easier, safer way.

Haven't tried it, but saving buffer-undo-list before calling `orig-func'
and checking the result afterwards (adding an undo-boundary at the
saved location of buffer-undo-list when needed), might be "easier,
safer".


        Stefan