[emacs-berlin] org-babel evaluate elisp for “window changing” functions

[Gary Phillips]

The code referenced on Stackoverflow.com seems to work perfectly for my use
case.
If you have time to read the code you will probably learn a lot about emacs
lisp - I certainly did!

My explanation in email yesterday was slightly misleading.
org-babel-execute-source-block always runs save-excursion and then hands
over to a language-specific handler, in this case org-babel-execute:emacs-lisp,
which runs save-window-excursion. It's the emacs-lisp handler that causes
the problem we saw.

save-excursion saves the identity of the current buffer and its value of
point (the cursor position) but ignores the window layout.
save-window-excursion saves the current window layout.

In my use-case of running ediff-files I rely on ediff-files itself to save
the window configuration including my org-mode buffer which is then
restored when I quit the ediff session.

On Thu, 27 Jun 2019, 02:32 Gary Phillips, <gary.phillips at rolmo.com> wrote:

> Thanks everyone for a great Emacs night which I found very inspiring.
>
> Tonight we looked at a problem I had hit with running Emacs Lisp code
> “interactively” inside an org-mode buffer.
>
> This is the best solution I’ve found so far (not yet tried for my example
> but it looks good).
>
> https://emacs.stackexchange.com/questions/42096/running-elisp-within-an-orgmode-code-block?rq=1
>
> We evaluate the following code block and only see the buffer name which
> ediff-files creates and not the interactive ediff session we expect.
>  #+begin_src elisp
> (ediff-files “foo.s” “bar.s”)
>  #+end_src
>
> Causing the problem is the Emacs macro ’save-excursion’ which saves and
> restores all window settings after executing the code given as its
> parameter.
> ’save-excursion’  is used by org-babel whenever it evaluates code.
> In the case of ediff-files, all the correct buffers and windows are
> created but when the setup is finished it returns to save-excursion and
> everything is put back as before. [I’ve omitted stuff about the Emacs event
> loop which may or may not be recursive.]
>
> Lisp macros are executed and expanded at compile-time and so we can’t just
> replace save-excursion with a new temporary function of the same name.
>
> The solution shown on stackexchange is quite complicated because it must
> rewrite the ’save-excursion’ macro inside  ‘org-babel-execute:emacs-lisp’.
> There may be a better solution if we can modify the source code of
> ‘org-babel-execute:emacs-lisp’.
>
> Cheers
> Gary
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailb.org/pipermail/emacs-berlin/attachments/20190627/dfdd506f/attachment.html>