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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 14:41:20 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: GNU Emacs Help <help-gnu-emacs@gnu.org>
> 
> * Eli Zaretskii <eliz@gnu.org> [2019-08-24 14:31]:
> > That can be done easily, but I cannot resist asking: why do you need
> > the intermediate temporary file?  Why not insert the string into a
> > buffer, let the user edit that string in a buffer, and then have a
> > command in that buffer that tells you the user is done editing?
> 
> That is exactly what I am doing now. And I am losing editing.
> 
> What I am doing now is using M-C-c to finish recursive-edit. But
> problem is that I use other functions of Emacs which are disturbing
> it.

What do you mean by "disturbing"?  If the problem is that you are
using recursive-edit, and you exit recursive-edit with C-M-c, then I
specifically did NOT suggest to use recursive-edit.  You shouldn't
need it, AFAIU.  You need a simple editing of a buffer, that's all.

If the problem is that you are afraid C-M-c could have a different
command bound to it under some circumstances, then bind your "done
editing" command to something else, like C-M-F10 or something, a key
sequence that is unlikely to be ever taken by some Emacs feature.  Let
that key sequence tell you the buffer is ready to be fed back.

> If I am ONLY editing words from mind, that would be fine, but I use
> Emacs to switch to other buffers, maybe open mutt, maybe launch new
> emacsclient from outside, to open other file, to copy staff from other
> file to such buffer.

That's fine.  After you are done with all those other buffers, just
switch back to your editing buffer and continue.  Why is that a
problem?  What am I missing here?

> Observation and reality is that my recursive-edit will simply
> break. It does not last.

Then don't use recursive-edit.  You don't need it.

> I am just invoking from Emacs Lisp to read the database, to read the
> field from database, and then I am editing that field as a string and
> feeding it back.

"Feed it back" how? by using Emacs primitives to write to a file? or
by invoking some external program to do that?

> When I am editing Org file or Markdown from database, it is complex,
> requires using other windows, other buffers, and also using
> emacsclient to open other files for references.

So how about the following high-level design:

  . you get the material from the data base into a buffer
  . depending on the contents, you turn on the appropriate major mode
    in that buffer, be it Org or Markdown or whatever
  . you then let the user edit the buffer
  . when the user is done editing, let the user type some special key
    sequence, say C-M-F10, and then feed the edited buffer back to the
    database

Would that work?  Note that there's no recursive-edit anywhere in
sight on what I described, it's normal editing on level zero.

> Eli, do you think I could do that somehow by installing some kind of
> timer or async function or something that works in background, which
> is checking if the buffer created with find-file is still there?
> 
> Then I could read the string from well known file back into the
> database.

You could, but I don't see how this is going to solve your problem any
better than installing a kill-buffer-hook.  After all, if you are
afraid that the user might kill the buffer when they shouldn't, then
your reliability issue is not solved by using the kill-buffer as a
trigger for feeding the stuff back to the database?

And why do you need to watch the buffer killed, anyway?  If you are
afraid the user will erroneously kill it before finishing the editing,
then there are means to prevent such accidental killing of a buffer.

So I don't think I understand what problem you are trying to solve by
using a timer.  If I did understand correctly what you are trying to
accomplish, you can have that without all that complexity, without
even the temporary file.  Am I missing something?