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

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

[Jean Louis]

I need to reliably edit the file from within Emacs Lisp, and then
return the string by reading the file. And I have difficulties in
doing so.

Purpose of it is to read database field values, and feed them back
into the database. I have been doing that for years, reliably, because
I was calling Emacs from outside of Emacs. For example, common lisp
would wait for the Emacs to finish editing and then it would read the
file as a string.

Since I have switched to editing within Emacs, I am forced so far to
use various tricks like (recursive-edit) and similar. I am forced to
quit editing with C-c C-c or C-M-c which is all not reliable, as if
mode chances, maybe C-c C-c changes, killing the buffer is also not
conclusive for Emacs Lisp, basically from within Emacs Lisp, how can I
know that find-file has finished its job, that buffer has been closed,
so that I can read the string?

Function like this one below is just an alternative, but it is simply
not reliable, as too many things can happen with the buffer, and I
better rely on temporary files, and not temporary buffers for database
field value editing.

(defun read-from-buffer (value &optional buffer-name)
  "Edits string and returns it"
  (let ((this-buffer (buffer-name))
	(new-value value)
	(buffy (if buffer-name buffer-name "*edit-string*")))
    (save-excursion
      (switch-to-buffer buffy)
      (set-buffer buffy)
      (text-mode)
      (setq header-line-format "➜ Finish editing with C-c C-c or C-M-c")
      (local-set-key (kbd "C-c C-c") 'exit-recursive-edit)
      (if (stringp value) (insert value))
      (speak "You may quit the buffer with Control C Control C")
      (message "When you're done editing press C-c C-c or C-M-c to continue.")
      (unwind-protect
	  (recursive-edit)
	(if (get-buffer-window buffy)
	    (progn
	      (setq new-value (buffer-substring (point-min) (point-max)))
	      (kill-buffer buffy))))
      (switch-to-buffer this-buffer)
      new-value)))

The function like this one below is simply not perfect. The `a` will
be set on the end only if I press C-M-c, while C-c C-c will mostly
be changed as keybinding if I change the mode, like changing to Org
mode, the C-c C-c is also changing.

(defun edit-temp-file (file)
  "Edits temporary file and returns it as string"
  (let ((created (create-file-buffer file))
	(buffer (get-file-buffer file)))
  (progn
    (switch-to-buffer created)
    (set-visited-file-name file)
    (if (file-exists-p file)
	(insert (file-to-string file)))
    (message "Hit C-M-c when done") 
    ;; (add-hook 'kill-buffer-hook 'exit-recursive-edit 0 t) ;; just thinking
    ;; (local-set-key (kbd "C-x k") 'exit-recursive-edit)    ;; just thinking
    ;; (set-register 77 (recursive-edit))                    ;; just thinking 
    (recursive-edit)
    ;; (speak "Finished editing")) ;; This way I can know what happened
  (kill-buffer buffer)
  (file-to-string file)))

(defun file-to-string (file)
  "File to string function"
  (with-temp-buffer
    (insert-file-contents file)
    (buffer-string)))

(setq a (edit-temp-file "New1234.md"))

What I really need is following:

- to be able to provide file name to Emacs Lisp function

- for Emacs Lisp to have it know with guarantee that buffer has been
  killed, if saved or not saved, is left to editing choice,

- for Emacs Lisp to read the string after buffer has been killed

To repeat again, to do that is extremely easy from outside programming
language. I supply the file, edit it with emacs, and once finished, I
read the file into string.

My concept is of course following:

(defun edit-temp-file (file)
  (find-file file)
  (file-to-string file))

But of course I am not getting the result. If anybody knows the solution, let me know.

Jean

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

[Noam Postavsky]

On Thu, 22 Aug 2019 at 17:31, Jean Louis <bugs@gnu.support> wrote:
> killing the buffer is also not
> conclusive for Emacs Lisp,

Why do you say that?

> basically from within Emacs Lisp, how can I
> know that find-file has finished its job, that buffer has been closed,
> so that I can read the string?

find-file finishes as soon as the buffer is opened. It sounds like you
want to know when the user is finished with the file; the user has to
tell you somehow (e.g., by killing the buffer).

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

[Jean Louis]

* Noam Postavsky <npostavs@gmail.com> [2019-08-23 00:03]:
> On Thu, 22 Aug 2019 at 17:31, Jean Louis <bugs@gnu.support> wrote:
> > killing the buffer is also not
> > conclusive for Emacs Lisp,
> 
> Why do you say that?

I cannot conclusively know and I do not know how to know it, from
within Emacs Lisp, that a buffer has been killed. Function `find-file'
finishes as soon as file is opened, just as you said.

> > basically from within Emacs Lisp, how can I know that find-file
> > has finished its job, that buffer has been closed, so that I can
> > read the string?
> 
> find-file finishes as soon as the buffer is opened. It sounds like
> you want to know when the user is finished with the file; the user
> has to tell you somehow (e.g., by killing the buffer).

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.

Do you know how to do it?

Jean

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

[Óscar Fuentes]

Jean Louis <bugs@gnu.support> writes:

> I cannot conclusively know and I do not know how to know it, from
> within Emacs Lisp, that a buffer has been killed. Function `find-file'
> finishes as soon as file is opened, just as you said.

C-h v kill-buffer-hook

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

[Noam Postavsky]

On Thu, 22 Aug 2019 at 18:46, Jean Louis <bugs@gnu.support> wrote:

> I cannot conclusively know and I do not know how to know it, from
> within Emacs Lisp, that a buffer has been killed.

Adding a function to kill-buffer-hook should work fine for that. But...

> 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. Traditionally, you would stuff the
rest of your code into a lambda callback, which means you can't have a
function like edit-and-return, because the flow needs to inverted. You
can have edit-and-do-with-resulting-string:

;;; -*- lexical-binding: t -*-
(defun call-with-edited-value (value function &optional buffer-name)
  "Edit VALUE and then call FUNCTION on it."
  (with-current-buffer (pop-to-buffer-same-window
                        (or buffer-name "*edit-string*"))
    (add-hook 'kill-buffer-hook
              (lambda () (funcall function (buffer-string))))
    (text-mode)
    (insert value)
    (setq header-line-format
          (substitute-command-keys
           "➜ Finish editing with \\[kill-buffer]"))
    (message "When you're done editing press %s to continue."
             (substitute-command-keys "\\[kill-buffer]"))))

;; Example call:
(call-with-edited-value
 "initial value"
 (lambda (v)
   (message "The value is now %S" v)))

It might be possible to use threads for waiting and get more linear
code that way, though there are still some rough spots around user
interaction from non-main threads, so it may also be somewhat tricky.

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

[Jean Louis]

* Noam Postavsky <npostavs@gmail.com> [2019-08-23 01:23]:
> On Thu, 22 Aug 2019 at 18:46, Jean Louis <bugs@gnu.support> wrote:
> 
> > I cannot conclusively know and I do not know how to know it, from
> > within Emacs Lisp, that a buffer has been killed.
> 
> Adding a function to kill-buffer-hook should work fine for
> that. But...

I have tried, and could not. Do you have example?

Jean

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

[Noam Postavsky]

On Thu, 22 Aug 2019 at 21:19, Jean Louis <bugs@gnu.support> wrote:

> > Adding a function to kill-buffer-hook should work fine for
> > that. But...
>
> I have tried, and could not. Do you have example?

Yes, it's in the remainder of my previous message (I should have said
"But see below", instead of just "But...").

https://lists.gnu.org/archive/html/help-gnu-emacs/2019-08/msg00055.html

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

[Eli Zaretskii]

> 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.

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-23 09:53]:
> > 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.

