* How to reliably edit a file from within Emacs Lisp and return a string? @ 2019-08-22 21:31 Jean Louis 2019-08-22 22:01 ` Noam Postavsky 0 siblings, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-22 21:31 UTC (permalink / raw) To: GNU Emacs Help 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-22 21:31 How to reliably edit a file from within Emacs Lisp and return a string? Jean Louis @ 2019-08-22 22:01 ` Noam Postavsky 2019-08-22 22:46 ` Jean Louis 0 siblings, 1 reply; 39+ messages in thread From: Noam Postavsky @ 2019-08-22 22:01 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help 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). ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-22 22:01 ` Noam Postavsky @ 2019-08-22 22:46 ` Jean Louis 2019-08-22 23:10 ` Óscar Fuentes 2019-08-22 23:22 ` Noam Postavsky 0 siblings, 2 replies; 39+ messages in thread From: Jean Louis @ 2019-08-22 22:46 UTC (permalink / raw) To: Noam Postavsky; +Cc: GNU Emacs Help * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-22 22:46 ` Jean Louis @ 2019-08-22 23:10 ` Óscar Fuentes 2019-08-22 23:22 ` Noam Postavsky 1 sibling, 0 replies; 39+ messages in thread From: Óscar Fuentes @ 2019-08-22 23:10 UTC (permalink / raw) To: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-22 22:46 ` Jean Louis 2019-08-22 23:10 ` Óscar Fuentes @ 2019-08-22 23:22 ` Noam Postavsky 2019-08-23 1:19 ` Jean Louis 2019-08-23 7:49 ` Eli Zaretskii 1 sibling, 2 replies; 39+ messages in thread From: Noam Postavsky @ 2019-08-22 23:22 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-22 23:22 ` Noam Postavsky @ 2019-08-23 1:19 ` Jean Louis 2019-08-23 1:27 ` Noam Postavsky 2019-08-23 7:49 ` Eli Zaretskii 1 sibling, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-23 1:19 UTC (permalink / raw) To: Noam Postavsky; +Cc: GNU Emacs Help * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 1:19 ` Jean Louis @ 2019-08-23 1:27 ` Noam Postavsky 0 siblings, 0 replies; 39+ messages in thread From: Noam Postavsky @ 2019-08-23 1:27 UTC (permalink / raw) To: Jean Louis; +Cc: GNU Emacs Help 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-22 23:22 ` Noam Postavsky 2019-08-23 1:19 ` Jean Louis @ 2019-08-23 7:49 ` Eli Zaretskii 2019-08-23 14:01 ` Jean Louis 2019-08-24 12:15 ` Jean Louis 1 sibling, 2 replies; 39+ messages in thread From: Eli Zaretskii @ 2019-08-23 7:49 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 7:49 ` Eli Zaretskii @ 2019-08-23 14:01 ` Jean Louis 2019-08-23 14:14 ` Robert Pluim ` (2 more replies) 2019-08-24 12:15 ` Jean Louis 1 sibling, 3 replies; 39+ messages in thread From: Jean Louis @ 2019-08-23 14:01 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 14:01 ` Jean Louis @ 2019-08-23 14:14 ` Robert Pluim 2019-08-24 12:20 ` Jean Louis 2019-08-24 12:24 ` Jean Louis 2019-08-23 14:25 ` Eli Zaretskii 2019-08-23 21:44 ` Marcin Borkowski 2 siblings, 2 replies; 39+ messages in thread From: Robert Pluim @ 2019-08-23 14:14 UTC (permalink / raw) To: Jean Louis; +Cc: help-gnu-emacs >>>>> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 14:14 ` Robert Pluim @ 2019-08-24 12:20 ` Jean Louis 2019-08-24 12:24 ` Jean Louis 1 sibling, 0 replies; 39+ messages in thread From: Jean Louis @ 2019-08-24 12:20 UTC (permalink / raw) To: Robert Pluim; +Cc: GNU Emacs Help * 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 14:14 ` Robert Pluim 2019-08-24 12:20 ` Jean Louis @ 2019-08-24 12:24 ` Jean Louis 1 sibling, 0 replies; 39+ messages in thread From: Jean Louis @ 2019-08-24 12:24 UTC (permalink / raw) To: Robert Pluim; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 14:01 ` Jean Louis 2019-08-23 14:14 ` Robert Pluim @ 2019-08-23 14:25 ` Eli Zaretskii 2019-08-24 12:19 ` Jean Louis 2019-08-23 21:44 ` Marcin Borkowski 2 siblings, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2019-08-23 14:25 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 14:25 ` Eli Zaretskii @ 2019-08-24 12:19 ` Jean Louis 2019-08-24 12:30 ` Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 12:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: GNU Emacs Help * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 12:19 ` Jean Louis @ 2019-08-24 12:30 ` Eli Zaretskii 2019-08-24 12:41 ` Jean Louis 2019-08-24 13:08 ` Jean Louis 0 siblings, 2 replies; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 12:30 UTC (permalink / raw) To: help-gnu-emacs > 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? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 12:30 ` Eli Zaretskii @ 2019-08-24 12:41 ` Jean Louis 2019-08-24 13:17 ` Eli Zaretskii 2019-08-24 13:08 ` Jean Louis 1 sibling, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 12:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: GNU Emacs Help * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 12:41 ` Jean Louis @ 2019-08-24 13:17 ` Eli Zaretskii 2019-08-24 14:14 ` Jean Louis 0 siblings, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 13:17 UTC (permalink / raw) To: help-gnu-emacs > 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? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 13:17 ` Eli Zaretskii @ 2019-08-24 14:14 ` Jean Louis 2019-08-24 14:55 ` Jean Louis 0 siblings, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 14:14 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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))) ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 14:14 ` Jean Louis @ 2019-08-24 14:55 ` Jean Louis 2019-08-24 15:10 ` Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 14:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 14:55 ` Jean Louis @ 2019-08-24 15:10 ` Eli Zaretskii 2019-08-24 15:51 ` Jean Louis 0 siblings, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 15:10 UTC (permalink / raw) To: help-gnu-emacs > 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? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 15:10 ` Eli Zaretskii @ 2019-08-24 15:51 ` Jean Louis 2019-08-24 16:11 ` Eli Zaretskii 2019-08-24 16:18 ` Yuri Khan 0 siblings, 2 replies; 39+ messages in thread From: Jean Louis @ 2019-08-24 15:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 15:51 ` Jean Louis @ 2019-08-24 16:11 ` Eli Zaretskii 2019-08-24 16:44 ` Jean Louis 2019-08-24 16:18 ` Yuri Khan 1 sibling, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 16:11 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 16:11 ` Eli Zaretskii @ 2019-08-24 16:44 ` Jean Louis 2019-08-24 16:55 ` Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 16:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 16:44 ` Jean Louis @ 2019-08-24 16:55 ` Eli Zaretskii 2019-08-24 17:02 ` Eli Zaretskii 2019-08-24 17:15 ` Jean Louis 0 siblings, 2 replies; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 16:55 UTC (permalink / raw) To: help-gnu-emacs > 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?? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 16:55 ` Eli Zaretskii @ 2019-08-24 17:02 ` Eli Zaretskii 2019-08-24 17:17 ` Jean Louis 2019-08-24 17:15 ` Jean Louis 1 sibling, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 17:02 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 17:02 ` Eli Zaretskii @ 2019-08-24 17:17 ` Jean Louis 2019-08-24 17:23 ` Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 17:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 17:17 ` Jean Louis @ 2019-08-24 17:23 ` Eli Zaretskii 2019-08-24 17:37 ` Jean Louis 0 siblings, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 17:23 UTC (permalink / raw) To: help-gnu-emacs > 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? ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 17:23 ` Eli Zaretskii @ 2019-08-24 17:37 ` Jean Louis 2019-08-24 18:25 ` Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 17:37 UTC (permalink / raw) To: Eli Zaretskii; +Cc: GNU Emacs Help * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 17:37 ` Jean Louis @ 2019-08-24 18:25 ` Eli Zaretskii 2019-08-24 18:50 ` Jean Louis 0 siblings, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 18:25 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 18:25 ` Eli Zaretskii @ 2019-08-24 18:50 ` Jean Louis 2019-08-24 19:03 ` Eli Zaretskii 0 siblings, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 18:50 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 18:50 ` Jean Louis @ 2019-08-24 19:03 ` Eli Zaretskii 2019-08-24 21:30 ` Jean Louis 0 siblings, 1 reply; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 19:03 UTC (permalink / raw) To: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 19:03 ` Eli Zaretskii @ 2019-08-24 21:30 ` Jean Louis 0 siblings, 0 replies; 39+ messages in thread From: Jean Louis @ 2019-08-24 21:30 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 16:55 ` Eli Zaretskii 2019-08-24 17:02 ` Eli Zaretskii @ 2019-08-24 17:15 ` Jean Louis 2019-08-24 17:22 ` Eli Zaretskii 1 sibling, 1 reply; 39+ messages in thread From: Jean Louis @ 2019-08-24 17:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 17:15 ` Jean Louis @ 2019-08-24 17:22 ` Eli Zaretskii 0 siblings, 0 replies; 39+ messages in thread From: Eli Zaretskii @ 2019-08-24 17:22 UTC (permalink / raw) To: Jean Louis; +Cc: help-gnu-emacs > 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 15:51 ` Jean Louis 2019-08-24 16:11 ` Eli Zaretskii @ 2019-08-24 16:18 ` Yuri Khan 2019-08-24 17:07 ` Jean Louis 1 sibling, 1 reply; 39+ messages in thread From: Yuri Khan @ 2019-08-24 16:18 UTC (permalink / raw) To: Jean Louis; +Cc: help-gnu-emacs 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 16:18 ` Yuri Khan @ 2019-08-24 17:07 ` Jean Louis 0 siblings, 0 replies; 39+ messages in thread From: Jean Louis @ 2019-08-24 17:07 UTC (permalink / raw) To: Yuri Khan; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-24 12:30 ` Eli Zaretskii 2019-08-24 12:41 ` Jean Louis @ 2019-08-24 13:08 ` Jean Louis 1 sibling, 0 replies; 39+ messages in thread From: Jean Louis @ 2019-08-24 13:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 14:01 ` Jean Louis 2019-08-23 14:14 ` Robert Pluim 2019-08-23 14:25 ` Eli Zaretskii @ 2019-08-23 21:44 ` Marcin Borkowski 2 siblings, 0 replies; 39+ messages in thread From: Marcin Borkowski @ 2019-08-23 21:44 UTC (permalink / raw) To: Jean Louis; +Cc: help-gnu-emacs 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: How to reliably edit a file from within Emacs Lisp and return a string? 2019-08-23 7:49 ` Eli Zaretskii 2019-08-23 14:01 ` Jean Louis @ 2019-08-24 12:15 ` Jean Louis 1 sibling, 0 replies; 39+ messages in thread From: Jean Louis @ 2019-08-24 12:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: help-gnu-emacs * 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2019-08-24 21:30 UTC | newest] Thread overview: 39+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2019-08-22 21:31 How to reliably edit a file from within Emacs Lisp and return a string? Jean Louis 2019-08-22 22:01 ` Noam Postavsky 2019-08-22 22:46 ` Jean Louis 2019-08-22 23:10 ` Óscar Fuentes 2019-08-22 23:22 ` Noam Postavsky 2019-08-23 1:19 ` Jean Louis 2019-08-23 1:27 ` Noam Postavsky 2019-08-23 7:49 ` Eli Zaretskii 2019-08-23 14:01 ` Jean Louis 2019-08-23 14:14 ` Robert Pluim 2019-08-24 12:20 ` Jean Louis 2019-08-24 12:24 ` Jean Louis 2019-08-23 14:25 ` Eli Zaretskii 2019-08-24 12:19 ` Jean Louis 2019-08-24 12:30 ` Eli Zaretskii 2019-08-24 12:41 ` Jean Louis 2019-08-24 13:17 ` Eli Zaretskii 2019-08-24 14:14 ` Jean Louis 2019-08-24 14:55 ` Jean Louis 2019-08-24 15:10 ` Eli Zaretskii 2019-08-24 15:51 ` Jean Louis 2019-08-24 16:11 ` Eli Zaretskii 2019-08-24 16:44 ` Jean Louis 2019-08-24 16:55 ` Eli Zaretskii 2019-08-24 17:02 ` Eli Zaretskii 2019-08-24 17:17 ` Jean Louis 2019-08-24 17:23 ` Eli Zaretskii 2019-08-24 17:37 ` Jean Louis 2019-08-24 18:25 ` Eli Zaretskii 2019-08-24 18:50 ` Jean Louis 2019-08-24 19:03 ` Eli Zaretskii 2019-08-24 21:30 ` Jean Louis 2019-08-24 17:15 ` Jean Louis 2019-08-24 17:22 ` Eli Zaretskii 2019-08-24 16:18 ` Yuri Khan 2019-08-24 17:07 ` Jean Louis 2019-08-24 13:08 ` Jean Louis 2019-08-23 21:44 ` Marcin Borkowski 2019-08-24 12:15 ` Jean Louis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).