Re: Calling Lisp from undo.c's record_* functions

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

>> The problem is not in undo.c but in the fact that insdel.c calls
>> record_insert at a moment where Elisp code can't be run.  So the call to
>> record_insert would need to be moved.
> Even if run_undoable_change doesn't call Lisp, but instead conses the
> list by calling Fcons directly?

My answers were assuming that we want a solution that keeps using Elisp
for run_undoable_change.

> That's what Phillip did on his branch.

Yes, I saw that branch, but that's a separate thread.

>> But of course, in reality it's not the whole record_insert that needs to
>> be moved, only the run_undoable_change within it.
>> So if it's difficult to move record_insert to safe spot, maybe we should
>> take run_undoable_change out of it.
>> E.g. maybe we could call run_undoable_change from
>> prepare_to_modify_buffer instead.
> Beware: prepare_to_modify_buffer is not always called.

When would it not be called?  You mean there are cases where we'd add
stuff to the undo list but we don't run before-change-functions?
Wouldn't that be a bug?

> Why call this at such a low level?

To me, prepare_to_modify_buffer is actually higher-level than record_insert.

> Why not at the level of general_insert_function, Fdelete_region, etc.?
> (Yes, that would be more places to change, but so what?)

Yes, we could push it to an even higher level, but if
prepare_to_modify_buffer works, it's preferable, I think.

In any case, these are just suggestions, I don't have strong opinions on
these issues now ;-)


        Stefan