The problem in using M-C-c is the habit and Emacs nature.

Habit:
======
Editing 200 files in one days and closing those files with C-x k,
saving them in that process is hard to break to even remember to do
the M-C-c to quit editing from recursive buffer.

Recursive editing for database fields, without file written on the
disk is somehow risky. Something can happen in Emacs, and it does
happen, and the waiting for recursive edit is "out" or finished before
I would like it to finish. I am using various functions, helm,
inserting links, etc. it all disturbs such waiting. That is Emacs
nature, it has many other things running around.

I would be happy if I can do something like:

(defun emacsclient-edit (file)
  (shell-command (format "emacsclient %s " file))
  (file-to-string file))

But that does not work within Emacs itself. Would that work, I would be fine.

It is somehow strange that I can run emacsclient from outside
Emacs and edit file and know that emacsclient finished its job,
and read the string from file, and that I cannot do the same from
Emacs.

Other solution is to spawn another Emacs editor, but that would
not appear integrated within one Emacs.

Is there really no solution that one can do so from within Emacs
reliable? I could use recursive-edit, if it will give me
certainty that from Emacs Lisp I can know when buffer have been
killed to read the string.

Anything, any solution is fine, but I would not like to rely on
C-M-c, rather on killing of the buffer to which the file is
related.

Jean

P.S. For example, I am spawning this text in emacsclient from
mutt. Mutt is waiting until I kill this buffer. Then I go back to
vterm or ansi-term and I can send email from mutt. This works. It is
totally not logical that I cannot do the same from within Emacs.

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

[Robert Pluim]

>>>>> On Fri, 23 Aug 2019 16:01:45 +0200, Jean Louis <bugs@gnu.support> said:
    Jean> I would be happy if I can do something like:

    Jean> (defun emacsclient-edit (file)
    Jean>   (shell-command (format "emacsclient %s " file))
    Jean>   (file-to-string file))

    Jean> But that does not work within Emacs itself. Would that work, I would be fine.

    Jean> It is somehow strange that I can run emacsclient from outside
    Jean> Emacs and edit file and know that emacsclient finished its job,
    Jean> and read the string from file, and that I cannot do the same from
    Jean> Emacs.

Iʼd investigate the 'with-editor' package, which lets you use
emacsclient to talk back to the emacs itʼs run from.

Robert

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

[Eli Zaretskii]

> Date: Fri, 23 Aug 2019 16:01:45 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> The problem in using M-C-c is the habit and Emacs nature.

I see your point, although I don't share your conclusions.  But it's
pointless to argue about that, because it's your code, and all I want
to do is help you get it right according to your preferences.

> I would be happy if I can do something like:
> 
> (defun emacsclient-edit (file)
>   (shell-command (format "emacsclient %s " file))
>   (file-to-string file))
> 
> But that does not work within Emacs itself. Would that work, I would be fine.

