Re: How to reliably edit a file from within Emacs Lisp and return a string?

[Eli Zaretskii <eliz@gnu.org>]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Thu, 22 Aug 2019 19:22:34 -0400
> Cc: GNU Emacs Help <help-gnu-emacs@gnu.org>
> 
> > Yes. I need to be able to run function that waits on the buffer to be
> > killed, so that I can read string from the file that related to the
> > buffer.
> 
> The difficulty is the waiting part.

I think the difficulty is the very concept of "waiting".  It probably
comes from the previous implementation, where Emacs was invoked as an
external program, and then the caller would "wait" for it to exit, and
take that as a signal that editing is complete.

This paradigm is problematic when everything is done from within
Emacs, because once editing is done, Emacs just returns to its main
command loop and waits for the next command.  IOW, it's Emacs that
"waits" here, not the command which invoked the editing part.

One way to keep the "waiting" paradigm is to use recursive-edit (which
I still don't understand why the OP dislikes: the problems with "C-c
C-c" are minor and can be easily resolved).  If that is somehow not
appropriate, then my question would be "what would the 'waiting' part
do once the wait is over?"  Given the answer to that, it shouldn't be
hard to devise the solution that doesn't "wait", but instead causes
something to happen after editing is complete.  Just as an example, if
after editing the application should refresh some buffer, then
triggering that buffer's revert function would be all that's needed.

My main point is that doing this from Emacs needs a certain conceptual
shift, because the command loop and the resulting "wait" are now
implicit.

> It might be possible to use threads for waiting and get more linear
> code that way

Not recommended.