Must prevent switching from recursive edit buffers

Must prevent switching from recursive edit buffers

[Jean Louis]

I would like to find the solution to prevent me as user to switch away
from the recursive edit.

Recursive edit is not file editing. In my case it is editing of the
database values, in general strings. That is what I am using currently
7200 times per month, and do not need different solution at this moment.

I would like to ensure, that if I am switching away from a buffer
which I am editing with `recursive-edit', that I am warned, or that I
can ensure that switch is detected, so that I can invoke other
functions such as asking user to save buffer, or automatically saving
it, or closing the buffer.

I am testing this variable:
(add-hook 'window-buffer-change-functions 'my-speak nil t)

I can see:

Its value is (my-speak)
Local in buffer *mail*; global value is nil

(defun my-speak (&optional window)
(rcd-message "%s" window)
(rcd-speak "Hello there"))

And I can here voice when I for example, split the window.

And I can see message: #<window 224 on *mail*>

Which is alright, but I cannot hear message when I switch away from
buffer.

If I give it global value, then it will give me message.

That means it will be invoked in the other buffer, but then how do I
recognize that previous buffer is the one with recursive edit?

Maybe I could make function to switch to window quickly, recognize if
it has recursive edit, or maybe recognize if some buffer local
variable has been set, to stop that recursive edit or record value
from inside.

I see this on above change:
#<window 224 on *mail*>

Best would be to have list of recursive edit buffers but sadly I do
not know how to get it. All I can see is in modeline [(Mail WK Fill)]
which indicates there is one or 3-4 or 10 pending recursive buffers,
but they are not shown in any list. 

If I list all buffers, and delete all of them, recursive-edit buffers
still remain hidden.

Maybe solution could be setting up global functions for
'window-buffer-change-functions to detect at other window, if
recursive-edit buffer is still open, in order to close it, save buffer
into the database;

(abort-recursive-edit) is not quite a solution, as that means my
editing my be lost.

Basically, I would like to keep 1 recursive-edit at maximum, not more.

I appreciate if someone finds better approach to solve the problem of
pending recursive-edit buffers.

Jean

RE: [External] : Must prevent switching from recursive edit buffers

[Drew Adams]

I'm not an expert on recursive edit.  But I think
that (apart from the special case of a minibuffer)
a recursive edit isn't in any way buffer or mode
or anything else specific - it's global.

One thing you can do, which doesn't directly
address your question, is to make it more obvious
when you're in a recursive edit, and at what level.

For that, the little library `rec-edit.el' can
help.

Description:

https://www.emacswiki.org/emacs/RecursiveEdit#rec-edit.el

Code:

https://www.emacswiki.org/emacs/download/rec-edit.el

Re: Must prevent switching from recursive edit buffers

[Stefan Monnier via Users list for the GNU Emacs text editor]

> I would like to ensure, that if I am switching away from a buffer
> which I am editing with `recursive-edit', that I am warned, or that I
> can ensure that switch is detected, so that I can invoke other
> functions such as asking user to save buffer, or automatically saving
> it, or closing the buffer.

I can't understand the above.  You start talking about "I" doing things
which I associate with user actions, but then you say "I can invoke other
functions such as asking user to save buffer" suggesting "I" is not the
user after all.


        Stefan

Re: Must prevent switching from recursive edit buffers

[Jean Louis]

* Stefan Monnier via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2024-12-19 02:43]:
> > I would like to ensure, that if I am switching away from a buffer
> > which I am editing with `recursive-edit', that I am warned, or that I
> > can ensure that switch is detected, so that I can invoke other
> > functions such as asking user to save buffer, or automatically saving
> > it, or closing the buffer.
> 
> I can't understand the above.  You start talking about "I" doing things
> which I associate with user actions, but then you say "I can invoke other
> functions such as asking user to save buffer" suggesting "I" is not the
> user after all.

Yes, as whatever I do, users such as staff members will do too. That
is minor problem. I = user and user = others;

Basically, I would like to recognize that bufer where I am invoking
recursive-edit is at some moment not visible any more, and I would
like programmatically to find out WHICH buffer is it.

Now I have no idea which buffer is it, and multiple recursive-edits
stay active, even though there is no buffer with recursive-edit.

That is some mystery. Those recursive-edit buffers show as

[[[[[(Mail WK Fill)]]]]]