See, that's exactly the paradigm I suggest to unlearn when you
implement features, such as the one you described, entirely in Emacs.
What you need instead is to trigger something (which I don't yet think
I understand) once editing is complete.  Can you describe in more
detail what should your feature do after the user is done with editing
the file?

> It is somehow strange that I can run emacsclient from outside
> Emacs and edit file and know that emacsclient finished its job,
> and read the string from file, and that I cannot do the same from
> Emacs.

That's because Emacs is a single-threaded program, so while its single
thread waits for emacsclient, no other code in Emacs can run and serve
the emacsclient request.  Emacs is stuck waiting, period.

> Other solution is to spawn another Emacs editor, but that would
> not appear integrated within one Emacs.

That's an awful design, IMO, even though there's a very smart and
sophisticated package out there that supports exactly that.

> Is there really no solution that one can do so from within Emacs
> reliable?

I'm sure there is, but at least for me the details of the problem that
you face are not yet sufficiently clear to give a concrete advice.

> P.S. For example, I am spawning this text in emacsclient from
> mutt. Mutt is waiting until I kill this buffer. Then I go back to
> vterm or ansi-term and I can send email from mutt. This works. It is
> totally not logical that I cannot do the same from within Emacs.

It's very logical, because in the latter case it's the same program
that "waits" and should serve the editing job.  emacsclient works by
sending a request to Emacs to edit the file, and Emacs cannot serve
that request while it's waiting for emacsclient, because it's busy
waiting.

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

[Marcin Borkowski]

On 2019-08-23, at 16:01, Jean Louis <bugs@gnu.support> wrote:

> Anything, any solution is fine, but I would not like to rely on
> C-M-c, rather on killing of the buffer to which the file is
> related.

I have not followed this thread very closely, so maybe I'm
misunderstanding something.  Nevertheless, here are my 2 cents.

Cent number 1 is: I had a similar problem.  I wanted to be able to edit
something in Emacs and I wanted Emacs to do something when I finish it.
So, I created a dedicated minor mode, with C-c C-c bound to
a "finishing" function.  (I'm 99% sure I haven't blogged about it.
Should I?)

Cent number 2 is: why don't you just do the same, and rebind C-x k in
your minor mode to do something useful?  It's not bullet-proof, of
course, since you might kill the buffer in some other way, but if your
habit is one part of the problem - that should help, no?  I would even
go as far as making C-x k play the "sad trombone" sound and tell you
(possibly with dancing elephants™) that you should use C-c C-c instead
(which is a customary way of telling Emacs "I'm done with whatever I've
been doing in this buffer" - it works this way in WDired, message-mode,
Magit and many other places)?  Of course, you should then bind C-c C-c
in *your* minor mode to *your* finishing ("commit") function.

This way, instead of fixing Emacs, you would fix yourself instead - but
still, the problem would be fixed.

Bonus cent (related to emacs client/server): I have this in my init.el:

