[Top][All Lists]

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

bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcall

From: martin rudalics
Subject: bug#11939: 24.1; `save-buffers-kill-emacs'losesminibufferfocuswhenitcalls`list-processes'
Date: Wed, 15 Aug 2012 12:32:34 +0200

>> All I can say is that for me `one-window-p' is much too hard to
>> understand.  I wouldn't use it.  Can't you compare the results of
>> `frame-first-window' and `minibuffer-window' instead?
> Is that sure to DTRT?  If so, fine.  I am not familiar with
> `frame-first-window'.  It was certainly not obvious to me that if those two 
> eq then the frame can only be showing a minibuffer window (no other windows).
> `f-f-w' is written in C, and its definition has changed somewhat over Emacs
> releases.   But if I pass a frame parameter

... frame argument, I suppose ...

> then I guess the different
> definitions should amount to the same thing.  I'll give that a try.

>> Hardly.  Neither of these should affect focus.
> What can I say?  `save-selected-window' sure seems to.

What can I say?  `select-window' ends up calling somewhere
do_switch_frame which has

  if (track && FRAME_WINDOW_P (XFRAME (frame)))
      Lisp_Object focus, xfocus;

      xfocus = x_get_focus_frame (XFRAME (frame));
      if (FRAMEP (xfocus))
          focus = FRAME_FOCUS_FRAME (XFRAME (xfocus));
          if (FRAMEP (focus) && XFRAME (focus) == SELECTED_FRAME ())
            Fredirect_frame_focus (xfocus, frame);
#endif /* HAVE_X_WINDOWS */

which _apparently_ directs focus away from one of your frames when it's
called for the first time and does not direct focus back to that frame
when it's called for the second time.  If you (like me) do not
understand why and how such a thing happens, you maybe understand why
I propose to side-step `select-window' in the first place.

>> No.  All I can say is that manually selecting the
>> `minibuffer-window' seems harmful.
> FWIW, I have not encountered any bugs selecting it

Maybe because in all other cases you explicitly wanted to select it (not
just temporarily/implicitly).

> (whatever you might mean by
> "manually"),

By "manually" I mean that you "explicitly" select it.  I always leave it
to Emacs to select the minibuffer window.

>>  > You seem to be saying that Emacs has introduced bugs, and
>>  > nothing more.
>> Where did I say that?
> In the text you snipped, just before that sentence of mine:
>>> I can't explain any of these.  In the past, I tried to
>>> make most window functions work on any window/frame to
>>> work independently from the selected window.  Earlier,
>>> selecting a window must have been a very simple procedure.
>>>  Nowadays, this incurs so many side-effects in the
>>> window/frame/display area that you should
>>> try to avoid `select-window' wherever possible.
> And by "nothing more" I meant no more explanation: your "I can't explain any 
> these".

The fact that I can't explain something means just that: I'm too silly
to comprehend what's going on - but not that Emacs has introduced any
bugs.  Meanwhile Emacs has to interact with too many different operating
systems and window managers, in particular when multiple frames are

>> IIUC all Emacs version behave the same wrt your
>> scenario.
> Correct.  It is you who suggested that selecting a window used to be simpler
> than now,

... because people working with a different OS want Emacs to DTRT on
their OS and selecting a window which implicitly selects a frame had to
cope with their needs ...

> and that now it has "many" side effects - so much so that you advise
> people to avoid `select-window'.  My finding was that the 
> changes-the-focus bug is present in all Emacs releases (20 through 24).

... and to solve this we probably have to add another twist as soon as
someone is able to understand and resolve this particular issue ...

> It was not obvious to me that `frame-first-window' could be used to test for
> only-one-window-ness, or that the doc prior to Emacs 24 for `one-window-p' was
> not correct wrt a frame argument.  Your simplifications are welcome, but they
> were far from obvious, to me.

To me as well.  I tried to find out which function was present in early
Emacsen and whether it could DTRT (in principle).


reply via email to

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