help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jean Louis
Subject: Re: How to reliably edit a file from within Emacs Lisp and return a string?
Date: Fri, 23 Aug 2019 16:01:45 +0200
User-agent: Mutt/1.10.1 (2018-07-13)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]