--8<---------------cut here---------------start------------->8---
(require 'server)
(if (server-running-p)
    (load-theme 'green-phosphor t)
  (setq confirm-kill-emacs #'yes-or-no-p)
  (server-start)
  (global-set-key (kbd "C-x C-3") 'server-edit))
--8<---------------cut here---------------end--------------->8---

What this does is:
- it starts the server by default,
- if makes every other Emacs instance _not_ start the server (this
wouldn't work anyway), and make it stand out using a very distnictive
theme (so that I do not accidentally spawn another Emacs session, forget
about it and try to use it for my normal tasks),
- make exiting from my main session hard and leave exiting from other
ones easy,
- and fix the terrible C-x # binding (which requires using the control
key first and shift next).

(I blogged about this setup here:
http://mbork.pl/2019-01-06_Emacs_server_and_other_Emacs_instances).

Hth,

--
Marcin Borkowski
http://mbork.pl

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-23 09:53]:
> > 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.
> 
> One way to keep the "waiting" paradigm is to use recursive-edit

Let me just say, that I am already using recursive-edit and use M-C-c
to exit.

But the problem is there that relates to reliability that I do not
know how to solve.

As if I am in recursive-edit in one window, then I wish maybe to open
up other window, for exampel ansi-term and mutt inside, and in that
window I am opening emacsclint too. In this moment my recursive-edit
from first window is broken, or dissapers, I cannot get to it.

Maybe it is a bug. Is it? It should not be so logically.

If I would have recursive-edit very reliable I would use it.

Jean

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-23 16:28]:
> See, that's exactly the paradigm I suggest to unlearn when you
> implement features, such as the one you described, entirely in
> Emacs.  What you need instead is to trigger something (which I don't
> yet think I understand) once editing is complete.  Can you describe
> in more detail what should your feature do after the user is done
> with editing the file?

Thanks for helping. I am reading string from PostgreSQL database
field. And I wish to edit that string. It is best done if string is
first written into the file, so that I can edit the file, and after
killing the buffer to read the string from file, so that it can be fed
into the database.

Question is basically how to know, from Emacs Lisp, reliably, that
process of editing of a buffer finished, so that string can be read
from file, thereafter.

I feel solution is very simple, I just don't know it.

Jean

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

[Jean Louis]

* Robert Pluim <rpluim@gmail.com> [2019-08-23 16:15]:
> >>>>> On Fri, 23 Aug 2019 16:01:45 +0200, Jean Louis <bugs@gnu.support> said:
>     Jean> I would be happy if I can do something like:
> 
>     Jean> (defun emacsclient-edit (file)
>     Jean>   (shell-command (format "emacsclient %s " file))
>     Jean>   (file-to-string file))
> 
>     Jean> But that does not work within Emacs itself. Would that work, I would be fine.
> 
>     Jean> It is somehow strange that I can run emacsclient from outside
>     Jean> Emacs and edit file and know that emacsclient finished its job,
>     Jean> and read the string from file, and that I cannot do the same from
>     Jean> Emacs.
> 
> Iʼd investigate the 'with-editor' package, which lets you use
> emacsclient to talk back to the emacs itʼs run from.

Let me inspect that.

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

[Jean Louis]

* Robert Pluim <rpluim@gmail.com> [2019-08-23 16:15]:
> >>>>> On Fri, 23 Aug 2019 16:01:45 +0200, Jean Louis <bugs@gnu.support> said:
>     Jean> I would be happy if I can do something like:
> 
>     Jean> (defun emacsclient-edit (file)
>     Jean>   (shell-command (format "emacsclient %s " file))
>     Jean>   (file-to-string file))
> 
>     Jean> But that does not work within Emacs itself. Would that work, I would be fine.
> 
>     Jean> It is somehow strange that I can run emacsclient from outside
>     Jean> Emacs and edit file and know that emacsclient finished its job,
>     Jean> and read the string from file, and that I cannot do the same from
>     Jean> Emacs.
> 
> Iʼd investigate the 'with-editor' package, which lets you use
> emacsclient to talk back to the emacs itʼs run from.

I tried it, as I understand that package is preparing the environment
$EDITOR for shell commands, so that it is ensured that editor will
communicate to current Emacs instance. For example launching external
mail reader that uses $EDITOR variable would use existing Emacs
instance with emacsclient

Jean

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 14:19:24 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: GNU Emacs Help <help-gnu-emacs@gnu.org>
> 
> Thanks for helping. I am reading string from PostgreSQL database
> field. And I wish to edit that string. It is best done if string is
> first written into the file, so that I can edit the file, and after
> killing the buffer to read the string from file, so that it can be fed
> into the database.

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?

As for feeding the string into the database: can you tell in more
detail how you are doing that?  Are you invoking some external program
passing it the edited string, for example?

> Question is basically how to know, from Emacs Lisp, reliably, that
> process of editing of a buffer finished, so that string can be read
> from file, thereafter.

The best way is for the user to tell you so.  Only the user knows for
sure, right?

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

[Jean Louis]

* 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.

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.

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

It does not last when I invoke additional emacsclient from outside.

Bufer is *edit-string* so if I am opening this email with emacsclient,
the recursive-edit in the buffer *edit-string* is not any more... The
message is "No recursive edit is in progress".

Any more complex buffer editing without file is not reliable any
more. I can even kill the buffer by thinking that the string will be
read, but it will not be read. I can click M-C-c by expected that
string will be read from buffer, but it is not as recursive-edit was
disturbed for background reasons not known to me.

> As for feeding the string into the database: can you tell in more
> detail how you are doing that?  Are you invoking some external
> program passing it the edited string, for example?

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.

Simple numbers can be edited with (read-number "Prompt: ") and some
short strings I edit from minibuffer, as those are not complex edits.

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.

By opening emacsclient during recursive-edit, such is then
interrupted.

> > Question is basically how to know, from Emacs Lisp, reliably, that
> > process of editing of a buffer finished, so that string can be
> > read from file, thereafter.
> 
> The best way is for the user to tell you so.  Only the user knows
> for sure, right?

I am the user and my staff members.

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.

That is my idea how to solve that.

Jean

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 14:31]:
> > Date: Sat, 24 Aug 2019 14:19:24 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: GNU Emacs Help <help-gnu-emacs@gnu.org>
> > 
> > Thanks for helping. I am reading string from PostgreSQL database
> > field. And I wish to edit that string. It is best done if string is
> > first written into the file, so that I can edit the file, and after
> > killing the buffer to read the string from file, so that it can be fed
> > into the database.
> 
> 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?
> 
> As for feeding the string into the database: can you tell in more
> detail how you are doing that?  Are you invoking some external
> program passing it the edited string, for example?

Do you think I could go with this approach:

- use find-file, to return the buffer reference

- install async-start to verify each in a while, like few seconds, in
  a loop, if buffer reference exists, and if not to read the file back
  as string

Jean

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?

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 15:18]:
> 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.

I am listening to your advice.

> 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?

Yes, I tried before with kill-buffer-hook and I was doing something
wrong.

With those advises, I made the below function, which does mostly what
I want.

Thank you, it is solved!

Jean

(defun edit-db-field-value (table field type id value file)
  (string-to-file-force value file)
  (let* ((buffer (create-file-buffer file)))
    (switch-to-buffer buffer)
    (set-visited-file-name file)
    (insert value)
    (add-hook 'kill-buffer-hook `(lambda ()
				  (let ((new-value (file-to-string ,file)))
				    (rcd-db-update-entry ,table ,field ,type ,id new-value)))
	      0 t)))

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

[Jean Louis]

* Jean Louis <bugs@gnu.support> [2019-08-24 16:15]:
> Thank you, it is solved!
> 
> Jean
> 
> (defun edit-db-field-value (table field type id value file)
>   (string-to-file-force value file)
>   (let* ((buffer (create-file-buffer file)))
>     (switch-to-buffer buffer)
>     (set-visited-file-name file)
>     (insert value)
>     (add-hook 'kill-buffer-hook `(lambda ()
> 				  (let ((new-value (file-to-string ,file)))
> 				    (rcd-db-update-entry ,table ,field ,type ,id new-value)))
> 	      0 t)))
> 

