Re: [Emacs-diffs] fix/no-undo-boundary-on-secondary-buffer-change f59d1be: Move undo amalgamation to lisp.

[Phillip Lord]

Stefan Monnier <address@hidden> writes:

>> +(defun undo-auto-pre-command-hook()
>> +  (when (and (eq last-command 'self-insert-command)
>> +             (eq this-command 'self-insert-command))
>
> I think this code should be called from self-insert-command rather than
> from pre-command-hook.


On a hook? Or do I just directly call a function defined in lisp form C?

Does the same argument apply to the post-command-hook and
after-change-functions also? I've been trying to use already existing
functionality where possible (as it stands, I've only reduced code in
the C layer -- the one thing I have added -- undo-size -- isn't used
anymore, and I may back out before I've finished).

> And it should also be called from delete-char.

Yes, next on my list. Wanted to do one thing first and check that it
didn't crash first.


>> +    ;; As last-command was s-i-c, there should be "insert" cons just
>> +    ;; before this. We need to check that there have not been too many 
>> insertions
>> +    (let ((last-before-nil
>> +           (cadr buffer-undo-list)))
>> +      (when
>> +          (> 20
>> +             (- (cdr last-before-nil)
>> +                (car last-before-nil)))
>
> We don't actually know that (cdr last-before-nil) and (car
> last-before-nil) are numbers.  The previous self-insert-command might
> have performed all kinds of buffer modifications (via abbrev-expansion,
> post-self-insert-hook, ...).

Hmmm. That's unfortunate -- I was trying to avoid "global" state and
just user buffer state; the undo-list seemed like a sensible place to
get this knowledge from.

Other ideas? A buffer-local "undo-auto-self-insert-counter" perhaps? Or
I could just use the logic above when it works and do nothing when it
doesn't which would be safe, but means a post-self-insert-hook might
break the blocks-of-20 amalgamation.

Phil