From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Date: Tue, 03 May 2022 21:28:51 +0300 Message-ID: <83fslq4gik.fsf@gnu.org> References: <83fsm4pbs4.fsf@gnu.org> <6961B895-263C-4632-AA4E-8DE29D6160BC@swenson.org> <83sfq3op15.fsf@gnu.org> <86wnfcxnvf.fsf@mail.linkov.net> <87mtg8i1za.fsf@gnus.org> <86h76fu9q5.fsf@mail.linkov.net> <83r15jltce.fsf@gnu.org> <86sfpzspz4.fsf@mail.linkov.net> <83o80nlnjm.fsf@gnu.org> <86fslysc14.fsf@mail.linkov.net> <19755688-1BC3-45A0-854D-031469E50DB9@swenson.org> <861qxhy9cz.fsf@mail.linkov.net> <5DA5751F-DC2F-4C40-AE30-DAF65BCF0572@swenson.org> <86a6c56ra5.fsf@mail.linkov.net> <83wnf77yii.fsf@gnu.org> <86wnf5f8of.fsf@mail.linkov.net> <83levi4lyy.fsf@gnu.org> <86pmkufql3.fsf@mail.linkov.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23839"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue May 03 20:29:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nlxGo-00062R-SN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 May 2022 20:29:11 +0200 Original-Received: from localhost ([::1]:33582 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nlxGn-0004p9-6Z for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 03 May 2022 14:29:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47302) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlxGf-0004mE-UP for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 14:29:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:47127) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nlxGf-00048X-LV for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 14:29:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nlxGf-0002aC-Ip for bug-gnu-emacs@gnu.org; Tue, 03 May 2022 14:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 03 May 2022 18:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55070 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo patch Original-Received: via spool by 55070-submit@debbugs.gnu.org id=B55070.16516025309909 (code B ref 55070); Tue, 03 May 2022 18:29:01 +0000 Original-Received: (at 55070) by debbugs.gnu.org; 3 May 2022 18:28:50 +0000 Original-Received: from localhost ([127.0.0.1]:41024 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlxGU-0002Zl-1M for submit@debbugs.gnu.org; Tue, 03 May 2022 14:28:50 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlxGS-0002ZW-DM for 55070@debbugs.gnu.org; Tue, 03 May 2022 14:28:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35216) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlxGM-00046k-He; Tue, 03 May 2022 14:28:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CB129gQ1pWXUe3tAf/cmvaoRIv7Gvq9EMcyonvbm1ik=; b=d7r4uYeMVE91 AHBwxOe1R+D482QFGsEKrOkPW+mupR/HReKq4OwIFkez1xWRupiMYCtwc2uaiWku/7TtEST30WjJR OafFLzWHChm7HB/w+L8GVv8ov6xuNkqPygm3Va9rqXYFiXCQ0li93iSxROyovis1+TNe70y9qTRnm 4nbzBi56i+leYwSi05qwvaNEdENEXcktiqRLtomj8il8xNdXxJDqnHv0slbPRwkGQz4+7azd3bWox epaZuy4ywKlB6PgNkg7fnwMIzP3R6hmoBWPngQ7TgUCnhoPV4oOdaCqCQNC5erkb94oHlHtd1dLiN veAlkjvc241u+U6orcDtrw==; Original-Received: from [87.69.77.57] (port=4185 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlxGK-0002Eb-Cu; Tue, 03 May 2022 14:28:41 -0400 In-Reply-To: <86pmkufql3.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 03 May 2022 20:57:52 +0300) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:231357 Archived-At: > From: Juri Linkov > Cc: eric@swenson.org, larsi@gnus.org, 55070@debbugs.gnu.org > Date: Tue, 03 May 2022 20:57:52 +0300 > > > I think this means we cannot save and restore tab-bar-mode by relying > > on the tab-bar-lines frame parameter; the solution should be in a > > special support for desktop.el in tab-bar.el. For example, remove the > > tab-bar-line frame parameter when saving the desktop, and instead save > > the tab-bar-mode state; then restoring the desktop would turn on > > tab-bar-mode in the restored session, and recreate the tab bar of the > > desired height. > > Agreed. Although currently I have no idea how to do this without adding > direct calls of tab-bar.el functions in desktop.el. It isn't a crime. It is also not a catastrophe to have in desktop.el code that knows something about tab-bar.el's code. We already have such code in desktop.el that knows something about some minor modes. > > I hope you can develop such a solution, so that tab bars could be > > meaningfully restored on TTY frames. > > Such a solution is also needed for GUI frames as well, because > when tab-bar-mode is not enabled explicitly, then after restoring > the desktop with tab-bar-line frame parameters, tab buttons are too ugly. > The graphical versions of these buttons are created only when > tab-bar-mode is enabled on a GUI frame. So desktop.el should > enable tab-bar-mode somehow. Yes, what I proposed will work for any kind of frame, because tab-bar-mode calculates the metrics of the tab bar, so doesn't need it to be already calculated in advance. > > Btw, what about tab-bar-show -- should it be saved as well? at least > > if its value is not the default? > > tab-bar-lines are updated according to the value of tab-bar-show > in tab-bar--update-tab-bar-lines (called from tab-bar-mode). Yes, but what about future frames? The use case is: the user restores a session from desktop file, then proceeds creating new frames with tab bars of different numbers of tabs. We'd want tab-bar-show to be restored from the desktop as well, so that the tab bars on the new frames behave the same as the user defined in the session that was restored, no? > But this raises another question: when the user changes the value > of tab-bar-show, should desktop.el show the tab bar exactly as saved, > or should it update the tab bar according to the new value of tab-bar-show > immediately after restoring the desktop? I think the idea always was that restoring desktop overrides any local changes of the saved variables. Users that want it the other way around should edit their init files to move the desktop restoration code before the code which modifies the variables which could be restored. I think.