From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#11939: 24.1; `save-buffers-kill-emacs' loses minibuffer focuswhenit calls `list-processes' Date: Sat, 04 Aug 2012 15:44:53 +0200 Message-ID: <501D2755.3030500@gmx.at> References: <83fw8iz7et.fsf@gnu.org><60948DD3935D452F85F95174474D06E9@us.oracle.com><838veaz34x.fsf@gnu.org><83629blssa.fsf@gnu.org>!<5011116B.4010106@gm x.at><32A934E820BA4853B84229C32F7145A1@us.oracle! ! .com><50116AD9.706 09@gmx.at><548032D12CE14E3689257D609E93482F@us.oracle.com><501175C9.3090803@gmx.at><2F76545DBD0C4F199A60F4B750709112@us.oracle.com><5012362A.7070200@gmx.at><4FB29D967D524DA99545D98266DD74B4@us.oracle.com><501540D0.50900@gmx.at><9E8DDE70EE6047779A17AA79E42D0FBA@us.oracle.com><50156DFE.6090807@gmx.at> <50165035.409040 1@gmx.at> <501BAAB0.1020! 807@gmx.at> <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1344087931 29882 80.91.229.3 (4 Aug 2012 13:45:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 4 Aug 2012 13:45:31 +0000 (UTC) Cc: 11939@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 04 15:45:30 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SxefY-0005AB-7m for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Aug 2012 15:45:28 +0200 Original-Received: from localhost ([::1]:42482 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxefX-00080m-KD for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Aug 2012 09:45:27 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:55851) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxefT-0007w0-J2 for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2012 09:45:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SxefR-00030r-Ae for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2012 09:45:23 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SxefR-00030f-69 for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2012 09:45:21 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Sxems-00028s-EM for bug-gnu-emacs@gnu.org; Sat, 04 Aug 2012 09:53:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Aug 2012 13:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11939 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11939-submit@debbugs.gnu.org id=B11939.13440883718206 (code B ref 11939); Sat, 04 Aug 2012 13:53:02 +0000 Original-Received: (at 11939) by debbugs.gnu.org; 4 Aug 2012 13:52:51 +0000 Original-Received: from localhost ([127.0.0.1]:60995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Sxemf-00028I-TK for submit@debbugs.gnu.org; Sat, 04 Aug 2012 09:52:51 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.22]:54262) by debbugs.gnu.org with smtp (Exim 4.72) (envelope-from ) id 1Sxemb-000287-84 for 11939@debbugs.gnu.org; Sat, 04 Aug 2012 09:52:47 -0400 Original-Received: (qmail invoked by alias); 04 Aug 2012 13:45:01 -0000 Original-Received: from 62-47-50-137.adsl.highway.telekom.at (EHLO [62.47.50.137]) [62.47.50.137] by mail.gmx.net (mp004) with SMTP; 04 Aug 2012 15:45:01 +0200 X-Authenticated: #14592706 X-Provags-ID: V01U2FsdGVkX1/yZGFVoEjybOENaggTF8HKCOm46culJLpEAQg2Gi YMFuS2YVUdibh8 In-Reply-To: <6461CCBF29034160B48D267E46D6FF0E@us.oracle.com> X-Y-GMX-Trusted: 0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:62812 Archived-At: > It is only the code that is calling for such a user dialog that knows that that > is what is being called for. By "such a user dialog", again, I mean (a) the > display of a buffer for information only, i.e., one that does not need the input > focus, and (b) request of user input with the previous buffer remaining current > and the minibuffer having the input focus. > > That is the use case that is problematic. It is the case where the above > systematic "fix" is inappropriate. There might be other such use cases, but it > is the only one I have encountered. And I have encountered it in several > different places (e.g., Dired *Marked Files* popup, *Process List* popup). > > My suggestion is, again, that we try to come up with a construct that covers > this use case, and then use it in the appropriate places: places where we do (a) > + (b). Users who want to pop up a frame with a minibuffer almost certainly want to supply their input right in the frame where the informational buffer is displayed. So there is a use case where the informational buffer must be made current. Also, when the new frame is popped up and `handle-switch-frame' switches to it, the informational buffer is made current anyway. So we'll have a hard time preserving the "with the previous buffer remaining current" requirement throughout the dialog. > On the other hand, if you know of a way to _detect_ such an intention on the > part of the developer, i.e., somehow _detect_ whether the displayed buffer > should have input focus, then I'm all ears. You know that buffers don't have input focus - only frames do, so please keep this distinction alive here. I think we agree that developers leave it to us users to decide whether the buffer is shown in a new or an existing frame. For a use case where the frame of the displayed buffer should have input focus see the `pop-up-frames' non-nil case. > I don't expect that to be possible, which is why I propose that the developer > make the intention explicit by using a new construct (e.g. a macro) that takes > care of this. > > The construct would display the informational buffer and redirect its input > focus to a standalone minibuffer, if there is one. If there is no standalone > minibuffer frame, then that part could be a no-op, AFAICT. We would at least have to make this optional. Users might want to prefer standalone buffers for most of their input but prefer answering the dialogs we talk about here in a minibuffer frame with the list of files being displayed in the same frame. The new option, let's call it `always-redirect-input-to-standalone-minibuffer-frame', if non-nil, could be used by your construct. > Something like this: > > (with-unfocused-buffer-displayed BUFFER &body BODY) > > where BUFFER is displayed for information only, and where BODY would include the > call(s) that read from the minibuffer. > > The current buffer would remain what it was beforehand, and _if_ BUFFER gets > displayed in its own frame and _if_ there is a standalone minibuffer frame, > _then_ the focus for BUFFER's frame gets automatically redirected to the > minibuffer frame. In my experience, this requirement is met if the construct requests input with BUFFER's window temporarily selected and BUFFER temporarily current. Or am I missing something? > If those conditions do not hold then there is no special > handling needed - the construct can essentially be a no-op in that case > (AFAICT). > > How something like this would be implemented I'm not sure. When the redirection > would need to take place, to DTRT, I'm not sure. Perhaps it would need to be > done more than once. > > But an important further requirement is that nothing should prevent Emacs code > in BODY or called from within BODY from switching the input focus to BUFFER's > frame. I don't understand what BODY should contain. Would this macro be responsible for displaying BUFFER? > Likewise, nothing should prevent the user from explicitly switching the > focus to BUFFER's frame. This is part of the `yes-or-no-p' dialog, nothing within the scope of the construct you propose. > The only switching of focus to BUFFER's frame that this construct would be > trying to prevent would be something that comes from neither a user action nor > the Emacs code - in particular, MS Windows auto-focussing a newly created frame. And the only way of "trying to prevent" I can think of is to redirect focus by requesting input from BUFFER's frame. > Again, I don't know the "how". But (so far) I'm convinced that this has to be > an explicit Emacs construct: there needs to be some way for a Lisp programmer to > communicate the intention that BUFFER is not intended to have the input focus ... BUFFER's frame ... > during BODY (unless that is done by the user or by code within BODY). ... during the subsequent reading from the minibuffer. BODY has terminated long ago at that time I suppose. > I do not expect that the problematic use case we've been discussing can be > detected and dealt with correctly in an automatic way. If the programmer > intention Who is the programmer here? > cannot be made explicit then there is no way to know what TRT is. First we have to separate application from user in a clear way. > It's problematic enough even with the intention communicated, in the sense that > we need to allow users and Emacs code to give focus to BUFFER's frame if they > want to. IOW, even if we _know_ that initially BUFFER's frame should not be > focused, it is hard enough to prevent or undo focusing by MS Windows while still > allowing users and Emacs to focus BUFFER. Yes. > That's the point of providing programmers with a construct to express that > intention explicitly: "This buffer's frame, if it is displayed in its own frame, > should not receive the focus." Let's be realistic, programmers won't care. We can only provide a construct that's convenient enough and has been tested in a few model cases like the ones we know of. > By "might pop up" I meant that _if_ informational BUFFER is popped up in its own minibuffer-less > frame, _then_ the intention is that that frame not receive the input focus. > >> > redirecting focus for any new frames to the minibuffer. >> >> And what you have in mind here should be distinguishable from other >> things that pop up frames but do not want the redirection. > > Not sure I follow you. Are you referring to the equivalent of possibly nested > `with-unfocused-buffer-displayed' calls? I refer to the case where a minibuffer-equipped frame is popped up. > Here's the thing. I don't know whether we can come up with something that is > 100% reliable. But the important thing, I think, is to have _some_ programmatic > translation of the programmer intention that this BUFFER be shown without giving > it the input focus. > > Today there is no way for a programmer to indicate that. S?he might not > _expect_ that the focus would be grabbed away from a minibuffer frame and given > to a new frame, but that lack of expectation today is mainly based on > inexperience with a standalone minibuffer and MS Windows. > > What's needed is some way to reinforce the programmer's natural expectation that > the user can in fact type input into the minibuffer even when the informational > buffer gets displayed. > > No one would naturally expect that not to be the case, but it can be the case, > unfortunately. So the idea is to somehow support the natural expectation and > take away the possibility (or reduce the probability) of MS Windows interfering > with what should be a simple user dialog. OK. If you think that the way with-temp-buffer-window.el handles it is not enough, tell me what you would do instead. >> What you want is some clairvoyance in step (1) of my description >> above whether step (2) will be performed. > > No, I don't think so. I don't believe in such clairvoyance (but I'm open to > being convinced). Instead, I believe in the programmer stating that the buffer > is not intended to have the focus. (But that nothing should prevent Emacs or > the user from giving it the focus at some point.) Why don't you code the macro you have in mind so we can discuss it? >> `with-temp-buffer-window' avoids that by asking the `yes-or-no-p' >> question in the new frame. > > The issue at stake is the case of a standalone minibuffer. I don't see any > problem if there is no standalone minibuffer frame. > > With a standalone minibuffer frame, the proper behavior is for the minibuffer > frame to be used for all minibuffer activity. Anything else is less than > desirable, even if it might be acceptable if no better solution could be found > in some case. > > A user of a standalone minibuffer looks there for all echo-area output and all > minibuffer input. That is one of the reasons for using a standalone minibuffer: > a single place where all Q & A with the user takes place. > > Well, nearly all. Yes, there are some times where things like `read-event' are > used instead of the minibuffer. But let's not get pedantic; this is about use > of the minibuffer and echo area. A standalone minibuffer offers the advantage > of always looking to the same place on the screen for user I/O. So let's use an option like `always-redirect-input-to-standalone-minibuffer-frame' and you propose a macro that does what you mean based on that option (I'm afraid I do not understand well what you think that macro's BODY should do). > The other potential trouble is the need to show an informational buffer that > does not necessarily correspond to what you have defined for > `with-temp-buffer-window'. So you think it's too restrictive? > To be clear, I do not know whether such a need exists much in practice. But it > looks to me like your macro and the related code you sent make additional > assumptions about the buffer that is popped up that constrain it more than what > I was describing abstractly for the hypothetical > `with-unfocused-buffer-displayed'. It's a substitute for `with-output-to-temp-buffer' with an additional function that can be used to replace the return value of the former. > The buffer in the case of `with-temp-buffer-window' starts out from scratch (it > must be empty), etc. In a nutshell, your construct assumes that the buffer > itself is temporary, whereas the only real need for our problematic use case is > that the buffer's _display_, in a separate frame, be temporary. The buffer need not be temporary. But in order for quitting to get rid of the frame, the buffer must be killed. > IOW, I think your solution is more constraining/limited and doesn't really > address the general problem, which is that of displaying _any_ buffer for only > informational use (at least initially, allowing for user/code to intentionally > switch focus to it). And AFAIK the problem we are trying to solve occurs only > when such a buffer appears in its own frame. > > Your solution certainly helps for things like *Process List* and *Marked Files*. > But the characterization of the problem is, logically, in terms of a buffer that > is displayed temporarily during a minibuffer dialog, in its own frame, and whose > frame should not have the input focus in that context. > > Am I wrong about that? If you came up with a macro that (approximately) does what you want/need, I probably could answer that question. > Don't get me wrong. I think your code (the little that I've tried using it) is > a definite improvement for the problem cases we've actually encountered, which > are in fact not only temporary displays of a buffer but also displays of a > temporary buffer. > > I'm just saying that I think the problem of MS Windows giving the focus to a new > frame that gets popped during a minibuffer interaction, where that new frame > should not have the focus, i.e., where its buffer is shown only for information, > is more general than the show-a-temporary-buffer case you have treated. > > At least that's what I think so far. You'll tell me if I'm wrong. You might be right. >> It's not that simple. The invoking code doesn't care about focus > > It does care. Maybe what you mean is that it does not expect the focus to be > messed with by MS Windows. The invoking code does not care. It expects `display-buffer' and `yes-or-no-p' to take care of this. > Typically, such code simply does not expect (take into account) a scenario where > the user (a) has a standalone minibuffer frame, (b) has the buffer in question > be popped up in its own frame, and (c) is on MS Windows, which steals the input > focus and gives it to the new frame. > > But the code does expect the minibuffer to have the focus, and it knows that the > buffer is shown only for informational purposes, i.e., the buffer does not need > (and should not have) the input focus. Once more - the code expects the underlying mechanism to handle that. > The code does not, today, explicitly express that intention/care, because > outside of the problematic case of (a), (b), and (c), which today is not that > common, there is no need to express and handle that intention. IOW it cares, > but its cares are already taken care of automatically in most cases. > >> and in particular not about some frame whose eventually popping >> up will cause problems. It expects the reading from the minibuffer >> mechanism DTRT. > > Precisely. And except for the problematic case, there has never been any need > for the programmer to make clear the fact (intention) that the buffer is > informational only. > > You have encapsulated precisely that intention in your code. But you have gone > beyond that and expressed the additional intention that the buffer be temporary. So write a `with-buffer-window' doing things in a non-temporary fashion. The problem is that removing the frame without killing the buffer will be impossible unless we provide yet another option. > And your code in fact does make the distinction between *Process List* and > *Backtrace*, which proves my point here. But your code makes the distinction > based on *Process List* being a temporary buffer (which it is), and not on it > being a buffer that is displayed temporarily in its own frame. > > The latter distinction is I think the right one, and which would be good to > handle. That is where MS Windows's automatic focusing leads to a problem. > > The problematic case is (a) standalone minibuffer (b) popped-up buffer in its > own frame, (c) that frame being new, and (d) the OS giving the new frame the > input focus. You still have to tell me how to remove that frame when you're done. > The second step, I think, would be something similar, but not limited to > temporary buffers. Some way for a programmer to express the intention of > displaying a buffer (temporary or not) only for informational purposes during a > minibuffer interaction. > > And I think that for that more general case, there is a problem to be handled > only when (a) there is a standalone minibuffer frame, (b) the buffer is popped > up in its own frame. Write the macro and we'll see further. martin