unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
* Must prevent switching from recursive edit buffers
@ 2024-12-18  7:50 Jean Louis
  2024-12-18 16:13 ` [External] : " Drew Adams
  0 siblings, 1 reply; 2+ messages in thread
From: Jean Louis @ 2024-12-18  7:50 UTC (permalink / raw)
  To: Help GNU Emacs

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






^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: [External] : Must prevent switching from recursive edit buffers
  2024-12-18  7:50 Must prevent switching from recursive edit buffers Jean Louis
@ 2024-12-18 16:13 ` Drew Adams
  0 siblings, 0 replies; 2+ messages in thread
From: Drew Adams @ 2024-12-18 16:13 UTC (permalink / raw)
  To: Jean Louis, Help GNU Emacs

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



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-12-18 16:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-18  7:50 Must prevent switching from recursive edit buffers Jean Louis
2024-12-18 16:13 ` [External] : " Drew Adams

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