bug#36894: Stability issues in frameset sorting

bug#36894: Stability issues in frameset sorting

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

Tags: patch

Currently frameset sorting is not stable.  It changes the sorting order of equal
minibuffer-owning frames.  On closer inspection it becomes clear that
frameset--mini parameters are messed up in 'frameset--minibufferless-last-p'.
This patch should fix it:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: frameset--minibufferless-last-p.patch --]
[-- Type: text/x-diff, Size: 756 bytes --]

diff --git a/lisp/frameset.el b/lisp/frameset.el
index 73b2071a5a..0d921421ad 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -1102,8 +1104,8 @@ frameset--minibufferless-last-p
   "Predicate to sort frame states in an order suitable for creating frames.
 It sorts minibuffer-owning frames before minibufferless ones.
 Internal use only."
-  (pcase-let ((`(,hasmini1 ,id-def1) (assq 'frameset--mini (car state1)))
-	      (`(,hasmini2 ,id-def2) (assq 'frameset--mini (car state2))))
+  (pcase-let ((`(,hasmini1 . ,id-def1) (cdr (assq 'frameset--mini (car state1))))
+	      (`(,hasmini2 . ,id-def2) (cdr (assq 'frameset--mini (car state2)))))
     (cond ((eq id-def1 t) t)
 	  ((eq id-def2 t) nil)
 	  ((not (eq hasmini1 hasmini2)) (eq hasmini1 t))

bug#36894: Stability issues in frameset sorting

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

> Currently frameset sorting is not stable.  It changes the sorting order of equal
> minibuffer-owning frames.  On closer inspection it becomes clear that
> frameset--mini parameters are messed up in 'frameset--minibufferless-last-p'.
> This patch should fix it:

Pushed to master.

Now one problem still remains: the desktop file doesn't restore the
selected frame, i.e. after restoring frames from the desktop file,
the selected frame is not the same as was before saving the desktop.
This patch ensures that the previously selected frame is restored last,
thus becoming selected again:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: frameset--minibufferless-last-p.last-focus-update.patch --]
[-- Type: text/x-diff, Size: 759 bytes --]

diff --git a/lisp/frameset.el b/lisp/frameset.el
index a8b16706c2..8e69bfb499 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -1104,7 +1106,9 @@ frameset--minibufferless-last-p
 Internal use only."
   (pcase-let ((`(,hasmini1 . ,id-def1) (cdr (assq 'frameset--mini (car state1))))
 	      (`(,hasmini2 . ,id-def2) (cdr (assq 'frameset--mini (car state2)))))
-    (cond ((eq id-def1 t) t)
+    (cond ((and (eq hasmini1 t) (eq hasmini2 t) (eq (cdr (assq 'last-focus-update (car state1))) t)) nil)
+          ((and (eq hasmini1 t) (eq hasmini2 t) (eq (cdr (assq 'last-focus-update (car state2))) t)) t)
+          ((eq id-def1 t) t)
 	  ((eq id-def2 t) nil)
 	  ((not (eq hasmini1 hasmini2)) (eq hasmini1 t))
 	  ((eq hasmini1 nil) (or id-def1 id-def2))

bug#36894: Stability issues in frameset sorting

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 06 Aug 2019 00:17:32 +0300
> 
> Now one problem still remains: the desktop file doesn't restore the
> selected frame, i.e. after restoring frames from the desktop file,
> the selected frame is not the same as was before saving the desktop.
> This patch ensures that the previously selected frame is restored last,
> thus becoming selected again:

Is this really necessary?  IME, the selected frame does get restored,
so I'm not sure why it doesn't work for you.

I'm wary of changing the order of restoring frames from what Emacs
does now, because this could have adverse effects on some settings
that are related to restoring frame dimensions.

bug#36894: Stability issues in frameset sorting

[Juri Linkov]

>> Now one problem still remains: the desktop file doesn't restore the
>> selected frame, i.e. after restoring frames from the desktop file,
>> the selected frame is not the same as was before saving the desktop.
>> This patch ensures that the previously selected frame is restored last,
>> thus becoming selected again:
>
> Is this really necessary?  IME, the selected frame does get restored,
> so I'm not sure why it doesn't work for you.

Currently the desktop doesn't restore focus to the previously selected frame.

> I'm wary of changing the order of restoring frames from what Emacs
> does now, because this could have adverse effects on some settings
> that are related to restoring frame dimensions.

I doubt that fixing would have any effect because for many years
the order was completely broken, and no one complained
(I can speak only for myself why I haven't complained until now -
every time the desktop restored focus to wrong frame,
it was easier to switch to the previously selected frame
manually than to debug the problem).

bug#36894: Stability issues in frameset sorting

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 36894@debbugs.gnu.org
> Date: Wed, 07 Aug 2019 01:09:49 +0300
> 
> >> Now one problem still remains: the desktop file doesn't restore the
> >> selected frame, i.e. after restoring frames from the desktop file,
> >> the selected frame is not the same as was before saving the desktop.
> >> This patch ensures that the previously selected frame is restored last,
> >> thus becoming selected again:
> >
> > Is this really necessary?  IME, the selected frame does get restored,
> > so I'm not sure why it doesn't work for you.
> 
> Currently the desktop doesn't restore focus to the previously selected frame.

Is this new in Emacs 27?  Because I see no such problem in Emacs 26,
where I use desktop all the time with multi-frame arrangements.

bug#36894: Stability issues in frameset sorting

[Juri Linkov]

>> Currently the desktop doesn't restore focus to the previously selected frame.
>
> Is this new in Emacs 27?  Because I see no such problem in Emacs 26,
> where I use desktop all the time with multi-frame arrangements.

I tried to load in Emacs 26 the desktop created in Emacs 27,
but it crashed with this backtrace:

  emacs_backtrace at emacs/src/sysdep.c:2413
  terminate_due_to_signal at emacs/src/emacs.c:383
  handle_fatal_signal at emacs/src/sysdep.c:1769
  deliver_thread_signal at emacs/src/sysdep.c:1733
  stack_overflow at emacs/src/sysdep.c:1819
   (inlined by) handle_sigsegv at emacs/src/sysdep.c:1862
  ?? ??:0
  ?? ??:0
  xftfont_encode_char at emacs/src/xftfont.c:557
  get_char_glyph_code at emacs/src/xdisp.c:25797
   (inlined by) x_produce_glyphs at emacs/src/xdisp.c:28169
  produce_special_glyphs at emacs/src/xdisp.c:27805 (discriminator 9)
  init_iterator at emacs/src/xdisp.c:2945
  resize_mini_window at emacs/src/xdisp.c:11278
  display_echo_area_1 at emacs/src/xdisp.c:11175
  with_echo_area_buffer at emacs/src/xdisp.c:10955
  display_echo_area at emacs/src/xdisp.c:11142
   (inlined by) echo_area_display at emacs/src/xdisp.c:11647
  message3_nolog at emacs/src/xdisp.c:10653
  message3 at emacs/src/xdisp.c:10582
  Fmessage at emacs/src/editfns.c:4029
  Ffuncall at emacs/src/eval.c:2773
  exec_byte_code at emacs/src/bytecode.c:630
  Ffuncall at emacs/src/eval.c:2798
  Fapply at emacs/src/eval.c:2395
  apply1 at emacs/src/eval.c:2610
  call_debugger at emacs/src/eval.c:345
  signal_or_quit at emacs/src/eval.c:1617
  Fsignal at emacs/src/eval.c:1518
  xsignal1 at emacs/src/lisp.h:3854
  verror at emacs/src/eval.c:1840
  error at emacs/src/eval.c:1852
  x_set_font at emacs/src/frame.c:4262
  x_set_font_backend at emacs/src/frame.c:4396
  x_set_frame_parameters at emacs/src/frame.c:3913
  Fmodify_frame_parameters at emacs/src/frame.c:3177
  funcall_subr at emacs/src/eval.c:2850
  Ffuncall at emacs/src/eval.c:2773
  exec_byte_code at emacs/src/bytecode.c:630
  Ffuncall at emacs/src/eval.c:2798
  exec_byte_code at emacs/src/bytecode.c:630
  Ffuncall at emacs/src/eval.c:2798
  exec_byte_code at emacs/src/bytecode.c:630
  Ffuncall at emacs/src/eval.c:2798

Then replaced (font-backend xfthb x) with (font-backend xft x)
in the desktop file, after that it didn't crash, but raised
the error: (wrong-number-of-arguments #<subr set-window-fringes> 5)

Then replaced (fringes 8 8 nil nil) with (fringes 8 8 nil)
but it messed the monitors - restored frames in opposite monitors.

Then created a completely new desktop in Emacs 26,
but it didn't restore focus in the frame where it previously was.

And I don't see how Emacs 26 could restore focus,
because there is no 'last-focus-update' frame parameter in Emacs 26.
'last-focus-update' was added recently in Emacs 27.
So this is a new feature that we could use now in the desktop
to restore focus in the same frame where it was before.

> I'm wary of changing the order of restoring frames from what Emacs
> does now, because this could have adverse effects on some settings
> that are related to restoring frame dimensions.

I agree, looking at frameset--minibufferless-last-p it's difficult
to understand its logic, so I added comments to it.

Before my previous fix, despite the bug, the sorting order
was almost like intended in most cases: it still sorted
all minibuffer-owning frames before minibufferless.

Now I added more comments to explain the logic:

  (pcase-let ((`(,hasmini1 . ,id-def1) (cdr (assq 'frameset--mini (car state1))))
	      (`(,hasmini2 . ,id-def2) (cdr (assq 'frameset--mini (car state2)))))
    ;; hasmini1 is t when 1st frame has its own minibuffer
    ;; hasmini2 is t when 2nd frame has its own minibuffer
    ;; id-def1 is t when 1st minibuffer-owning frame is the default-minibuffer-frame
    ;;         or frame-id of 1st frame if it's minibufferless
    ;; id-def2 is t when 2nd minibuffer-owning frame is the default-minibuffer-frame
    ;;         or frame-id of 2nd frame if it's minibufferless
    (cond ;; Sort the minibuffer-owning default-minibuffer-frame first
	  ((eq id-def1 t) t)
	  ((eq id-def2 t) nil)
	  ;; Sort non-default minibuffer-owning frames before minibufferless
	  ((not (eq hasmini1 hasmini2)) (eq hasmini1 t)) ;; boolean xor
	  ;; Sort minibufferless frames with frame-id before some remaining
	  ((eq hasmini1 nil) (or id-def1 id-def2))
	  (t t)))

This shows that the intention was to restore minibuffer-owning frames before
minibufferless, and I agree that better not to change the sorting order,
because the last-selected frame might be the default-minibuffer-frame
(used by minibufferless frames) that should be created first.

So as a better solution we could restore the focus explicitly
after all frames are created.

bug#36894: Stability issues in frameset sorting

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 36894@debbugs.gnu.org
> Date: Fri, 09 Aug 2019 21:09:17 +0300
> 
> Then created a completely new desktop in Emacs 26,
> but it didn't restore focus in the frame where it previously was.
> 
> And I don't see how Emacs 26 could restore focus,

Well, it does for me, and I think that's because the order of saving
the frames is such that the selected frame is saved last (and thus
restored last).

> 'last-focus-update' was added recently in Emacs 27.

How is that relevant?

> So this is a new feature that we could use now in the desktop
> to restore focus in the same frame where it was before.

Selected frame and frame that has focus is not the same thing,
definitely not with an arbitrary window-manager.

But I asked for a reproducible recipe, and I don't think you have
shown one.  Could you please do that?  I'd like to study it.

Thanks.

bug#36894: Restore frameset focus and selectedness

[Juri Linkov]

retitle 36894 Restore frameset focus and selectedness
thanks

>> Then created a completely new desktop in Emacs 26,
>> but it didn't restore focus in the frame where it previously was.
>>
>> And I don't see how Emacs 26 could restore focus,
>
> Well, it does for me, and I think that's because the order of saving
> the frames is such that the selected frame is saved last (and thus
> restored last).
>
>> 'last-focus-update' was added recently in Emacs 27.
>
> How is that relevant?

'last-focus-update' could be used to put focus back to the same frame
where it was before saving the desktop.

>> So this is a new feature that we could use now in the desktop
>> to restore focus in the same frame where it was before.
>
> Selected frame and frame that has focus is not the same thing,
> definitely not with an arbitrary window-manager.

Maybe then the desktop should save the selectedness as well.
I see some ‘(selected . t)’ in the desktop, but it seems
these indicate the selected buffer, not frame.

> But I asked for a reproducible recipe, and I don't think you have
> shown one.  Could you please do that?  I'd like to study it.

In your case above, if you save the frames is such order that
the selected frame is not saved last, can you reproduce the problem?
I see this problem often when the last frame is not selected.

bug#36894: Restore frameset focus and selectedness

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 36894@debbugs.gnu.org
> Date: Sun, 11 Aug 2019 23:51:54 +0300
> 
> >> 'last-focus-update' was added recently in Emacs 27.
> >
> > How is that relevant?
> 
> 'last-focus-update' could be used to put focus back to the same frame
> where it was before saving the desktop.
> 
> >> So this is a new feature that we could use now in the desktop
> >> to restore focus in the same frame where it was before.
> >
> > Selected frame and frame that has focus is not the same thing,
> > definitely not with an arbitrary window-manager.
> 
> Maybe then the desktop should save the selectedness as well.

You mean, restore last-focus-update?  If you add it to
desktop-globals-to-save, is it restored?

> > But I asked for a reproducible recipe, and I don't think you have
> > shown one.  Could you please do that?  I'd like to study it.
> 
> In your case above, if you save the frames is such order that
> the selected frame is not saved last, can you reproduce the problem?
> I see this problem often when the last frame is not selected.

How can this happen?  In my use, desktop is saved when I kill Emacs,
and in that case the selected frame is always the last one saved.

That's hwy I asked for a reproducible recipe: I think there are some
factors at work on your system which I don't understand.

bug#36894: Restore frameset focus and selectedness

[Juri Linkov]

>> Maybe then the desktop should save the selectedness as well.
>
> You mean, restore last-focus-update?  If you add it to
> desktop-globals-to-save, is it restored?

'last-focus-update' is a frame parameter saved in 'desktop-saved-frameset'.

>> > But I asked for a reproducible recipe, and I don't think you have
>> > shown one.  Could you please do that?  I'd like to study it.
>> 
>> In your case above, if you save the frames is such order that
>> the selected frame is not saved last, can you reproduce the problem?
>> I see this problem often when the last frame is not selected.
>
> How can this happen?  In my use, desktop is saved when I kill Emacs,
> and in that case the selected frame is always the last one saved.
>
> That's hwy I asked for a reproducible recipe: I think there are some
> factors at work on your system which I don't understand.

Indeed something strange happens, here is a complete recipe:

0. emacs -Q
1. C-h C-t   (view-emacs-todo)
2. C-x 5 2   (make-frame-command)
3. C-h C-n   (view-emacs-news)
4. C-x 5 o   (other-frame)
5. M-x desktop-save RET RET
6. C-x C-c

7. emacs -Q -f desktop-read --eval '(message "selected-frame: %S" (selected-frame))'
8. M-: (selected-frame) RET

9. In the *Messages* buffer the printed selected-frame is not the same.
   See more explanations of messages in the *Messages* buffer below:

The next message comes from 'message' added to frameset.el:
frameset-restore frame-list: (#<frame emacs@localhost 0x5572e78000c0> #<frame emacs@localhost 0x5572e71a9eb0>)

The next message comes from 'message' added to frameset.el:
frameset-restore selected-frame: #<frame emacs@localhost 0x5572e71a9eb0>

The next message comes from desktop.el:
Desktop: 2 frames, 2 buffers restored.

The next message comes from 'message' added to desktop.el:
desktop-read selected-frame: #<frame TODO 0x5572e71a9eb0>

The next message comes from 'message' on the command line:
selected-frame: #<frame TODO 0x5572e71a9eb0>

The next message comes from 'message' added to startup.el:
normal-top-level selected-frame: #<frame TODO 0x5572e71a9eb0>

The next message comes from M-: (selected-frame)
#<frame  *Minibuf-1* 0x5572e78000c0>

Here 0x5572e71a9eb0 is the frame with TODO, and 0x5572e78000c0 with NEWS.
(0x5572e71a9eb0 was reused, but 0x5572e78000c0 is a new frame created by frameset-restore)
After loading the former should be selected, but actually the latter is selected.

The 'message' added at the end of 'normal-top-level' shows one value
of selected-frame, but evaluating M-: (selected-frame) immediately after loading
shows another value of selected-frame.

Conclusion:
The window manager always selects the last created frame, i.e.
it seems it's impossible to create a new frame without selecting it.

Here is complete information:

In GNU Emacs 27.0.50 (build 84, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
 of 2019-08-13 built on localhost
Repository revision: 2b329ed420eb15f6738edd402697ac2876b2aa61
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11906000
System Description: Linux Mint 19.1

Configured using:
 'configure --with-imagemagick'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT
LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS PDUMPER
LCMS2 GMP

Important settings:
  value of $LC_MONETARY: fi_FI.UTF-8
  value of $LC_NUMERIC: fi_FI.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Outline

Minor modes in effect:
  bug-reference-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t
  view-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils cl-seq cl-extra
help-mode time-date subr-x goto-addr thingatpt seq byte-opt gv bytecomp
byte-compile cconv view vc-git diff-mode easymenu bug-reference noutline
outline easy-mmode desktop frameset cl-loaddefs cl-lib tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win
x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 55782 4941)
 (symbols 48 7047 1)
 (strings 32 19182 1991)
 (string-bytes 1 619171)
 (vectors 16 11862)
 (vector-slots 8 157169 9776)
 (floats 8 36 26)
 (intervals 56 229 0)
 (buffers 992 13))

bug#36894: Restore frameset focus and selectedness

[martin rudalics]

 > The window manager always selects the last created frame, i.e.
 > it seems it's impossible to create a new frame without selecting it.

The xfce window manager has an option for whether a new window should
be automatically given focus or not.

martin

bug#36894: Restore frameset focus and selectedness

[Eli Zaretskii]

> Cc: 36894@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Wed, 14 Aug 2019 10:58:47 +0200
> 
>  > The window manager always selects the last created frame, i.e.
>  > it seems it's impossible to create a new frame without selecting it.
> 
> The xfce window manager has an option for whether a new window should
> be automatically given focus or not.

I'm not sure I understand what you both are saying.  Are you saying
that this problem is impossible to solve in Emacs?

bug#36894: Restore frameset focus and selectedness

[Juri Linkov]

>> The window manager always selects the last created frame, i.e.
>> it seems it's impossible to create a new frame without selecting it.
>
> The xfce window manager has an option for whether a new window should
> be automatically given focus or not.

Actually I use the MATE window manager.  I don't know why the output of
report-emacs-bug I sent in the previous message doesn't include information
about the window manager, I see several ENV variables with this name,
maybe report-emacs-bug should include one of them:

  DESKTOP_SESSION=mate
  GDMSESSION=mate
  XDG_CURRENT_DESKTOP=MATE
  XDG_SESSION_DESKTOP=mate

And I can't find such a focus-related option in the MATE window manager.

bug#36894: Restore frameset focus and selectedness

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 431 bytes --]

>>  > The window manager always selects the last created frame, i.e.
>>  > it seems it's impossible to create a new frame without selecting it.
>> 
>> The xfce window manager has an option for whether a new window should
>> be automatically given focus or not.
>
> I'm not sure I understand what you both are saying.  Are you saying
> that this problem is impossible to solve in Emacs?

The problem can be solved with this patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: frameset-restore-last-focus-frame.patch --]
[-- Type: text/x-diff, Size: 782 bytes --]

diff --git a/lisp/frameset.el b/lisp/frameset.el
index 60b6fe38ad..4f7800630c 100644
--- a/lisp/frameset.el
+++ b/lisp/frameset.el
@@ -1346,6 +1352,16 @@ frameset-restore
 	    (error
 	     (delay-warning 'frameset (error-message-string err) :warning))))))
 
+    ;; Make sure the last selected frame has focus.
+    (let ((last-focus-frame
+           (catch 'last-focus
+             (maphash (lambda (frame _)
+                        (when (frame-parameter frame 'last-focus-update)
+                          (throw 'last-focus frame)))
+                      frameset--action-map))))
+      (when last-focus-frame
+        (select-frame-set-input-focus last-focus-frame)))
+
     ;; Make sure there's at least one visible frame.
     (unless (or (daemonp)
 		(catch 'visible

bug#36894: Restore frameset focus and selectedness

[martin rudalics]

 > I'm not sure I understand what you both are saying.  Are you saying
 > that this problem is impossible to solve in Emacs?

If the window manager doesn't comply or is set up "wrongly", yes.
Focus stealing cannot be handled by the application alone.  But if the
window manager is compliant, setting the 'no-focus-on-map' frame
parameter should handle the problem.

martin

bug#36894: Restore frameset focus and selectedness

[Juri Linkov]

> If the window manager doesn't comply or is set up "wrongly", yes.
> Focus stealing cannot be handled by the application alone.  But if the
> window manager is compliant, setting the 'no-focus-on-map' frame
> parameter should handle the problem.

I see that the MATE window manager doesn't select the new frame after

  (make-frame '((no-focus-on-map . t)))

Then I don't understand the logic of make-frame-command:

  (defun make-frame-command ()
    (interactive)
    (if (display-graphic-p)
        (make-frame)
      (select-frame (make-frame))))

On a graphic display it doesn't select the new frame explicitly,
maybe on the assumption that all window managers should select it
afterwards?

bug#36894: Restore frameset focus and selectedness

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  36894@debbugs.gnu.org
> Date: Thu, 15 Aug 2019 21:36:33 +0300
> 
> Then I don't understand the logic of make-frame-command:
> 
>   (defun make-frame-command ()
>     (interactive)
>     (if (display-graphic-p)
>         (make-frame)
>       (select-frame (make-frame))))
> 
> On a graphic display it doesn't select the new frame explicitly,
> maybe on the assumption that all window managers should select it
> afterwards?

On a TTY, if you don't select the new frame, it is invisible.  On a
GUI display, the new frame is visible, so there's no need to
explicitly select it, because no one said the user wants the new frame
become selected.

bug#36894: Restore frameset focus and selectedness

[martin rudalics]

 > I see that the MATE window manager doesn't select the new frame after
 >
 >    (make-frame '((no-focus-on-map . t)))
 >
 > Then I don't understand the logic of make-frame-command:
 >
 >    (defun make-frame-command ()
 >      (interactive)
 >      (if (display-graphic-p)
 >          (make-frame)
 >        (select-frame (make-frame))))
 >
 > On a graphic display it doesn't select the new frame explicitly,
 > maybe on the assumption that all window managers should select it
 > afterwards?

IIUC it intentionally doesn't care and doesn't make any guarantees.
See the info on 'make-frame':

      This function itself does not make the new frame the selected
      frame.  *Note Input Focus::.  The previously selected frame remains
      selected.  On graphical terminals, however, the windowing system
      may select the new frame for its own reasons.

martin

bug#36894: Restore frameset focus and selectedness

[Eli Zaretskii]

> Cc: juri@linkov.net, 36894@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 15 Aug 2019 10:12:17 +0200
> 
>  > I'm not sure I understand what you both are saying.  Are you saying
>  > that this problem is impossible to solve in Emacs?
> 
> If the window manager doesn't comply or is set up "wrongly", yes.
> Focus stealing cannot be handled by the application alone.  But if the
> window manager is compliant, setting the 'no-focus-on-map' frame
> parameter should handle the problem.

Juri suggested a patch.  Are you okay with it, or are you saying that
it will still fail in some situations?

Thanks.

bug#36894: Restore frameset focus and selectedness

[martin rudalics]

 > Juri suggested a patch.  Are you okay with it,

Okay with it.  It should not make things worse.

 > or are you saying that
 > it will still fail in some situations?

Focus related problems are generally unpredictable.  Each window
manager under GNU/Linux and each Windows version introduces its own
ones.  Just for example, here on Windows 10 it's so far completely
incomprehensible for me to tell whether a window A hidden by a window
B will get focus when B is deleted.

martin

bug#36894: Restore frameset focus and selectedness

[Eli Zaretskii]

> Cc: juri@linkov.net, 36894@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Sat, 17 Aug 2019 10:24:52 +0200
> 
>  > Juri suggested a patch.  Are you okay with it,
> 
> Okay with it.  It should not make things worse.

Thanks.  Juri, please go ahead and push.

>  > or are you saying that
>  > it will still fail in some situations?
> 
> Focus related problems are generally unpredictable.  Each window
> manager under GNU/Linux and each Windows version introduces its own
> ones.  Just for example, here on Windows 10 it's so far completely
> incomprehensible for me to tell whether a window A hidden by a window
> B will get focus when B is deleted.

I guess you are saying that even after this fix thisissue will never
be solved 100%.

bug#36894: Restore frameset focus and selectedness

[Juri Linkov]

tags 36894 + fixed
close 36894 27.0.50
quit

>>  > Juri suggested a patch.  Are you okay with it,
>>
>> Okay with it.  It should not make things worse.
>
> Thanks.  Juri, please go ahead and push.

Done.  Hope it makes things better in more cases than worse.

bug#36894: Restore frameset focus and selectedness

[martin rudalics]

 > I guess you are saying that even after this fix thisissue will never
 > be solved 100%.

You guess right.

martin