[Top][All Lists]

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

Re: Stop frames stealing eachothers' minibuffers!

From: Gregory Heytings
Subject: Re: Stop frames stealing eachothers' minibuffers!
Date: Thu, 07 Jan 2021 23:34:18 +0000
User-agent: Alpine 2.22 (NEB 394 2020-01-19)

Let me repeat, it is not the content of your posts I find difficult to deal with. It's their rudeness and aggressiveness.

I think we are miscommunicating. I honestly don't understand where you perceive "rudeness and aggressiveness" in my posts. I can only say again that this was not at all my intention.

The old behavior is indeed valuable, if only because it is an old behavior.

So you're defending old bugs as valuable, simply because they're old. You decline to defend this behaviour on its merits. Nobody else has done so either, as far as I'm aware.

I did defend it on its merits, multiple times. What I said did not convince you; I should perhaps have written something more detailed, as I do below.

I experienced the behavior which surprised you from time to time, and found it coherent with the general Emacs behavior.

Let's first define that behavior again: from a user's point of view, in Emacs 21 (and possibly earlier) to 27, when minibuffers MB1 to MBn are active on a frame F1, and a command that activates the minibuffer is started on a frame F2, the minibuffers MB1 to MBn are moved to frame F2, and the minibuffer MBn+1 is created. This behavior happens with enable-recursive-minibuffers set to t, either globally or temporarily.

The other possible behaviors are, AFAICS, the ones you try to implement:

1. Either tying each minibuffer to the frame in which it is created. If you tie each minibuffer to the frame in which it was created, there are two options:

1.1. Either it becomes possible to interact with them. From an UI point of view, the problem of that behavior is that it is not coherent with recursive edits in Emacs, of which recursive minibuffers are an instance. When you enter a recursive edit you cannot act on the non-recursive edit level or on the previous recursive edit levels anymore, you first have to leave the current recursive edit. As the Emacs manual explains, recursive edits "constrain you to go back in a particular order---from the innermost level toward the top level." IOW, that behavior would violate the general recursive editing constraint.

1.2. Or you make sure in one way or another that it is not possible to interact with them, which means that the user sees a minibuffer that it cannot use (for instance by clicking on it). From an UI point of view, this would be counter-intuitive; I don't know any other UI element that is displayed by Emacs and that you cannot interact with.

2. Or always moving the minibuffers to the currently active frame. From an UI point of view, the problem is that such a movement is, in most cases, gratuitious: when you start a command in a frame and switch to another frame, in most cases this switch is a temporary one (for example to check the documentation of the command you just started), and what you intend to do is to switch back to the frame in which you started the command to complete it.

The old behavior, which you despise, is not "chaotic" (see the definition of that word in Wordnet: "completely unordered and unpredictable and confusing", or in Wiktionary: "extremely disorganized"), it is well-defined, and it is a reasonable solution which avoids (at least) these three problems. And it has worked well for virtually all Emacs users in the last twenty years.

There is, in fact, a fourth possible behavior, which AFAICT has not been discussed in this thread:

1.3. Tying each minibuffer to the frame in which it is created, but make it invisible when a recursive minibuffer is entered in another frame, and visible again when that recursive minibuffer is left. The problem I see in this potential behavior is that, upon leaving the recursive minibuffer, the user would have no indication that another minibuffer is still (or rather, again) open in another frame, waiting for their input. This is yet another problem that the old behavior avoids.

reply via email to

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