Yes, I did consider redefining the functions in my package, but monkey patching emacs internal api's can't be good for maintenance. Because ielm supports this behavior, the change would bring buffer-based development to parity with ielm, making emacs itself more consistent. On Wed, Aug 18, 2021 at 1:30 AM Eduardo Ochs wrote: > Have you considered the possibility of implementing a _variant_ of > eval-last-sexp that does what you want? That's what I do in eev... take a > look at the section "0. How to use this" of this tutorial: > http://angg.twu.net/eev-intros/find-lexical-intro.html > > Cheers, > Eduardo Ochs > http://angg.twu.net/#eev > > > > On Tue, 17 Aug 2021, 13:41 Psionic K, wrote: > >> Proposing to patch the eslip module so that if a buffer-local >> `elisp-eval-target` has been set, `eval-last-sexp` and similar commands >> will execute lisp in the context of another buffer. >> >> The use case is when developing elisp to operate on non-elisp buffers, >> interacting with functionality for other languages such as when using LSP. >> >> This change would bring buffer-based development in line with ielm's >> `ielm-change-working-buffer` behavior. >> >> While the `eval-last-sexp` commands are very ergonomic, there is no way >> to direct them at another buffer without wrapping the last sexp in >> `with-current-buffer`. Advising deep into `eval-last-sexp` is difficult >> because we must call `set-buffer` after computing the elisp we want to >> evaluate. >> >> With this support available, the users can then update the buffer local >> in shortcut commands for buffer-based development of elisp for other modes. >> >> I intend to develop a patch. The main difficulty I can identify so far >> is setting the buffer at the correct points so that the setup for >> evaluation continues to occur in the correct context. >> >> -- >> Psionic K >> Software Engineer >> >> *Positron Solutions * >> > -- Psionic K Software Engineer *Positron Solutions *