From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#36894: Stability issues in frameset sorting Date: Fri, 09 Aug 2019 21:09:17 +0300 Organization: LINKOV.NET Message-ID: <87h86q8b3m.fsf@mail.linkov.net> References: <878sscwovy.fsf@mail.linkov.net> <877e7rwbv7.fsf@mail.linkov.net> <834l2uconb.fsf@gnu.org> <874l2uug62.fsf@mail.linkov.net> <83y305btde.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="44364"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 36894@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 09 20:11:27 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hw9MM-000BQv-O8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2019 20:11:27 +0200 Original-Received: from localhost ([::1]:33318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hw9ML-0001Do-Q4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Aug 2019 14:11:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45964) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hw9M0-0000sD-HA for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2019 14:11:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hw9Ly-0003FQ-Hf for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2019 14:11:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34423) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hw9Ly-0003FJ-DU for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2019 14:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hw9Ly-0007xd-7R for bug-gnu-emacs@gnu.org; Fri, 09 Aug 2019 14:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Aug 2019 18:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36894 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 36894-submit@debbugs.gnu.org id=B36894.156537423330546 (code B ref 36894); Fri, 09 Aug 2019 18:11:02 +0000 Original-Received: (at 36894) by debbugs.gnu.org; 9 Aug 2019 18:10:33 +0000 Original-Received: from localhost ([127.0.0.1]:43242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hw9LU-0007wb-IS for submit@debbugs.gnu.org; Fri, 09 Aug 2019 14:10:32 -0400 Original-Received: from bumble.birch.relay.mailchannels.net ([23.83.209.25]:31041) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hw9LQ-0007wK-36 for 36894@debbugs.gnu.org; Fri, 09 Aug 2019 14:10:28 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E9CB150285C; Fri, 9 Aug 2019 18:10:26 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a11.g.dreamhost.com (100-96-148-111.trex.outbound.svc.cluster.local [100.96.148.111]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5A9135027E8; Fri, 9 Aug 2019 18:10:26 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a11.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.5); Fri, 09 Aug 2019 18:10:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Bottle-Versed: 727fe94808c750b3_1565374226627_4252415203 X-MC-Loop-Signature: 1565374226626:130496572 X-MC-Ingress-Time: 1565374226626 Original-Received: from pdx1-sub0-mail-a11.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTP id 3467D83527; Fri, 9 Aug 2019 11:10:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=pJ5dfCrxHf6eIjinS+1pdjRKn+Q=; b= ZPlfsksBNe610uvCboicZ59DJbPiCsjkc/kgXxo6vS2cJcaaMpCocLFgKyYtRF5q +ZS65yAoZ6gQfaVwJxdLakGZmrPP1g2gJ+UJC4ueCCN8MagjJWlwzBjms+VF+Nfn Ne3qtPZpIOmtk0xu31QKbzXNR3LNKqC2zeYpCvvwr34= Original-Received: from mail.jurta.org (m91-129-103-91.cust.tele2.ee [91.129.103.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTPSA id 8F48E8360A; Fri, 9 Aug 2019 11:10:22 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a11 In-Reply-To: <83y305btde.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 07 Aug 2019 05:29:33 +0300") X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddruddujedguddvudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledruddtfedrledunecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledruddtfedrledupdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepvghlihiisehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptd X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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" Xref: news.gmane.org gmane.emacs.bugs:164814 Archived-At: >> 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 # 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.