but I cannot know in the list of buffer and CANNOT SEE to what buffers
those [[[[]]]] belogns.

And if I inspect buffers, they are not in recursive-edit

It means that [[[[[[[[[[[]]]]]]]]]]] recursive edit buffers disappear
from buffer list.

-- 
Jean Louis

Re: Must prevent switching from recursive edit buffers

[Stefan Monnier]

> That is some mystery. Those recursive-edit buffers show as
>
> [[[[[(Mail WK Fill)]]]]]
>
> but I cannot know in the list of buffer and CANNOT SEE to what buffers
> those [[[[]]]] belogns.

Hmm... currently I think that Emacs's code does not record a clear
association between a recursive edit and "the buffer to which it
belongs" (arguably even this concept is ill-defined, although in
practice it is probably true that there is almost always a buffer with
which we can associate the recursive edit).

Maybe we could start by implementing a command which shows a list of
current recursive edits by walking the backtrace and trying to guess
which "kind" of recursive edit it is and to which buffer is "belongs".

Kinds would be things like `minibuffer`, `debugger`, `edebug`,
`query-replace`, ...

That would have to rely on ad-hoc rules, but that would give us some
experience from which we could hopefully design a better API which ELisp
packages which use `recursive-edit` can then use to provide that same
information more directly.


        Stefan

Re: Must prevent switching from recursive edit buffers

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2024-12-21 18:24]:
> > That is some mystery. Those recursive-edit buffers show as
> >
> > [[[[[(Mail WK Fill)]]]]]
> >
> > but I cannot know in the list of buffer and CANNOT SEE to what buffers
> > those [[[[]]]] belogns.
> 
> Hmm... currently I think that Emacs's code does not record a clear
> association between a recursive edit and "the buffer to which it
> belongs" (arguably even this concept is ill-defined, although in
> practice it is probably true that there is almost always a buffer with
> which we can associate the recursive edit).
> 
> Maybe we could start by implementing a command which shows a list of
> current recursive edits by walking the backtrace and trying to guess
> which "kind" of recursive edit it is and to which buffer is
> "belongs".

That is missing, thanks for recognizing the lack of logic.

> Kinds would be things like `minibuffer`, `debugger`, `edebug`,
> `query-replace`, ...

But in my work they have always names. My recursive buffer opens full
screen like any other.

I understand someone or you, made similar function, but I don't like
it, so I use this function below.

