Hi Eshel, I just want to start off once again by saying thank you for the thoughtful review, help, testing, and encouragement. I'll start by responding to the previous email and then go on to explain the two attached patches. --- Eshel Yaron writes: > Right. And when considering sexps, forward-sexp-function can come into > play, which might take into account all sorts of buffer-local variables. Yeah.. I can imagine this become a frustrating game of whack-a-mole. > I think that might be the way to go, actually. Placing the after-string > insertion and subsequent deletion in an atomic change group (and using > undo-amalgamate-change-group to let the user undo everything in one go) > should hopefully work just as well, and that would alleviate the need to > chase down and replicate complex buffer state in the temporary buffer. I took a stab at implementing this. I didn't fiddle with `undo-amalgamate-change-group` but it seems like it wasn't required to get what felt like sensible behavior. > I think that'd be best, yes. Let's keep completion-preview-insert > intact for the time being and see if we there's room for cleanly > consolidating it with the new commands after we get them right. That sounds great no need to make things too complicated. > I'll give it a try, thanks. Thank you > In the future if you could squash all changes to a single patch I > think that'd make it easiest to review. That sounds great. I'll keep that in mind when presenting the next changesets. --- Okay now onto the latest patches. Both patches have reverted the changes to `completion-preview-insert` and both patches pass the same set of unit tests. The first patch `completion-preview-partial-insertion-with-temp-buffer.patch` is the same as the previous patch but with two critical changes: the revert, and the addition of a new variable `completion-preview-context-variables` which can be used to customize the list of variables to copy into the temporary buffer. The second patch `completion-preview-partial-insertion-with-region-delete.patch` is the version of the change that uses in-buffer deletion. There's not much to say here, it seems quite a bit more robust. I reckon the second patch is more in line with what you had in mind but I wanted to bring the first approach to a more acceptable state.