I was just thinking it is solved, but it does not solves anything but
that string can be read into the file.

However, that way program execution does not continue. There is no
waiting loop or something like that.

It just makes sure that one field is read back into string.

Very sad...
Jean

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 16:55:12 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > (defun edit-db-field-value (table field type id value file)
> >   (string-to-file-force value file)
> >   (let* ((buffer (create-file-buffer file)))
> >     (switch-to-buffer buffer)
> >     (set-visited-file-name file)
> >     (insert value)
> >     (add-hook 'kill-buffer-hook `(lambda ()
> > 				  (let ((new-value (file-to-string ,file)))
> > 				    (rcd-db-update-entry ,table ,field ,type ,id new-value)))
> > 	      0 t)))
> > 
> 
> I was just thinking it is solved, but it does not solves anything but
> that string can be read into the file.
> 
> However, that way program execution does not continue. There is no
> waiting loop or something like that.
> 
> It just makes sure that one field is read back into string.

So now you need to take that string and feed it back into the
database, right?  So why are you saying this is not the solution?
What else is missing?

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 17:11]:
> > Date: Sat, 24 Aug 2019 16:55:12 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > (defun edit-db-field-value (table field type id value file)
> > >   (string-to-file-force value file)
> > >   (let* ((buffer (create-file-buffer file)))
> > >     (switch-to-buffer buffer)
> > >     (set-visited-file-name file)
> > >     (insert value)
> > >     (add-hook 'kill-buffer-hook `(lambda ()
> > > 				  (let ((new-value (file-to-string ,file)))
> > > 				    (rcd-db-update-entry ,table ,field ,type ,id new-value)))
> > > 	      0 t)))
> > > 
> > 
> > I was just thinking it is solved, but it does not solves anything but
> > that string can be read into the file.
> > 
> > However, that way program execution does not continue. There is no
> > waiting loop or something like that.
> > 
> > It just makes sure that one field is read back into string.
> 
> So now you need to take that string and feed it back into the
> database, right?  So why are you saying this is not the solution?
> What else is missing?

kill-buffer-hook is a hook, it does not help me to continue program
execution.

A database table can have many fields:

page-title

page-description

page-body

Program may iterate over fields. After each editing of title, the
program moves back to the initial iteration of fields or main program
loop. After editing of title, I move back to the above list. Then I
edit description, I should be able to move back.

If hook is installed, it just ensured to read back the string into
database, but it escapes the main loop, program execution basically
and there, as nothing is holding it.

It could be solved if I could hold on find-file, and to know that
find-file finished its job, so that Emacs Lisp can continue after
find-file

Jean

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 17:51:03 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> A database table can have many fields:
> 
> page-title
> 
> page-description
> 
> page-body
> 
> Program may iterate over fields. After each editing of title, the
> program moves back to the initial iteration of fields or main program
> loop. After editing of title, I move back to the above list. Then I
> edit description, I should be able to move back.

Is the program iterating over the fields in some predefined order?

Also, are you feeding back each field individually, or do you need to
have them all edited before feeding them back as a single record?

> If hook is installed, it just ensured to read back the string into
> database, but it escapes the main loop, program execution basically
> and there, as nothing is holding it.

You are just now beginning to describe the details I asked for several
messages ago, and they do make a difference.

One possibility would be to let the user edit all the fields in the
same buffer; then killing that buffer would be your signal that
everything is ready to be fed back, and you could do that feeding in
the hook function itself.  Not sure this makes sense in the context of
your applications; I asked followup questions above to be able to
figure that out.

> It could be solved if I could hold on find-file, and to know that
> find-file finished its job, so that Emacs Lisp can continue after
> find-file

That isn't workable, since find-file finishes its job once it has the
file's contents in a buffer.  The user didn't yet edit the buffer, so
it is not yet time for you to do anything.  Your mental model seems to
be that find-file only returns when the user finishes editing and
saves the edits, but that's not how this works in reality.

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

[Yuri Khan]

On Sat, Aug 24, 2019 at 10:51 PM Jean Louis <bugs@gnu.support> wrote:

> A database table can have many fields:
>
> page-title
>
> page-description
>
> page-body
>
> Program may iterate over fields. After each editing of title, the
> program moves back to the initial iteration of fields or main program
> loop. After editing of title, I move back to the above list. Then I
> edit description, I should be able to move back.
>
> If hook is installed, it just ensured to read back the string into
> database, but it escapes the main loop, program execution basically
> and there, as nothing is holding it.

It looks like you want to guide the user through editing each field of
a database record in sequence, so that they edit the title first,
then, when they indicate they are done with the title, you make them
edit the description, and when they are finished with that, you ask
them to edit the body.

This is not a pleasant user experience. What if I make a mistake in
the title but notice it only after I have pressed the “finish editing”
key on the title? How do I go back from description to the title?


I can see two other workflows that would be better for the user.