(defun read-from-buffer (&optional value buffer-name mode title keymap place highlight-list minor-modes input-method)
  "Return string after editing it in buffer."
  (let* ((this-buffer (buffer-name))
	 (title (or title ""))
	 (value (or value ""))
	 (new-value value)
	 (point (cond ((numberp place) place)
		      ((listp place) (cdr (assoc "place" place)))))
	 (table (when (listp place) (cdr (assoc "table" place))))
	 (column (when (listp place) (cdr (assoc "column" place))))
	 (table-id (when (listp place) (cdr (assoc "table-id" place))))
	 (buffer-name (or buffer-name "*RCD String Editing*"))
	 (buffer-name (concat buffer-name " 🗒️"))
	 ;; (my-buffer-kill-hook kill-buffer-hook)
	 (read-buffer (get-buffer-create buffer-name)))
    (with-current-buffer read-buffer
      (switch-to-buffer read-buffer)
      (erase-buffer)
      (cond (mode (if (fboundp mode)
		      (funcall mode)
		    (rcd-message "You need `%s' mode" (symbol-name mode))))
	    (t (text-mode)))
      (setq rcd-db-current-table table)
      (setq rcd-db-current-column column)
      (setq rcd-db-current-table-id table-id)
      (local-set-key (kbd "<f8>") 'exit-recursive-edit)
      (local-set-key (kbd "C-c A") 'abort-recursive-edit)
      ;; total mess
      ;; (setq-local kill-buffer-hook (append kill-buffer-hook 
      ;; 					   (list 
      ;; 					    (lambda () 
      ;; 					      (setq-local kill-buffer-hook my-buffer-kill-hook)
      ;; 					      (kill-buffer read-buffer)
      ;; 					      (cond ((> (recursion-depth) 0) (exit-recursive-edit)))))))
      (when keymap
	(use-local-map keymap))
      (when input-method (set-input-method input-method))
      (when rcd-word-processing
	(rcd-word-processing))
      (setq header-line-format (format "%s ➜ Finish editing with or C-M-c or F8" title))
      (if (stringp value) (insert value))
      (rcd-highlight-list highlight-list)
      (goto-char (or point (point-min)))
      (rcd-speak "You may quit the buffer with Meta Control C")
      (message "When you're done editing press C-M-c or F8 to continue.")
      (setq eval-expression-debug-on-error nil)
      (while minor-modes
	(let ((minor-mode (pop minor-modes)))
	  (if minor-mode
	      (if (fboundp (intern minor-mode))
		  (funcall (intern minor-mode))
		(rcd-message "You need `%s' minor mode" (symbol-name minor-mode))))))
      (unwind-protect
	  (recursive-edit)
	(if (get-buffer-window read-buffer)
	    (progn
	      (setq new-value (buffer-substring (point-min) (point-max)))
	      (kill-buffer read-buffer))))
      (setq eval-expression-debug-on-error t)
      (prog1 new-value
	(switch-to-buffer this-buffer))))) ;; TODO if mode is used, maybe it should not return propertized string

> That would have to rely on ad-hoc rules, but that would give us some
> experience from which we could hopefully design a better API which ELisp
> packages which use `recursive-edit` can then use to provide that same
> information more directly.

My buffers open up in full window. Each of them has a name.

They are immediately available in the buffer list.

But I cannot know yet why, they also disappear, so I am left with
[[[[]]]] and do not know to what it belongs.

Then I go to the buffer list and I can start deleting buffers, but
have no idea which one is in recursive-edit, so sometimes I get
result:

- I have deleted buffers, and recursive edits are also resolved;

- sometimes I have deleted it and [[[[]]]] still remain on the
  modeline; and I have no idea why;

And I am still confused, maybe I am wrong about it in general.

-- 
Jean Louis

Re: Must prevent switching from recursive edit buffers

[Stefan Monnier]

>> Kinds would be things like `minibuffer`, `debugger`, `edebug`,
>> `query-replace`, ...
>
> But in my work they have always names. My recursive buffer opens full
> screen like any other.

That's a completely different problem since it's not about
recursive-edit in general but about those specific recursive-edits
introduced by your specific function, so you have complete freedom to
solve the problem on your side.

E.g. your function could add those buffers to a list of
`my-read-from-buffers` which you can then display via an ad-hoc command
you could implement, or you could display them in your modeline, or ...

> - sometimes I have deleted it and [[[[]]]] still remain on the
>   modeline; and I have no idea why;

Deleting a buffer won't get you out of the recursive edit (you didn't
tell Emacs about the link between the buffer and the recursive-edit;
you need a `kill-buffer-hook` for that).
Also, you can only get out of the most recent recursive-edit.
So, you can't eliminate the Nth recursive edit without also eliminating
all the >Nth recursive-edits.


        Stefan

RE: [External] : Re: Must prevent switching from recursive edit buffers

[Drew Adams]

> Also, you can only get out of the most recent recursive-edit.
> So, you can't eliminate the Nth recursive edit without also eliminating
> all the >Nth recursive-edits.

Well, there's always `(top-level)', to exit
all recursive-edit levels.

And there's function `recursion-depth'.  If
that returns N then you can programmatically
exit or abort any number of those N levels.

Re: Must prevent switching from recursive edit buffers

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2024-12-21 21:10]:
> E.g. your function could add those buffers to a list of
> `my-read-from-buffers` which you can then display via an ad-hoc command
> you could implement, or you could display them in your modeline, or
> ...

Good idea.

> > - sometimes I have deleted it and [[[[]]]] still remain on the
> >   modeline; and I have no idea why;
> 
> Deleting a buffer won't get you out of the recursive edit (you didn't
> tell Emacs about the link between the buffer and the recursive-edit;
> you need a `kill-buffer-hook` for that).

Aha, that is it, so that is something that didn't make sense. 

> Also, you can only get out of the most recent recursive-edit.
> So, you can't eliminate the Nth recursive edit without also eliminating
> all the >Nth recursive-edits.

Good to follow that, and I only need one in general.

At least now I could try to figure out how to solve it with hooks.

Yes, that is exactly that, many times I have pressed `C-x k' to kill
recursive buffer, because I didn't need it any more, but now how you
explained it, it seems they remain still somewhere in memory pending,
what does it mean actually? I have no idea. If I killed it, why it is
not internally killed? They are so invincible.

-- 
Jean Louis