1: You present the whole record in a single buffer. Invent some syntax
that lets you delimit the fields. When the user indicates they are
done editing the record, go throug the buffer and parse out each
field, then update the record in the database. (Close analog: A mail
message buffer with From, To, Subject and Body as separate fields in a
single buffer.)

2: Present a record buffer that lists out all fields. When the user
positions the point on a field and presses RET, open a new buffer that
lets them edit this field. When they finish editing the selected
field, update the record and close the field buffer. They end up back
in the record buffer and can select another field for editing. (Close
analog: Dired for a directory, letting you edit each file
independently.)

In any case, your program does not drive the workflow. The user does.

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 18:12]:
> Is the program iterating over the fields in some predefined order?

I can choose which field to edit, like using helm and then choosing a
field to edit. But more often I keep it without helm. There is
completing-read. And I have choices like to choose what to edit, then
it comes back.

> Also, are you feeding back each field individually, or do you need to
> have them all edited before feeding them back as a single record?

Each field individually.

> One possibility would be to let the user edit all the fields in the
> same buffer; then killing that buffer would be your signal that
> everything is ready to be fed back, and you could do that feeding in
> the hook function itself.

There are too many tables, fields, that is not a good solution, and
also not reliable to let too many information pieces waiting to be
inserted back into database.

> > It could be solved if I could hold on find-file, and to know that
> > find-file finished its job, so that Emacs Lisp can continue after
> > find-file
> 
> That isn't workable, since find-file finishes its job once it has the
> file's contents in a buffer.  The user didn't yet edit the buffer, so
> it is not yet time for you to do anything.  Your mental model seems to
> be that find-file only returns when the user finishes editing and
> saves the edits, but that's not how this works in reality.

OK fine, it is not working that way.

Look what I have observed:

M-x shell

§ emacsclient "file"

it works here inside of M-x shell where it says "Waiting for
Emacs..."

So I can launch emacsclient from shell within Emacs with waiting
stage.

Do you know if I could somehow invoke automatically this below?

To do some invokation like M-x shell, but with the the shell command
something like: `emacsclient file', so to launch emacsclient with such
waiting stage and upon return I could then continue program execution.

Jean

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 18:44:39 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2019-08-24 18:12]:
> > Is the program iterating over the fields in some predefined order?
> 
> I can choose which field to edit, like using helm and then choosing a
> field to edit. But more often I keep it without helm. There is
> completing-read. And I have choices like to choose what to edit, then
> it comes back.
> 
> > Also, are you feeding back each field individually, or do you need to
> > have them all edited before feeding them back as a single record?
> 
> Each field individually.

Then I don't understand the difficulty.  You already have a loop that
goes over the fields one by one, right?  So, for each field let the
user edit it, then feed the result back to the database, and continue
to the next field.  The "feed back to the database" part can be done
from a function called by kill-buffer-hook, and it will be triggered
by the user killing the edit buffer once he/she is done editing.

What is missing from this idea to make it work for your program?

> M-x shell
> 
> § emacsclient "file"
> 
> it works here inside of M-x shell where it says "Waiting for
> Emacs..."
> 
> So I can launch emacsclient from shell within Emacs with waiting
> stage.

Yes, but this won't get you anywhere past the waiting stage, because
there's no Emacs server that can serve the emacsclient's request.  I
thought I explained that earlier.  You cannot do that via emacsclient,
when the server is in the same Emacs which invoked emacsclient.  It
doesn't matter how you invoke emacsclient from Emacs, you cannot have
its request served within that same Emacs session.

Moreover: you don't need it.  You have all of Emacs already at your
server; why would you want to ask it to edit something via an outside
client??

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 19:55:58 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > M-x shell
> > 
> > § emacsclient "file"
> > 
> > it works here inside of M-x shell where it says "Waiting for
> > Emacs..."
> > 
> > So I can launch emacsclient from shell within Emacs with waiting
> > stage.
> 
> Yes, but this won't get you anywhere past the waiting stage, because
> there's no Emacs server that can serve the emacsclient's request.

Actually, you know what: it will work.  So if you insist on doing it
via emacsclient, go ahead and do it via the shell buffer.

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

[Jean Louis]

* Yuri Khan <yuri.v.khan@gmail.com> [2019-08-24 18:19]:
> On Sat, Aug 24, 2019 at 10:51 PM Jean Louis <bugs@gnu.support> wrote:
> 
> > A database table can have many fields:
> >
> > page-title
> >
> > page-description
> >
> > page-body
> >
> > Program may iterate over fields. After each editing of title, the
> > program moves back to the initial iteration of fields or main program
> > loop. After editing of title, I move back to the above list. Then I
> > edit description, I should be able to move back.
> >
> > If hook is installed, it just ensured to read back the string into
> > database, but it escapes the main loop, program execution basically
> > and there, as nothing is holding it.
> 
> It looks like you want to guide the user through editing each field of
> a database record in sequence, so that they edit the title first,
> then, when they indicate they are done with the title, you make them
> edit the description, and when they are finished with that, you ask
> them to edit the body.

> This is not a pleasant user experience. What if I make a mistake in
> the title but notice it only after I have pressed the “finish editing”
> key on the title? How do I go back from description to the title?

I don't know what is the alternative that you think of. If you think
of editing everything on the screen, even then user can make a
mistake.

I have currently completion-read which can be transformed into helm,
by helm-mode, and helm-mode combinations.

Look here the demonstration how it is done:
https://gnu.support/images/2019/08/2019-08-24/2019-08-24-18:49:43.ogv

> I can see two other workflows that would be better for the user.
> 
> 1: You present the whole record in a single buffer.

I understand what you mean. There are too many tables with too many
records, and it would not fit on single screen, not practical.

> 2: Present a record buffer that lists out all fields. When the user
> positions the point on a field and presses RET, open a new buffer that
> lets them edit this field. When they finish editing the selected
> field, update the record and close the field buffer. They end up back
> in the record buffer and can select another field for editing. (Close
> analog: Dired for a directory, letting you edit each file
> independently.)

That is about the same what I have now, just using helm.

Problem is not with small descriptions, titles, names, numbers, that
is really least problem, as situation is like this:

User looking into other buffer, or paper, or phone, entering contact
name. This information exists outside. In case of mistake, information
can be re-edited, as information anyway arrives from outside.

Some notes are coming from email messages, if the note is not well
edited or becomes empty, it can be re-edited as information exists
outside.

Problem is currently with pages, like few thousands pages, which I
have been editing from common lisp, launching emacsclient, editing
pages, emacsclient returns back, I could read string from file.

I cannot do same from within Emacs. I am now thinking even invoking
somehow external lisp or just anything that can launch externally the
emacsclient with waiting stage, and then read back the string. This
could be one solution, I need to figure out how to do it.

Or other solution for me could be to figure out how not to cancel
(recursive-edit) with launches of emacsclient in background.

Jean

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 18:56]:
> > Date: Sat, 24 Aug 2019 18:44:39 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2019-08-24 18:12]:
> > > Is the program iterating over the fields in some predefined order?
> > 
> > I can choose which field to edit, like using helm and then choosing a
> > field to edit. But more often I keep it without helm. There is
> > completing-read. And I have choices like to choose what to edit, then
> > it comes back.
> > 
> > > Also, are you feeding back each field individually, or do you need to
> > > have them all edited before feeding them back as a single record?
> > 
> > Each field individually.
> 
> Then I don't understand the difficulty.  You already have a loop that
> goes over the fields one by one, right?  So, for each field let the
> user edit it, then feed the result back to the database, and continue
> to the next field.  The "feed back to the database" part can be done
> from a function called by kill-buffer-hook, and it will be triggered
> by the user killing the edit buffer once he/she is done editing.
> 
> What is missing from this idea to make it work for your program?

If I use the option with (recursive-edit) such will be cancelled for
example if I open email in other window from mutt using
emacsclient. As I do need to copy information from emails, such as
contact information, phone numbers, and similar.

This could be a bug, I do not know. If I could ensure that
(recursive-edit) remains stable for one buffer, without being
interrupted by calls of emacsclient, I could use that. I am already
now using it, but it is not perfect.

It is not good for information that comes from mind, as if I rely on
the buffer and recursive edit, and move to other buffers or invoke
emacsclient, I may lose information.

It is thus better keeping information in the file.

If I keep information in the file and edit it as buffer and file,
without recursive-edit, then I do not know how to return to the
initial programming loop.

> Yes, but this won't get you anywhere past the waiting stage, because
> there's no Emacs server that can serve the emacsclient's request.  I
> thought I explained that earlier.  You cannot do that via emacsclient,
> when the server is in the same Emacs which invoked emacsclient.  It
> doesn't matter how you invoke emacsclient from Emacs, you cannot have
> its request served within that same Emacs session.

If I have this file here as "~/bin/edit-file.sh"

#!/home/data1/protected/bin/lisp
(setf (getenv "EDITOR") "emacsclient")
(ed "~/new")

Then I see that I can invoke emacsclient from outside

(inferior-lisp "~/bin/edit-file.sh")

so I know it is not pure Emacs Lisp, it invokes basically shell file
that invokes lisp inside, but somehow it works.

I am trying to find solution to have it "waiting" so that outside
function finishes editing, then I can read the file.

> Moreover: you don't need it.  You have all of Emacs already at your
> server; why would you want to ask it to edit something via an outside
> client??

Because I do not know how to come back to main program loop after
using kill-buffer-hook to read the straing back. So far I made it, I
can read the string back, but cannot go back to main loop.

Actually  I need the waiting stage in any manner, so that emacsclient
is invoked, even from outside lisp (or any other language) and that I
can then continue execution.

I hope you understand that.

Jean

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 19:03]:
> > Date: Sat, 24 Aug 2019 19:55:58 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > 
> > > M-x shell
> > > 
> > > § emacsclient "file"
> > > 
> > > it works here inside of M-x shell where it says "Waiting for
> > > Emacs..."
> > > 
> > > So I can launch emacsclient from shell within Emacs with waiting
> > > stage.
> > 
> > Yes, but this won't get you anywhere past the waiting stage, because
> > there's no Emacs server that can serve the emacsclient's request.
> 
> Actually, you know what: it will work.  So if you insist on doing it
> via emacsclient, go ahead and do it via the shell buffer.

I have strong feeling that it can work. Please give me better
specification. Which function you propose?

Jean

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 19:15:38 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > Moreover: you don't need it.  You have all of Emacs already at your
> > server; why would you want to ask it to edit something via an outside
> > client??
> 
> Because I do not know how to come back to main program loop after
> using kill-buffer-hook to read the straing back.

You should set that up in the hook, like setting some variable to
indicate that you need to go to the next field.  Or something.

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 19:17:11 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> > > > § emacsclient "file"
> > > > 
> > > > it works here inside of M-x shell where it says "Waiting for
> > > > Emacs..."
> > > > 
> > > > So I can launch emacsclient from shell within Emacs with waiting
> > > > stage.
> > > 
> > > Yes, but this won't get you anywhere past the waiting stage, because
> > > there's no Emacs server that can serve the emacsclient's request.
> > 
> > Actually, you know what: it will work.  So if you insist on doing it
> > via emacsclient, go ahead and do it via the shell buffer.
> 
> I have strong feeling that it can work. Please give me better
> specification. Which function you propose?

I don't understand the question.  I thought you have already figured
everything out for doing this via emacsclient.  Otherwise, why did you
keep asking about emacsclient all the time?

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 19:24]:
> > Date: Sat, 24 Aug 2019 19:17:11 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > > > > § emacsclient "file"
> > > > > 
> > > > > it works here inside of M-x shell where it says "Waiting for
> > > > > Emacs..."
> > > > > 
> > > > > So I can launch emacsclient from shell within Emacs with waiting
> > > > > stage.
> > > > 
> > > > Yes, but this won't get you anywhere past the waiting stage, because
> > > > there's no Emacs server that can serve the emacsclient's request.
> > > 
> > > Actually, you know what: it will work.  So if you insist on doing it
> > > via emacsclient, go ahead and do it via the shell buffer.
> > 
> > I have strong feeling that it can work. Please give me better
> > specification. Which function you propose?
> 
> I don't understand the question.  I thought you have already figured
> everything out for doing this via emacsclient.  Otherwise, why did you
> keep asking about emacsclient all the time?

I have three possible directions to solve that:

- use recursive-edit, if it would not interrupt while calling
  emacsclient in the same time, is that a bug?

- use simple editing of buffer with kill-buffer-hook, if I can come
  back to initial program execution, as program execution must be wait
  for editing to finish, I do not know how

- use emacsclient from external program somehow, provided that I can
  wait for it to finish

Jean

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 19:37:11 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: GNU Emacs Help <help-gnu-emacs@gnu.org>
> 
> - use simple editing of buffer with kill-buffer-hook, if I can come
>   back to initial program execution, as program execution must be wait
>   for editing to finish, I do not know how

A command such as "M-x loop-continue" (possibly bound globally to some
key sequence) should be enough to resolve the "come back to initial
program execution" part.

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 20:26]:
> > Date: Sat, 24 Aug 2019 19:37:11 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: GNU Emacs Help <help-gnu-emacs@gnu.org>
> > 
> > - use simple editing of buffer with kill-buffer-hook, if I can come
> >   back to initial program execution, as program execution must be wait
> >   for editing to finish, I do not know how
> 
> A command such as "M-x loop-continue" (possibly bound globally to some
> key sequence) should be enough to resolve the "come back to initial
> program execution" part.

I do not have loop-continue, is it in some package?

Jean

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

[Eli Zaretskii]

> Date: Sat, 24 Aug 2019 20:50:46 +0200
> From: Jean Louis <bugs@gnu.support>
> Cc: help-gnu-emacs@gnu.org
> 
> * Eli Zaretskii <eliz@gnu.org> [2019-08-24 20:26]:
> > > Date: Sat, 24 Aug 2019 19:37:11 +0200
> > > From: Jean Louis <bugs@gnu.support>
> > > Cc: GNU Emacs Help <help-gnu-emacs@gnu.org>
> > > 
> > > - use simple editing of buffer with kill-buffer-hook, if I can come
> > >   back to initial program execution, as program execution must be wait
> > >   for editing to finish, I do not know how
> > 
> > A command such as "M-x loop-continue" (possibly bound globally to some
> > key sequence) should be enough to resolve the "come back to initial
> > program execution" part.
> 
> I do not have loop-continue, is it in some package?

That's a command you need to write.  It is supposed to go to the next
field and generate a buffer for the user to edit that field.

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

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2019-08-24 21:04]:
> > Date: Sat, 24 Aug 2019 20:50:46 +0200
> > From: Jean Louis <bugs@gnu.support>
> > Cc: help-gnu-emacs@gnu.org
> > 
> > * Eli Zaretskii <eliz@gnu.org> [2019-08-24 20:26]:
> > > > Date: Sat, 24 Aug 2019 19:37:11 +0200
> > > > From: Jean Louis <bugs@gnu.support>
> > > > Cc: GNU Emacs Help <help-gnu-emacs@gnu.org>
> > > > 
> > > > - use simple editing of buffer with kill-buffer-hook, if I can come
> > > >   back to initial program execution, as program execution must be wait
> > > >   for editing to finish, I do not know how
> > > 
> > > A command such as "M-x loop-continue" (possibly bound globally to some
> > > key sequence) should be enough to resolve the "come back to initial
> > > program execution" part.
> > 
> > I do not have loop-continue, is it in some package?
> 
> That's a command you need to write.  It is supposed to go to the next
> field and generate a buffer for the user to edit that field.

I know what you mean. But command that handles next fields is in
the depth 0, I just need to return to senior function, or find
way how to wait on find-file

Jean