From unknown Fri Aug 15 03:57:33 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#55070 <55070@debbugs.gnu.org> To: bug#55070 <55070@debbugs.gnu.org> Subject: Status: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Reply-To: bug#55070 <55070@debbugs.gnu.org> Date: Fri, 15 Aug 2025 10:57:33 +0000 retitle 55070 28.1; desktop-load doesn't work in -nw (non-gui) emacs reassign 55070 emacs submitter 55070 Eric Swenson severity 55070 normal tag 55070 moreinfo patch thanks From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 22 19:59:13 2022 Received: (at submit) by debbugs.gnu.org; 22 Apr 2022 23:59:13 +0000 Received: from localhost ([127.0.0.1]:54855 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ni3B4-0002k7-Rk for submit@debbugs.gnu.org; Fri, 22 Apr 2022 19:59:13 -0400 Received: from lists.gnu.org ([209.51.188.17]:35256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ni2gt-0001h5-4x for submit@debbugs.gnu.org; Fri, 22 Apr 2022 19:27:55 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50634) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni2gs-0002jq-RZ for bug-gnu-emacs@gnu.org; Fri, 22 Apr 2022 19:27:54 -0400 Received: from mail-pl1-x62c.google.com ([2607:f8b0:4864:20::62c]:36705) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ni2gq-00054j-Fz for bug-gnu-emacs@gnu.org; Fri, 22 Apr 2022 19:27:54 -0400 Received: by mail-pl1-x62c.google.com with SMTP id q3so14053702plg.3 for ; Fri, 22 Apr 2022 16:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swenson.org; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version; bh=VpmH6XBpyH9CnXVquhB/jTncqwEI6bI/aa9wcq5O4Mw=; b=HAsouwCS9oAAw6R6WGBpvOl7K5vAvIxlGIwCP3uXBlovxj5M1+pCD64VZZYmJ4vX/3 vAAluxtltTYSAa6XeHlZe79jwxqN+nLTBsxDz3sjYuJFLkC8gc0yNRXAtjdt3pJ8CVZW phW103ZpJVErouDZUWfo9gM6Gnq+VLo3Uc+AY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version; bh=VpmH6XBpyH9CnXVquhB/jTncqwEI6bI/aa9wcq5O4Mw=; b=J1zEldFTdjJJtziOe3xz4kg3vjh0qeIN/tEbfaBa3OJD+HXSVMJRhqgFUnKNK3fdly NUEfDGpCu/VrUbSsQXrnxWqpYNmaJ5hb1yAMpQyme+Fk3txUV4v7VhszbJWwad2ouVAe iGW4N7ZryGIFjj28fnVexgfLdQLMK8NH+6IJhlT4zafv3nr6dxqrJPMGxVzuIt0/oXje F4bGvbGF3568ZxTz/oMZ5eogtH7zXsbhNUWWcHgT0UK+yJogR9CJNe+IMNNQJz5lrznu Gf3TQeaIIgfxqLveI/RArIlyFdA6WrDyybukt8LiGr9FMqnNGVu6sHIkd1CYPAX04yHE aSsw== X-Gm-Message-State: AOAM532DByYNNU1ImnGE6SFN+OLOgF1Gj/wKziJJA5GtJZztao0qdzU1 XgIalneVm9WWINThKiOJ0NSyx065PL1erg== X-Google-Smtp-Source: ABdhPJx8nArhcHOk67pZptgnW9WgQ1glqAaC/ficjVBC/VrfQxAdBBG8sTbq3jONHgfGlMTGxKZobw== X-Received: by 2002:a17:902:70c1:b0:154:667f:e361 with SMTP id l1-20020a17090270c100b00154667fe361mr7020207plt.148.1650670069373; Fri, 22 Apr 2022 16:27:49 -0700 (PDT) Received: from [192.168.0.101] (c-73-189-24-121.hsd1.ca.comcast.net. [73.189.24.121]) by smtp.gmail.com with ESMTPSA id a38-20020a056a001d2600b004f72acd4dadsm3689482pfx.81.2022.04.22.16.27.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Apr 2022 16:27:48 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.60.22041000 Date: Fri, 22 Apr 2022 16:27:47 -0700 Subject: 28.1; desktop-load doesn't work in -nw (non-gui) emacs From: Eric Swenson To: Message-ID: Thread-Topic: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3733489668_3359315939" Received-SPF: pass client-ip=2607:f8b0:4864:20::62c; envelope-from=eric@swenson.org; helo=mail-pl1-x62c.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Fri, 22 Apr 2022 19:59:05 -0400 Cc: "Eric Swenson via groups.io" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3733489668_3359315939 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I've tried the following in versions 26.3, 27.1, and 28.1.=C2=A0 If you use desktop-save in a non-GUI (-nw) run of emacs, with no init.el loaded (-Q), and then exit emacs, upon reentry, while the files that were loaded in buffers at the time of the save are present, the windows are not restored properly. Only one window is correct -- and only one window is present.=C2=A0 If you start emacs without the "-nw" option, however, everything works just fine. =20 For some of us who SSH into servers, we have no option but to use the non-GUI version of emacs. =20 Note, I started this ticket in an emacs invocation with "-nw" but without specifying "-Q", so my minimal, test init.el was executed. It appea= rs below: =20 =C2=A0 (desktop-save-mode 1) =C2=A0 (setq desktop-load-locked-desktop nil) =C2=A0 (desktop-read) =20 This bug report was issued from Ubuntu 20.04.=C2=A0 However, I can see the exact same behavior on macOS as well. =20 -- Eric =20 In GNU Emacs 28.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.20, cair= o version 1.16.0) of 2022-04-06 built on lcy02-amd64-033 Repository revision: 8b4be592de49fddc996ebb3e544256e20c81cf85 Repository branch: master System Description: Ubuntu 20.04.4 LTS =20 Configured using: 'configure --prefix=3D/snap/emacs/current/usr --with-x-toolkit=3Dgtk3 --without-xaw3d --with-modules --with-cairo --with-native-compilation 'CFLAGS=3D-isystem/build/emacs/parts/emacs/install/usr/include -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu -O2' 'CPPFLAGS=3D-isystem/build/emacs/parts/emacs/install/usr/include -isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu' 'LDFLAGS=3D-L/build/emacs/parts/emacs/install/lib -L/build/emacs/parts/emacs/install/usr/lib -L/build/emacs/parts/emacs/install/lib/x86_64-linux-gnu -L/build/emacs/parts/emacs/install/usr/lib/x86_64-linux-gnu'' =20 Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB =20 Important settings: =C2=A0 value of $LANG: en_US.UTF-8 =C2=A0 value of $XMODIFIERS: @im=3Dibus =C2=A0 locale-coding-system: utf-8-unix =20 Major mode: Shell-script =20 Minor modes in effect: =C2=A0 sh-electric-here-document-mode: t =C2=A0 desktop-save-mode: t =C2=A0 tooltip-mode: t =C2=A0 global-eldoc-mode: t =C2=A0 show-paren-mode: t =C2=A0 electric-indent-mode: t =C2=A0 mouse-wheel-mode: t =C2=A0 tool-bar-mode: t =C2=A0 menu-bar-mode: t =C2=A0 file-name-shadow-mode: t =C2=A0 global-font-lock-mode: t =C2=A0 font-lock-mode: t =C2=A0 blink-cursor-mode: t =C2=A0 auto-composition-mode: t =C2=A0 auto-encryption-mode: t =C2=A0 auto-compression-mode: t =C2=A0 line-number-mode: t =C2=A0 indent-tabs-mode: t =C2=A0 transient-mark-mode: t =20 Load-path shadows: None found. =20 Features: (shadow sort mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa derived epg rfc6068 epg-config gnus-util rmail rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs password-cache json map 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 mule-util term/xterm xterm dired-aux dired dired-loaddefs time-date sh-script smie executable comp comp-cstr warnings subr-x rx cl-seq cl-macs cl-extra help-mode seq byte-opt gv bytecomp byte-compile cconv desktop frameset cl-loaddefs cl-lib site-start iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode 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 lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer 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 emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window 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 cairo move-toolbar gtk x-toolkit x multi-tty make-network-process native-compile emacs) =20 Memory information: ((conses 16 101029 8397) (symbols 48 8635 1) (strings 32 24989 3159) (string-bytes 1 873580) (vectors 16 16905) (vector-slots 8 309235 14578) (floats 8 31 41) (intervals 56 574 0) (buffers 992 17)) --B_3733489668_3359315939 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

I've tried the following in versions 26.3, 27.1, and 28.1.= =C2=A0 If you use

desktop-save in a non-GUI (-nw) run of emacs, with no init.el loade= d

(-Q= ), and then exit emacs, upon reentry, while the files that were

loaded in buffers= at the time of the save are present, the windows are

<= p class=3DMsoNormal>not restored properly. Only= one window is correct -- and only one window

is present.=C2=A0 If you start emacs wi= thout the "-nw" option, however,

everything works just fine.=

 

For some of u= s who SSH into servers, we have no option but to use the

non-GUI version of emacs= .

 

N= ote, I started this ticket in an emacs invocation with "-nw" but

withou= t specifying "-Q", so my minimal, test init.el was executed. It ap= pears

below:

 

=C2=A0 (desktop-save-mode 1)

=C2=A0 (setq desktop-load-locked-desktop nil)

=C2=A0 (desktop-re= ad)

<= o:p> 

This bug report was issued from Ubuntu 20.04.=C2=A0 However, I can see the=

exact sam= e behavior on macOS as well.

 

-- Eric

 

= In GNU Emacs 28.1 (build 2, x86_64-pc-linux-g= nu, GTK+ Version 3.24.20, cairo version 1.16.0)

of 2022-04-06 built on lcy02-amd= 64-033

Repository revision: 8b4be592de49fddc996ebb3e544256e20c81cf85

Repository branch= : master

System Description: Ubuntu 20.04.4 LTS

 

Configured using:<= /p>

'configure --prefix=3D/s= nap/emacs/current/usr --with-x-toolkit=3Dgtk3

--without-xaw3d --with-modules --wit= h-cairo --with-native-compilation

'CFLAGS=3D-isystem/build/emacs/parts/emacs/insta= ll/usr/include

-isystem/build/emacs/parts/emacs/install/usr/include/x86_64-linux= -gnu

= -O2' 'CPPFLAGS=3D-isystem/build/emacs/parts/emacs/install/usr/include

-isystem/bu= ild/emacs/parts/emacs/install/usr/include/x86_64-linux-gnu'

'LDFLAGS=3D-L/build/em= acs/parts/emacs/install/lib

-L/build/emacs/parts/emacs/install/usr/lib

-L/build/emac= s/parts/emacs/install/lib/x86_64-linux-gnu

-L/build/emacs/parts/emacs/install/us= r/lib/x86_64-linux-gnu''

 

Configured features:

ACL CAIRO DBUS FREETYPE GIF GLIB GMP G= NUTLS GPM GSETTINGS HARFBUZZ JPEG

JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2= M17N_FLT MODULES

NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREA= DS TIFF

TOOLKIT_SCROLL_BARS X11 XDBE XIM XPM GTK3 ZLIB

 

Important settings:

=C2=A0 value of $L= ANG: en_US.UTF-8

=C2=A0 value of $XMODIFIERS: @im=3Dibus

=C2=A0 locale-coding-system: utf-8-unix=

 

Ma= jor mode: Shell-script

 

Minor modes in effect:

=C2=A0 sh-electric-here-document-mode: t

=C2=A0 des= ktop-save-mode: t

=C2=A0 tooltip-mode: t

=C2=A0 global-eldoc-mode: t

=C2=A0 show-paren-mode: t

=C2=A0 electric-i= ndent-mode: t

=C2=A0 mouse-wheel-mode: t

=C2=A0 tool-bar-mode: t

=C2=A0 menu-bar-mode: t

=C2=A0 file-name-shadow= -mode: t

=C2=A0 global-font-lock-mode: t

=C2=A0 font-lock-mode: t

=C2=A0 blink-cursor-mode: t

=C2=A0 auto-compos= ition-mode: t

=C2=A0 auto-encryption-mode: t

= =C2=A0 auto-compression-mode: t=

=C2=A0 line-number-mode: t=

=C2=A0 i= ndent-tabs-mode: t

=C2=A0 transient-mark-mode: t

 

Load-path shadows:

None found.

 <= /span>

Features:

(shadow sor= t mail-extr emacsbug message rmc puny rfc822 mml mml-sec epa

derived epg rfc6068 = epg-config gnus-util rmail rmail-loaddefs

auth-source eieio eieio-core eieio-load= defs password-cache json map

text-property-search mm-decode mm-bodies mm-encode m= ail-parse rfc2231

mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-d= rums

= mm-util mail-prsvr mail-utils mule-util term/xterm xterm dired-aux dired

dired-lo= addefs time-date sh-script smie executable comp comp-cstr<= /p>

warnings subr-x rx cl-s= eq cl-macs cl-extra help-mode seq byte-opt gv

bytecomp byte-compile cconv desktop= frameset cl-loaddefs cl-lib

site-start iso-transl tooltip eldoc paren electric u= niquify ediff-hook

vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win

term/co= mmon-win x-dnd tool-bar dnd fontset image regexp-opt fringe

tabulated-list replac= e newcomment text-mode lisp-mode prog-mode register

page tab-bar menu-bar rfn-esh= adow isearch easymenu timer select

<= span style=3D'font-size:11.0pt'>scroll-bar mouse jit-lock font-lock syntax fon= t-core term/tty-colors

frame minibuffer cl-generic cham georgian utf-8-lang misc-= lang

= vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932

hebrew gree= k romanian slovak czech european ethiopic indian cyrillic<= /p>

chinese composite emoji= -zwj charscript charprop case-table epa-hook

jka-cmpr-hook help simple abbrev oba= rray cl-preloaded nadvice button

loaddefs faces cus-face macroexp files window te= xt-properties overlay

sha1 md5 base64 format env code-pages mule custom widget

hashtab= le-print-readable backquote threads dbusbind inotify lcms2=

dynamic-setting system= -font-setting font-render-setting cairo

move-toolbar gtk x-toolkit x multi-tty ma= ke-network-process

native-compile emacs)

=  

Memory information:

((conses 16 101029 8397)

(symbol= s 48 8635 1)

(strings 32 24989 3159)

(string-bytes 1 873580)

(vectors 16 16905)

(vector-slot= s 8 309235 14578)

(floats 8 31 41)

(intervals 56 574 0)

(buffers 992 17))

--B_3733489668_3359315939-- From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 23 02:13:56 2022 Received: (at 55070) by debbugs.gnu.org; 23 Apr 2022 06:13:56 +0000 Received: from localhost ([127.0.0.1]:55012 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ni91o-0001Bt-J0 for submit@debbugs.gnu.org; Sat, 23 Apr 2022 02:13:56 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ni91m-0001Bf-Mz for 55070@debbugs.gnu.org; Sat, 23 Apr 2022 02:13:55 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53706) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ni91g-0008LV-PT; Sat, 23 Apr 2022 02:13:48 -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=n/8YouLjOguwuFwgtPQ0MSoqeWW+HkygyY58CjHhXYM=; b=TWioDR6tn+pD 4uWdPZoDjKAvrm/B+emRECWeMODIkjAF5fjExRnQgg7pN/wGvprnDR6SmQhm8vXOLF88JF/z2f+Mg 75AUMMP5ymyxnA4/DolLS57mAxvVCmkfM4ibhDfvuRZrG4p94n61Jgo9AJ5VbwJ628xPKcH683c5f CQSwBMl4nNwwCCUKCuQAt+vnM9IMlPyVqVwMEtRWMpiZPvMThLVCf/0ZYIZwSUWIAjVDpRlHBF0Xl EodcVQCw+TTHgYL0GldDv7vJxV+6a7x32tWCh2IqM7b4/uBsatlbq981nuxId3Lb4Ci+pUxA24zOj y+R70t083dkDvwXUBrrPqw==; Received: from [87.69.77.57] (port=4411 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 1ni91g-0002zO-2A; Sat, 23 Apr 2022 02:13:48 -0400 Date: Sat, 23 Apr 2022 09:13:47 +0300 Message-Id: <83fsm4pbs4.fsf@gnu.org> From: Eli Zaretskii To: Eric Swenson In-Reply-To: (message from Eric Swenson on Fri, 22 Apr 2022 16:27:47 -0700) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org, eric=swenson.org@groups.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Fri, 22 Apr 2022 16:27:47 -0700 > From: Eric Swenson > Cc: "Eric Swenson via groups.io" > > I've tried the following in versions 26.3, 27.1, and 28.1. If you use > desktop-save in a non-GUI (-nw) run of emacs, with no init.el loaded > (-Q), and then exit emacs, upon reentry, while the files that were > loaded in buffers at the time of the save are present, the windows are > not restored properly. Only one window is correct -- and only one window > is present. If you start emacs without the "-nw" option, however, > everything works just fine. > > For some of us who SSH into servers, we have no option but to use the > non-GUI version of emacs. > > Note, I started this ticket in an emacs invocation with "-nw" but > without specifying "-Q", so my minimal, test init.el was executed. It appears > below: > > (desktop-save-mode 1) > (setq desktop-load-locked-desktop nil) > (desktop-read) Please tell more about the symptoms: . what do you mean by "only one window"? do you mean "frame" or do you mean "window"? . what does one need to do before exiting the first session to observe the results in the next one? for example, if you indeed mean "only one window", then I guess in the first session one needs to do something like "C-x 2" or maybe "C-x 4 f SOME-FILE"? please describe those actions. . is the second session also a -nw session or is it a GUI session? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 23 08:50:57 2022 Received: (at control) by debbugs.gnu.org; 23 Apr 2022 12:50:57 +0000 Received: from localhost ([127.0.0.1]:55412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niFE1-0001KY-Ej for submit@debbugs.gnu.org; Sat, 23 Apr 2022 08:50:57 -0400 Received: from quimby.gnus.org ([95.216.78.240]:47740) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niFDz-0001KK-JR for control@debbugs.gnu.org; Sat, 23 Apr 2022 08:50:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=CrpazP2HTWrCUUXpBCLBXrD5jdMVndwKi5gNGrvclqA=; b=fF8rnv2jV3b3pyOhsbqPwmXjSp A0ezzQzY2pXjceON9Y+pcyzIkuocRSaOkN4JO38+mS+/1W6D2pUAWs3zQHbSVyS/qkDHgkkmKDZl4 w17d8cLoCPR6CfnzEM6vFElHv2Avx7FtqdWrpL6+NJAV0G0gOaYU38ln17UxmrzTqdyc=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1niFDs-0002Vp-6X for control@debbugs.gnu.org; Sat, 23 Apr 2022 14:50:50 +0200 Date: Sat, 23 Apr 2022 14:50:47 +0200 Message-Id: <87o80st13s.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #55070 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 55070 + moreinfo quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) tags 55070 + moreinfo quit From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 23 09:52:25 2022 Received: (at 55070) by debbugs.gnu.org; 23 Apr 2022 13:52:25 +0000 Received: from localhost ([127.0.0.1]:55498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niGBU-0003Cg-Qr for submit@debbugs.gnu.org; Sat, 23 Apr 2022 09:52:25 -0400 Received: from mail-pl1-f175.google.com ([209.85.214.175]:41857) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niGBT-0003CT-4h for 55070@debbugs.gnu.org; Sat, 23 Apr 2022 09:52:23 -0400 Received: by mail-pl1-f175.google.com with SMTP id s14so16914855plk.8 for <55070@debbugs.gnu.org>; Sat, 23 Apr 2022 06:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swenson.org; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Ew0E1gibG55A41th4fMkO2Grl5mAcdTJgCXzr7OzGMM=; b=J9CQ7OvajED90kv++oCGYAhnT64WtAgAoYXS1DXOHombNg9tGefUmycEcEW+NhOQ3d LcGoHlV/Oj91b/Qa8FO6L7e3Is2AzticrmtDMlznnZ7wzi6udgx6bLGh0s6KdpFAafVF 6GxY2U+fiwgVy0Q/93UJQgLt2818TcIeLz/u4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Ew0E1gibG55A41th4fMkO2Grl5mAcdTJgCXzr7OzGMM=; b=oIQK0S3l3xka62CMk08qhkW3JTs+eImKvp3xX7CmCyI1wUvpyFuvAeGZk4NQXeLKJt dm+OzOMEhCKIh8+fVZtx+z2iQy6aGOKQxf4DzFwraljg7k40QNupj+mQnMezoNIjLShn lSM6MzU9yosLVwIPoZEVtqquFQ14SSLo1QbvFsEVHeYzTuWjkK9bgFnRwta5msg5xtF6 1wxik89nuGc5/mpJjpUrh0xLf0hv4b0Pyw6aS0dF2CqdNhe0fxoV4PcR1LyedhpAMg4E aYePn9HCttNg+Y69bm4ZqD/VmPod9ghz+3H4fohFyNPdbIXFBrUnklkFDgz/QhxPrq3m xRSg== X-Gm-Message-State: AOAM531tjDr0rO/MTvgDYdPrSTg7Zmgk7746W2o9xz3xqqaMzyVG8rQi FR3H6WCdPQ+LFsGvDluratG8jPzonVdmqBbz X-Google-Smtp-Source: ABdhPJxlVgUq//IwTYwhABIKN7G6s6UkOjsttoKz0aptS7ddriMkQbvEa5pW0KgndTPQrpTInwuM1w== X-Received: by 2002:a17:902:e890:b0:15a:161a:16a with SMTP id w16-20020a170902e89000b0015a161a016amr9321384plg.39.1650721936081; Sat, 23 Apr 2022 06:52:16 -0700 (PDT) Received: from smtpclient.apple (c-73-189-24-121.hsd1.ca.comcast.net. [73.189.24.121]) by smtp.gmail.com with ESMTPSA id v11-20020a17090a520b00b001d7dd00c231sm6159895pjh.22.2022.04.23.06.52.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Apr 2022 06:52:15 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Swenson Mime-Version: 1.0 (1.0) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Date: Sat, 23 Apr 2022 06:52:13 -0700 Message-Id: <6961B895-263C-4632-AA4E-8DE29D6160BC@swenson.org> References: <83fsm4pbs4.fsf@gnu.org> In-Reply-To: <83fsm4pbs4.fsf@gnu.org> To: Eli Zaretskii X-Mailer: iPhone Mail (19E258) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org, eric=swenson.org@groups.io X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) I start emacs with a single frame. I create three windows by doing, for exam= ple, C-x 2, and C-x 3. In each window, I read in a file. Then I invoke M-x d= esktop-save, and select a directory. I always use ~/.emacs.d. Then I exit e= macs with C-x C-c. Then I renter emacs and invoke C-x desktop-load. If for both sessions, I invoke emacs with =E2=80=9C-Q=E2=80=9D only, on eith= er macOS or Linux with Gnome desktop, everything works fine. However, if I i= nvoke emacs with =E2=80=9C-nw -Q=E2=80=9D, when I run M-x desktop-load, I on= ly get a single window with one of the files loaded. The other two files are= loaded into buffers, but their windows were not restored. I haven=E2=80=99t tried a case where I ran a GUI session first and saved the= desktop and then ran the non-GUI (-nw) session for the restore, but I=E2=80= =99m pretty sure it would also fail.=20 I think the =E2=80=9Cissue=E2=80=9D is that desktop-load doesn=E2=80=99t wor= k in the -nw session. And yes, you can set up the windows using C-x 4 f as well as the e= xplicitly creating a second window and splitting and then loading files into= each. It doesn=E2=80=99t really matter.=20 -- Eric (KN6SIJ) > On Apr 22, 2022, at 23:13, Eli Zaretskii wrote: >=20 > =EF=BB=BF >>=20 >> Date: Fri, 22 Apr 2022 16:27:47 -0700 >> From: Eric Swenson >> Cc: "Eric Swenson via groups.io" >>=20 >> I've tried the following in versions 26.3, 27.1, and 28.1. If you use >> desktop-save in a non-GUI (-nw) run of emacs, with no init.el loaded >> (-Q), and then exit emacs, upon reentry, while the files that were >> loaded in buffers at the time of the save are present, the windows are >> not restored properly. Only one window is correct -- and only one window >> is present. If you start emacs without the "-nw" option, however, >> everything works just fine. >>=20 >> For some of us who SSH into servers, we have no option but to use the >> non-GUI version of emacs. >>=20 >> Note, I started this ticket in an emacs invocation with "-nw" but >> without specifying "-Q", so my minimal, test init.el was executed. It app= ears >> below: >>=20 >> (desktop-save-mode 1) >> (setq desktop-load-locked-desktop nil) >> (desktop-read) >=20 > Please tell more about the symptoms: >=20 > . what do you mean by "only one window"? do you mean "frame" or do > you mean "window"? > . what does one need to do before exiting the first session to > observe the results in the next one? for example, if you indeed > mean "only one window", then I guess in the first session one needs > to do something like "C-x 2" or maybe "C-x 4 f SOME-FILE"? please > describe those actions. > . is the second session also a -nw session or is it a GUI session? >=20 > Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 23 10:25:17 2022 Received: (at 55070) by debbugs.gnu.org; 23 Apr 2022 14:25:17 +0000 Received: from localhost ([127.0.0.1]:56858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niGhJ-0000Jb-Du for submit@debbugs.gnu.org; Sat, 23 Apr 2022 10:25:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:35326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niGhH-0000JL-SV for 55070@debbugs.gnu.org; Sat, 23 Apr 2022 10:25:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60972) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1niGhC-0002bB-Bj; Sat, 23 Apr 2022 10:25:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=0ViBz3lFt181s6b6B5JHOggCz6c99omIn4HXEycLY2E=; b=YgdZko8LW1JRNFMohHmH ofrFpUFiZpBiPDav68K6WFdMNdXU/vEGy2Y+vBRIa5qQHZAi/cR4gFUPe+y242A/92HmC7oCV0/kW eHmV3M4BVnWYSceeRH2l0/PhPbUXOU7h//y9d116W/l3c3S8MCkXzRFWkhR2Ue5LmLRZPXecGjRaJ 5BVagrNUlFaak6Y0DjU/NoKZ5viE9lQsLLY6b7hOErar1+GBBsaF4ULoEXDtA6xQ6qjhQj3xyDl25 M3xdo5xickVtOIL/C1rNSFMYGPpza4OO9E3e5s+Hv2oPfV1dz/2VIQV5qVjv7VtFBt/TZyngfAbm4 41gS18JgbP3XRQ==; Received: from [87.69.77.57] (port=3753 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 1niGhB-0002Eu-Gp; Sat, 23 Apr 2022 10:25:10 -0400 Date: Sat, 23 Apr 2022 17:25:10 +0300 Message-Id: <83sfq3op15.fsf@gnu.org> From: Eli Zaretskii To: Eric Swenson In-Reply-To: <6961B895-263C-4632-AA4E-8DE29D6160BC@swenson.org> (message from Eric Swenson on Sat, 23 Apr 2022 06:52:13 -0700) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs References: <83fsm4pbs4.fsf@gnu.org> <6961B895-263C-4632-AA4E-8DE29D6160BC@swenson.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eric Swenson > Date: Sat, 23 Apr 2022 06:52:13 -0700 > Cc: 55070@debbugs.gnu.org, eric=swenson.org@groups.io > > I start emacs with a single frame. I create three windows by doing, for example, C-x 2, and C-x 3. In each window, I read in a file. Then I invoke M-x desktop-save, and select a directory. I always use ~/.emacs.d. Then I exit emacs with C-x C-c. > > Then I renter emacs and invoke C-x desktop-load. > > If for both sessions, I invoke emacs with “-Q” only, on either macOS or Linux with Gnome desktop, everything works fine. However, if I invoke emacs with “-nw -Q”, when I run M-x desktop-load, I only get a single window with one of the files loaded. The other two files are loaded into buffers, but their windows were not restored. > > I haven’t tried a case where I ran a GUI session first and saved the desktop and then ran the non-GUI (-nw) session for the restore, but I’m pretty sure it would also fail. > > I think the “issue” is that desktop-load doesn’t work in the -nw session. > > And yes, you can set up the windows using C-x 4 f as well as the explicitly creating a second window and splitting and then loading files into each. It doesn’t really matter. OK, thanks for the details. They tell me that what you see is the intended behavior: desktop.el doesn't restore frames and windows on text-mode terminals. This is because restoring frames and windows in a -nw session is problematic, especially if the desktop was saved from a GUI session. If this causes a lot of inconvenience, maybe we could have a user option to allow restoring the frameset in -nw session, for those who only ever use -nw sessions. But we cannot allow that in general, and not by default, IMO. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 23 10:54:01 2022 Received: (at 55070) by debbugs.gnu.org; 23 Apr 2022 14:54:01 +0000 Received: from localhost ([127.0.0.1]:56971 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niH92-0005We-Gm for submit@debbugs.gnu.org; Sat, 23 Apr 2022 10:54:01 -0400 Received: from mail-pl1-f170.google.com ([209.85.214.170]:46010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niH90-0005WP-EV for 55070@debbugs.gnu.org; Sat, 23 Apr 2022 10:53:54 -0400 Received: by mail-pl1-f170.google.com with SMTP id h12so13478521plf.12 for <55070@debbugs.gnu.org>; Sat, 23 Apr 2022 07:53:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swenson.org; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=aviUNQ25FXP54s0XfmOO0SILQwCqEvS1RIcjUCL0WBM=; b=T5HtZwl/0mnNG7NumqZXfKBA8jeI/L1UwNPnxDnjFcA/xKQmFZO3dIAEyCug3EGZm1 vHAFRcSX3G2tftFRt2yQdIDP7tVM28s5HCk7FvOKAHRAgtS07SLI0FqdvfMR0lyMVXKE E6khq0ZG5xuRPzQrywV3Wc+MbkbmUAJqFORhE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=aviUNQ25FXP54s0XfmOO0SILQwCqEvS1RIcjUCL0WBM=; b=AwG06i2eq7mPls5mH5hXuAgvo8NaUyi31MAKKRhrmlhvodI0qlPEtA/h67RoPLUKnN EP4/gDh9zuuaiES75q0xnjcF/F+apbloB8gTZOfauoMgY+rkqw+SyMhFqG0FJ7qPWJ52 ryPxDVwoD4WapaufBuJR53uZ5QUBY+v/T8jfcxCwLNZqUQRfZk2k7cXSjCQlw1XonYB1 Dud26k76SIwlOkJF752196PzWEmY1txNnMGOltDczjSCVuRFb1jOsHjqHH9D3fZvf21i qHj/Q52oldt6B6I9vKTbT51SRSE34L2fSUn+1BD6ULZ4C3NfBGccAOSYvdEpkl1voiVb UgPw== X-Gm-Message-State: AOAM531L5clQSRjhrMJ8eChW5VzSQcAv3JG1nSXDm1YDMMtcB1dd6GX6 /D8ynx7HSmXFcE0i/wud/iRpaTI0cUDBswXU X-Google-Smtp-Source: ABdhPJytwpUuZWiZ1Z1gehUTMH61cJOrqq8yfZxfUYjJ6wNOddjdOPhV9cnbjObIHztYAl3vUcFrlQ== X-Received: by 2002:a17:90a:fd10:b0:1d9:2a41:6fe6 with SMTP id cv16-20020a17090afd1000b001d92a416fe6mr4146183pjb.196.1650725627462; Sat, 23 Apr 2022 07:53:47 -0700 (PDT) Received: from smtpclient.apple (c-73-189-24-121.hsd1.ca.comcast.net. [73.189.24.121]) by smtp.gmail.com with ESMTPSA id 76-20020a62194f000000b0050abaf80f99sm6051969pfz.114.2022.04.23.07.53.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Apr 2022 07:53:46 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Swenson Mime-Version: 1.0 (1.0) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Date: Sat, 23 Apr 2022 07:53:43 -0700 Message-Id: <0005CD80-4AE7-4E00-86EB-6ADDF333A9B6@swenson.org> References: <83sfq3op15.fsf@gnu.org> In-Reply-To: <83sfq3op15.fsf@gnu.org> To: Eli Zaretskii X-Mailer: iPhone Mail (19E258) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Thanks. It seems really strange that this should be problematic in -nw sessi= ons. I could understand not being able to restore windows between a GUI and -= nw sessions, but I don=E2=80=99t see why, since windows work perfectly well i= n a single frame in a -nw session that restoring them should be problematic.= Can you explain why this is difficult? In -nw sessions the same commands spl= it windows perfectly well. So clearly -nw sessions support window splitting =E2= =80=94 why not restoring? (I think a restriction that requires the saving an= d restoring sessions to be the same kind (either both -nw or both GUI) is a p= erfectly sensible restriction. -- Eric (KN6SIJ) > On Apr 23, 2022, at 07:25, Eli Zaretskii wrote: >=20 > =EF=BB=BF >>=20 >> From: Eric Swenson >> Date: Sat, 23 Apr 2022 06:52:13 -0700 >> Cc: 55070@debbugs.gnu.org, eric=3Dswenson.org@groups.io >>=20 >> I start emacs with a single frame. I create three windows by doing, for e= xample, C-x 2, and C-x 3. In each window, I read in a file. Then I invoke M-= x desktop-save, and select a directory. I always use ~/.emacs.d. Then I exi= t emacs with C-x C-c. >>=20 >> Then I renter emacs and invoke C-x desktop-load. >>=20 >> If for both sessions, I invoke emacs with =E2=80=9C-Q=E2=80=9D only, on e= ither macOS or Linux with Gnome desktop, everything works fine. However, if I= invoke emacs with =E2=80=9C-nw -Q=E2=80=9D, when I run M-x desktop-load, I o= nly get a single window with one of the files loaded. The other two files ar= e loaded into buffers, but their windows were not restored. >>=20 >> I haven=E2=80=99t tried a case where I ran a GUI session first and saved t= he desktop and then ran the non-GUI (-nw) session for the restore, but I=E2=80= =99m pretty sure it would also fail.=20 >>=20 >> I think the =E2=80=9Cissue=E2=80=9D is that desktop-load doesn=E2=80=99t w= ork in the -nw session. >>=20 >> And yes, you can set up the windows using C-x 4 f as well as t= he explicitly creating a second window and splitting and then loading files i= nto each. It doesn=E2=80=99t really matter.=20 >=20 > OK, thanks for the details. They tell me that what you see is the > intended behavior: desktop.el doesn't restore frames and windows on > text-mode terminals. This is because restoring frames and windows in > a -nw session is problematic, especially if the desktop was saved from > a GUI session. >=20 > If this causes a lot of inconvenience, maybe we could have a user > option to allow restoring the frameset in -nw session, for those who > only ever use -nw sessions. But we cannot allow that in general, and > not by default, IMO. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 23 11:16:44 2022 Received: (at 55070) by debbugs.gnu.org; 23 Apr 2022 15:16:44 +0000 Received: from localhost ([127.0.0.1]:56991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niHV6-0008Hi-4T for submit@debbugs.gnu.org; Sat, 23 Apr 2022 11:16:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41806) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niHV4-0008HV-ED for 55070@debbugs.gnu.org; Sat, 23 Apr 2022 11:16:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33034) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1niHUy-0001Tp-Q4; Sat, 23 Apr 2022 11:16:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=jbJ5raAtAlHh6vqwGYMKZyjrpnz9qPVdp2ZgyiwpL9A=; b=mDj3Vzgj4ZS1BtFwnkFy RIzOwTCpn8hwlAgAuyHeR65rckVzfahbfXUKjjftnM3FAKuTBjdIskh8I42itW4OPqe17l6k5aODI Pi65SeplhIS58keXv09Lpi4IVamVVfWU9Mxk6CDf2GU2hfjgaZN47HuMyCf1tmLExCfcha4dWP5qx 0bjlTacLo1Qo6uKs4cPkjiy6VpbYEygETZeLVOdQi6OfN3DLrivqNUQMRZBxL7IPVg4jZyro61MwI ScX3JeJi6OCs7XcdKpufcf2DAYZocgwHsItTZCqn6ocs1Q98ZUGy/EH5q+1KTcCJWRgdmwmHNXmJl JvzTa57WtwwgEw==; Received: from [87.69.77.57] (port=2955 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 1niHUy-0004CJ-9F; Sat, 23 Apr 2022 11:16:36 -0400 Date: Sat, 23 Apr 2022 18:16:32 +0300 Message-Id: <83r15nomnj.fsf@gnu.org> From: Eli Zaretskii To: Eric Swenson In-Reply-To: <0005CD80-4AE7-4E00-86EB-6ADDF333A9B6@swenson.org> (message from Eric Swenson on Sat, 23 Apr 2022 07:53:43 -0700) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs References: <83sfq3op15.fsf@gnu.org> <0005CD80-4AE7-4E00-86EB-6ADDF333A9B6@swenson.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Eric Swenson > Date: Sat, 23 Apr 2022 07:53:43 -0700 > Cc: 55070@debbugs.gnu.org > > Thanks. It seems really strange that this should be problematic in -nw sessions. I could understand not being able to restore windows between a GUI and -nw sessions, but I don’t see why, since windows work perfectly well in a single frame in a -nw session that restoring them should be problematic. > > Can you explain why this is difficult? In -nw sessions the same commands split windows perfectly well. So clearly -nw sessions support window splitting — why not restoring? (I think a restriction that requires the saving and restoring sessions to be the same kind (either both -nw or both GUI) is a perfectly sensible restriction. Emacs currently cannot restore windows without also restoring the frames. Technically, this is because we use the frameset.el package as infrastructure for this desktop.el facility. And restoring frames in a -nw session will create GUI frames, something the user didn't intend. So we disabled that. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 23 11:39:24 2022 Received: (at 55070) by debbugs.gnu.org; 23 Apr 2022 15:39:24 +0000 Received: from localhost ([127.0.0.1]:57033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niHr2-0002ba-GD for submit@debbugs.gnu.org; Sat, 23 Apr 2022 11:39:24 -0400 Received: from mail-pf1-f171.google.com ([209.85.210.171]:46784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1niHr0-0002bM-1w for 55070@debbugs.gnu.org; Sat, 23 Apr 2022 11:39:22 -0400 Received: by mail-pf1-f171.google.com with SMTP id j6so8450992pfe.13 for <55070@debbugs.gnu.org>; Sat, 23 Apr 2022 08:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swenson.org; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=ZMdLg/5Gg8xgttEhAxKeCUqyHvNczCaWYhkajJ4jmvI=; b=a4VI8PD03/ANTWyOhmmj7s5dYEctFoUkl3SIPbXGkEhr3gVKsxXJ0HHftNjfrL3F42 XKvj5Q6g2tSde931251M9H9shmvjlkcHjvBOzTAeGY8wta68bJEitDqCSpttlnZ047el jzpajko5hKIgz219htn8Vfj+QfP8AQfE/ea/M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=ZMdLg/5Gg8xgttEhAxKeCUqyHvNczCaWYhkajJ4jmvI=; b=RaKIHOxJzD/Y4aCPzsy7zubBWYiBiOSepjdVdWx+AUmJO0+JdLET++w+XGA3D8q/kA 6EJYcqBlUJA4Fk4dGFbzTvYzXVzJNTNsgaZ29fMON9pDd4zDkHEAdi+nW+41OIWlcH+2 5hS/zDtvkiMnAa8p7z2JkAZBe9e3x3cYIlBCm7aIltC/KL4s2wom+Z23egzz5gVkbSfo EQFmumILZjtwrFuzKkvFYTShidbO1NE6B705xoAG19esFp6vZFuRwGTMfIeBgIbXGBPW tBKD/cfjr2ePfowGK9e1uOnzibp8Ijk2a5MrhAxGs5bB+UX19F0LMZicm5HUVxJRqMlq /eNQ== X-Gm-Message-State: AOAM5327gAJoHJzU/+I9Jql3G6F/h+ng1Fkqz4PJcP4uK4oSF6j/iZty wFjjx2wTaUBWIqc3oJJA633WpctcBJp254hQ X-Google-Smtp-Source: ABdhPJxpOpLJTjw1sFHYQA8una2ZJAoslFd7lysVuFIIuwUh4xh3XALCEytjlmL6SYCAII9aw41WQg== X-Received: by 2002:a05:6a00:170d:b0:50a:858e:2b6e with SMTP id h13-20020a056a00170d00b0050a858e2b6emr10525897pfc.48.1650728355173; Sat, 23 Apr 2022 08:39:15 -0700 (PDT) Received: from smtpclient.apple (c-73-189-24-121.hsd1.ca.comcast.net. [73.189.24.121]) by smtp.gmail.com with ESMTPSA id d141-20020a621d93000000b00505aa1026f1sm6009275pfd.51.2022.04.23.08.39.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 Apr 2022 08:39:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Eric Swenson Mime-Version: 1.0 (1.0) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Date: Sat, 23 Apr 2022 08:39:12 -0700 Message-Id: <3E7AC94F-5AF1-4C3F-948A-F86EBBCF880E@swenson.org> References: <83r15nomnj.fsf@gnu.org> In-Reply-To: <83r15nomnj.fsf@gnu.org> To: Eli Zaretskii X-Mailer: iPhone Mail (19E258) X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Ah, that makes sense. Thanks. Still, this is very non-obvious to the user an= d is really an current implementation decision issue rather than a good reas= on for not supporting it. I suggest two action items. 1) update the documentation for desktop-save and= desktop-read to say that it only works in non -nw sessions. 2) keep this ti= cket open since the functionality makes as much sense in -nw sessions as in G= UI sessions.=20 The code could certainly be updated to handle the case where there is a sing= le frame and the user is trying to restore in an -nw session.=20 Also, while I have your ear, the obvious command for restoring a desktop whe= n desktop-save is used to save it would be desktop-restore. Desktop-read is v= ery non-intuitive. Thanks for listening and explaining the reason for the limitation. -- Eric (KN6SIJ) > On Apr 23, 2022, at 08:16, Eli Zaretskii wrote: >=20 > =EF=BB=BF >>=20 >> From: Eric Swenson >> Date: Sat, 23 Apr 2022 07:53:43 -0700 >> Cc: 55070@debbugs.gnu.org >>=20 >> Thanks. It seems really strange that this should be problematic in -nw se= ssions. I could understand not being able to restore windows between a GUI a= nd -nw sessions, but I don=E2=80=99t see why, since windows work perfectly w= ell in a single frame in a -nw session that restoring them should be problem= atic. >>=20 >> Can you explain why this is difficult? In -nw sessions the same commands s= plit windows perfectly well. So clearly -nw sessions support window splittin= g =E2=80=94 why not restoring? (I think a restriction that requires the savi= ng and restoring sessions to be the same kind (either both -nw or both GUI) i= s a perfectly sensible restriction. >=20 > Emacs currently cannot restore windows without also restoring the > frames. Technically, this is because we use the frameset.el package > as infrastructure for this desktop.el facility. And restoring frames > in a -nw session will create GUI frames, something the user didn't > intend. So we disabled that. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 04:18:27 2022 Received: (at 55070) by debbugs.gnu.org; 26 Apr 2022 08:18:27 +0000 Received: from localhost ([127.0.0.1]:36977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njGOx-0000aI-2z for submit@debbugs.gnu.org; Tue, 26 Apr 2022 04:18:27 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:51775) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njGOv-0000a5-8Z for 55070@debbugs.gnu.org; Tue, 26 Apr 2022 04:18:25 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 76F3B1BF209; Tue, 26 Apr 2022 08:18:16 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET References: <83fsm4pbs4.fsf@gnu.org> <6961B895-263C-4632-AA4E-8DE29D6160BC@swenson.org> <83sfq3op15.fsf@gnu.org> Date: Tue, 26 Apr 2022 10:58:28 +0300 In-Reply-To: <83sfq3op15.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 23 Apr 2022 17:25:10 +0300") Message-ID: <86wnfcxnvf.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: Eric Swenson , 55070@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > OK, thanks for the details. They tell me that what you see is the > intended behavior: desktop.el doesn't restore frames and windows on > text-mode terminals. This is because restoring frames and windows in > a -nw session is problematic, especially if the desktop was saved from > a GUI session. Interesting, I see this is disabled explicitly by display-graphic-p in: (defun desktop-restoring-frameset-p () "True if calling `desktop-restore-frameset' will actually restore it." (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t)) When I tried to remove display-graphic-p, then it's problematic indeed and fails with: frameset-move-onscreen(# t) frameset--restore-frame(((minibuffer . t) (tty-type . "xterm-256color") ... frameset-restore([frameset 1 ... desktop-restore-frameset() desktop-read(nil (4)) funcall-interactively(desktop-read nil (4)) command-execute(desktop-read record) So the problem is in frameset-move-onscreen. A little debugging revealed that it fails on the nil frame-parameter 'left', so a small patch could fix it, then restoring frames in a -nw session works fine: diff --git a/lisp/frameset.el b/lisp/frameset.el index 05884eed3a..32966376d8 100644 --- a/lisp/frameset.el +++ b/lisp/frameset.el @@ -883,8 +883,8 @@ frameset-move-onscreen (pcase-let* ((`(,left ,top ,width ,height) (cdadr (frame-monitor-attributes frame))) (right (+ left width -1)) (bottom (+ top height -1)) - (fr-left (frameset-compute-pos (frame-parameter frame 'left) left right)) - (fr-top (frameset-compute-pos (frame-parameter frame 'top) top bottom)) + (fr-left (frameset-compute-pos (or (frame-parameter frame 'left) 0) left right)) + (fr-top (frameset-compute-pos (or (frame-parameter frame 'top) 0) top bottom)) (ch-width (frame-char-width frame)) (ch-height (frame-char-height frame)) (fr-width (max (frame-pixel-width frame) (* ch-width (frame-width frame)))) From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 06:16:37 2022 Received: (at 55070) by debbugs.gnu.org; 26 Apr 2022 10:16:37 +0000 Received: from localhost ([127.0.0.1]:37134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njIFJ-0007Iv-8o for submit@debbugs.gnu.org; Tue, 26 Apr 2022 06:16:37 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njIFH-0007EB-My for 55070@debbugs.gnu.org; Tue, 26 Apr 2022 06:16:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=QfjWNJJC9P+fsuGEBudvLSE09pnpqm3WbZuY6BfygFo=; b=iR6A0weDQtHeGpziT4lAhcs/hm dizhAXuGO8MxAVE6kj6FmQkr5FF4HBiTQmU4RpcnC0HFsMEs2D7CLf7jOFseZs/Ic8xzPfH+EmsNE Zy010RTTIZ//v4Chy9EGjTAIJ/W94sug7Qm/JPMdt6i7h2Gpc0rCt1NDrEm5T9HWNnj8=; Received: from [84.212.220.105] (helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1njIF8-0007GB-Ec; Tue, 26 Apr 2022 12:16:28 +0200 From: Lars Ingebrigtsen To: Juri Linkov Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs References: <83fsm4pbs4.fsf@gnu.org> <6961B895-263C-4632-AA4E-8DE29D6160BC@swenson.org> <83sfq3op15.fsf@gnu.org> <86wnfcxnvf.fsf@mail.linkov.net> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAIVBMVEUDAgInGxTfixKe UB3faCZnRBVcNCOJPSIyKitHREb///9t9pFbAAAAAWJLR0QKaND0VgAAAAlwSFlzAAC4YAAAuGAB X7vcNgAAAAd0SU1FB+YEGgoNKqVvcUkAAAGXSURBVDjLhdRBT8IwFAfw9saxL+osR+ELODaDRxkL XiFk4BGy0O0IGYJHGuLsbnrbvq2vgEbXEt5lrL+8f7fXBUIuFJyK1aHd8jtB0O/f1aHT6rSCVtsz IDrV6MwezNgjDMN+MFiHRlQYhK4/WHtPdfCxQ3e5FjhUz4Bnv5ssssddHda9KyFEfG881drdi1zE SwMy97orMn9o63gVi2xmgY80n+9NyFaOVPLWhBiByxtzVslKITiyvk6mIw6cOX8aKK+qT+wYchz6 AWhTcXW4YH2J+S8QVRYFww5cB5lMUgkYpkGiHAGjhEgBVC5mCA2lKg3VF95s3ud4sgcoMaLSm5f4 a7fJsQMcgWNnHKMQilKVwHwvBQrOQp8HBdXUUVLhXeZtpO5gqiqqQu/xM6vuG1A19mbGm4sXQnji GR8DIQ4QSLZLG1A+tQPw7XZoAgfJo6kFGiDpIrIBAyomxuPiPAijxyH+K6UYgtJDqEF6BvIUl6wg j4FmlCQU38UEjkPHg+AGnP1nOF/jOPIi20TiceY9jN3LCd/fIYHJL9pyBwAAACV0RVh0ZGF0ZTpj cmVhdGUAMjAyMi0wNC0yNlQxMDoxMzo0MiswMDowMOhqwdUAAAAldEVYdGRhdGU6bW9kaWZ5ADIw MjItMDQtMjZUMTA6MTM6NDIrMDA6MDCZN3lpAAAAAElFTkSuQmCC X-Now-Playing: Shearwater's _The Dissolving Room_: "Ella Is the First Rider" Date: Tue, 26 Apr 2022 12:16:25 +0200 In-Reply-To: <86wnfcxnvf.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 26 Apr 2022 10:58:28 +0300") Message-ID: <87mtg8i1za.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Juri Linkov writes: > So the problem is in frameset-move-onscreen. A little debugging > revealed that it fails on the nil frame-parameter 'left', > so a small patch could fix it, then restoring frames > in a -nw session [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: Eric Swenson , 55070@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Juri Linkov writes: > So the problem is in frameset-move-onscreen. A little debugging > revealed that it fails on the nil frame-parameter 'left', > so a small patch could fix it, then restoring frames > in a -nw session works fine: I think the reason for disabling restoring frames on -nw wasn't because of technical reasons, but because of most users not being aware that an -nw Emacs can have frames, so they ended up with very confusing setups after restoring from desktop. But this is an issue that's come up again and again, so I think we should introduce a new user option to allow desktop to restore frames on -nw. (And that means that we should also apply your patch, I think?) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 07:26:44 2022 Received: (at 55070) by debbugs.gnu.org; 26 Apr 2022 11:26:44 +0000 Received: from localhost ([127.0.0.1]:37242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njJL9-0005aA-Ls for submit@debbugs.gnu.org; Tue, 26 Apr 2022 07:26:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55736) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njJL7-0005ZJ-Tv for 55070@debbugs.gnu.org; Tue, 26 Apr 2022 07:26:42 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58104) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njJL1-0000qK-VF; Tue, 26 Apr 2022 07:26:35 -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=vNhEgHS06NeFJ9T914T2nHA2zskLkEFfmOrqov4vkgE=; b=WwBh1dDMcTE6 BqMJHhtnmCDaJoYExxMh4ZncQONzpvk1KAs4ET2m5n/Jh9BTym+viQsbzRZmMXQDtpiCOMLbxu0+T LJao/KBhb7/QO86xZuWOKWzhTiddV7OjQ/H5ibbNAtXKfeEGzO3pXLhAcY7bYC4fGkBQXfn4orKST 5yPW6+ST+Cip9+dr7N/qeuWncC0rMhBhRDCJ/L7C1Pvg8GBae8zze1ZgJa4YAeetZ2qQjaqwFwuYp ZjcX7sD4+cEFxHwuCWuE5QxVqWaBPiHaXTqDaDyDvFwKKnUD+VqBphslbURR3jjgJDDdJRHZzWtBZ e4788nhxyoTzmU7mGwcKeA==; Received: from [87.69.77.57] (port=4580 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 1njJL1-0008Qw-8L; Tue, 26 Apr 2022 07:26:35 -0400 Date: Tue, 26 Apr 2022 14:26:22 +0300 Message-Id: <837d7cm6g1.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-Reply-To: <87mtg8i1za.fsf@gnus.org> (message from Lars Ingebrigtsen on Tue, 26 Apr 2022 12:16:25 +0200) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: Eli Zaretskii , Eric Swenson , > 55070@debbugs.gnu.org > Date: Tue, 26 Apr 2022 12:16:25 +0200 > > Juri Linkov writes: > > > So the problem is in frameset-move-onscreen. A little debugging > > revealed that it fails on the nil frame-parameter 'left', > > so a small patch could fix it, then restoring frames > > in a -nw session works fine: > > I think the reason for disabling restoring frames on -nw wasn't because > of technical reasons, but because of most users not being aware that an > -nw Emacs can have frames, so they ended up with very confusing setups > after restoring from desktop. > > But this is an issue that's come up again and again, so I think we > should introduce a new user option to allow desktop to restore frames on > -nw. I agree. I think a useful first step could be to teach frameset to restore windows, but not frames, in some useful way (e.g., restore the window configuration of just a single frame). Alternatively, we could try teaching desktop.el to better filter the frame parameters so that it could ignore the problematic ones, but I think this will be harder and less reliable. > (And that means that we should also apply your patch, I think?) I wouldn't. It looks too ad-hoc to me, and its only purpose is to fix desktop.el, so why does it need to be in frameset.el? The display-graphic-p condition was introduced because we had bug reports about the previous behavior (which didn't disallow restoring framesets in -nw sessions). From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 11:53:55 2022 Received: (at 55070) by debbugs.gnu.org; 26 Apr 2022 15:53:55 +0000 Received: from localhost ([127.0.0.1]:40331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njNVj-0000ka-1f for submit@debbugs.gnu.org; Tue, 26 Apr 2022 11:53:55 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:36125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njNVh-0000kA-EJ for 55070@debbugs.gnu.org; Tue, 26 Apr 2022 11:53:53 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 0A588C0003; Tue, 26 Apr 2022 15:53:45 +0000 (UTC) From: Juri Linkov To: Lars Ingebrigtsen Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> Date: Tue, 26 Apr 2022 18:28:18 +0300 In-Reply-To: <87mtg8i1za.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 26 Apr 2022 12:16:25 +0200") Message-ID: <86h76fu9q5.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: Eric Swenson , 55070@debbugs.gnu.org, Eli Zaretskii X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain > I think the reason for disabling restoring frames on -nw wasn't because > of technical reasons, but because of most users not being aware that an > -nw Emacs can have frames, so they ended up with very confusing setups > after restoring from desktop. > > But this is an issue that's come up again and again, so I think we > should introduce a new user option to allow desktop to restore frames on > -nw. (And that means that we should also apply your patch, I think?) Indeed, this is what an old comment in desktop.el used to say: ;; People don't expect emacs -nw, or --daemon, ;; to create graphical frames (bug#17693). ;; TODO perhaps there should be a separate value ;; for desktop-restore-frames to control this startup behavior? So this patch creates such separate values: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=desktop-restore-frames.patch diff --git a/lisp/desktop.el b/lisp/desktop.el index cd581e028b..b46c41e0e4 100644 --- a/lisp/desktop.el +++ b/lisp/desktop.el @@ -412,7 +412,10 @@ desktop-restore-frames "When non-nil, save and restore the frame and window configuration. See related options `desktop-restore-reuses-frames', `desktop-restore-in-current-display', and `desktop-restore-forces-onscreen'." - :type 'boolean + :type '(choice (const :tag "Don't restore frames" nil) + (const :tag "Restore frames" t) + (const :tag "Restore only graphical frames" x) + (const :tag "Restore only -nw frames" tty)) :group 'desktop :version "24.4") @@ -1245,7 +1248,13 @@ desktop-lazy-timer ;; ---------------------------------------------------------------------------- (defun desktop-restoring-frameset-p () "True if calling `desktop-restore-frameset' will actually restore it." - (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t)) + (and (pcase desktop-restore-frames + ('x (display-graphic-p)) + ('tty (not (display-graphic-p))) + ('nil nil) + (_ t)) + desktop-saved-frameset + t)) (defun desktop-restore-frameset () "Restore the state of a set of frames. diff --git a/lisp/frameset.el b/lisp/frameset.el index 05884eed3a..32966376d8 100644 --- a/lisp/frameset.el +++ b/lisp/frameset.el @@ -883,8 +883,8 @@ frameset-move-onscreen (pcase-let* ((`(,left ,top ,width ,height) (cdadr (frame-monitor-attributes frame))) (right (+ left width -1)) (bottom (+ top height -1)) - (fr-left (frameset-compute-pos (frame-parameter frame 'left) left right)) - (fr-top (frameset-compute-pos (frame-parameter frame 'top) top bottom)) + (fr-left (frameset-compute-pos (or (frame-parameter frame 'left) 0) left right)) + (fr-top (frameset-compute-pos (or (frame-parameter frame 'top) 0) top bottom)) (ch-width (frame-char-width frame)) (ch-height (frame-char-height frame)) (fr-width (max (frame-pixel-width frame) (* ch-width (frame-width frame)))) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 12:09:42 2022 Received: (at 55070) by debbugs.gnu.org; 26 Apr 2022 16:09:42 +0000 Received: from localhost ([127.0.0.1]:40364 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njNl0-000194-5D for submit@debbugs.gnu.org; Tue, 26 Apr 2022 12:09:42 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njNkz-00018q-7Q for 55070@debbugs.gnu.org; Tue, 26 Apr 2022 12:09:41 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34880) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njNkt-00006M-9L; Tue, 26 Apr 2022 12:09:35 -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=ReTLmrfetWgRELPMxsqiNHwkvXISgkE4xxWfLwC1s+o=; b=mWZMX5FjK4V1 JjGygsTdKzYIIULrSBJVbr9/kyi+fmQmn7qWJp/HTQbFO6KZoqzEZvkEKJkSGDbDcfnV41ni6lHZ0 LPN6CqJkUH6XGiP01OppG9iar+kRf5UngrRLTjvV+eDacF5BbQLPeeCucTmKdCyR73kzjh4Ah3a9A alWrOwo/QkQ9MQc/6CSzoi1Sz7RtBtI1/LjECY3WZ/nTyB09f6okn9vCqTIol7UdEypfIblD4Jk/u bvbGL9Y2T81J6SzXpkvS0T9yIr01e/JktXQqymJRFOR8j6OA3QwyJkiXTwKZxw1uk9g8rOvvb3usc BGUkhnsfglS2oC0IRa1S4w==; Received: from [87.69.77.57] (port=2551 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 1njNks-0004o8-Oy; Tue, 26 Apr 2022 12:09:35 -0400 Date: Tue, 26 Apr 2022 19:09:21 +0300 Message-Id: <83r15jltce.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86h76fu9q5.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 26 Apr 2022 18:28:18 +0300) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: Eli Zaretskii , Eric Swenson , > 55070@debbugs.gnu.org > Date: Tue, 26 Apr 2022 18:28:18 +0300 > > ;; People don't expect emacs -nw, or --daemon, > ;; to create graphical frames (bug#17693). > ;; TODO perhaps there should be a separate value > ;; for desktop-restore-frames to control this startup behavior? > > So this patch creates such separate values: Thanks, but I don't understand why you need the frameset part of the patch. Or if you do need it, why does it have to look so ad-hoc? If we want to support in frameset.el frames for which some frame parameters make no sense, let's do that explicitly, not by sweeping problems under the carpet by substituting some arbitrary values for those parameters that give us trouble. IOW, in 10 years, would you be able to remember and explain why we use zero instead of 'left' and 'top'? From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 13:42:13 2022 Received: (at 55070) by debbugs.gnu.org; 26 Apr 2022 17:42:13 +0000 Received: from localhost ([127.0.0.1]:40470 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njPCX-0003RZ-Af for submit@debbugs.gnu.org; Tue, 26 Apr 2022 13:42:13 -0400 Received: from relay11.mail.gandi.net ([217.70.178.231]:44129) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njPCW-0003RM-22 for 55070@debbugs.gnu.org; Tue, 26 Apr 2022 13:42:12 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 547A5100008; Tue, 26 Apr 2022 17:42:03 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> Date: Tue, 26 Apr 2022 20:40:10 +0300 In-Reply-To: <83r15jltce.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 26 Apr 2022 19:09:21 +0300") Message-ID: <86sfpzspz4.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> ;; People don't expect emacs -nw, or --daemon, >> ;; to create graphical frames (bug#17693). >> ;; TODO perhaps there should be a separate value >> ;; for desktop-restore-frames to control this startup behavior? >> >> So this patch creates such separate values: > > Thanks, but I don't understand why you need the frameset part of the > patch. Because restoring frames on tty fails without this fix. > Or if you do need it, why does it have to look so ad-hoc? If > we want to support in frameset.el frames for which some frame > parameters make no sense, let's do that explicitly, not by sweeping > problems under the carpet by substituting some arbitrary values for > those parameters that give us trouble. These values are not arbitrary. The function frame-monitor-attributes used in the same fixed function frameset-move-onscreen returns on tty: ((geometry 0 0 80 23) (workarea 0 0 80 23)) where 'left' and 'top' values are zero. > IOW, in 10 years, would you be able to remember and explain why we use > zero instead of 'left' and 'top'? Adding a comment to the source code will help. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 26 14:14:59 2022 Received: (at 55070) by debbugs.gnu.org; 26 Apr 2022 18:14:59 +0000 Received: from localhost ([127.0.0.1]:40516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njPiF-0004Sq-EH for submit@debbugs.gnu.org; Tue, 26 Apr 2022 14:14:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49642) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njPiD-0004Sa-LO for 55070@debbugs.gnu.org; Tue, 26 Apr 2022 14:14:58 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:37012) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njPi7-0003bJ-5G; Tue, 26 Apr 2022 14:14:51 -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=LA6zLm/o+bpBWed76EdNTlkQMfPhrFWBbPkao2EXLoI=; b=k4SaXBR2oD62 r35VfpygjJ78u6IO59rR2aAbIAUufAI9eHYTm5EouhGU4G/QhCEjK6pvXiYY9RQjXp5r2sv2TcGkZ jBYdpuDtfeoZ3vlep2+PHeIHtR6kaXrAXXrFO5sTpGjEQfg1jfsk027Op2wG0gQQefjN8qbZRV8qS Strljlos0Dn0GUi3zKUWuYrWUjB52H40M9LpFSGaJAdQZS5lyABBTZ/WAY06pwOmmdkrbo23v74o8 1tI8EfFKYAc48kdjVbfWgQpeH8a5OwIdhgaR9i0zMFhvQc1I37I2U85QsuZ52lNTWzWsw9mw1zmFy DNtTDqKcGXLx7evd/MIfig==; Received: from [87.69.77.57] (port=2358 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 1njPi6-0001cH-LT; Tue, 26 Apr 2022 14:14:50 -0400 Date: Tue, 26 Apr 2022 21:14:37 +0300 Message-Id: <83o80nlnjm.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86sfpzspz4.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 26 Apr 2022 20:40:10 +0300) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: larsi@gnus.org, eric@swenson.org, 55070@debbugs.gnu.org > Date: Tue, 26 Apr 2022 20:40:10 +0300 > > >> ;; People don't expect emacs -nw, or --daemon, > >> ;; to create graphical frames (bug#17693). > >> ;; TODO perhaps there should be a separate value > >> ;; for desktop-restore-frames to control this startup behavior? > >> > >> So this patch creates such separate values: > > > > Thanks, but I don't understand why you need the frameset part of the > > patch. > > Because restoring frames on tty fails without this fix. Restoring frames is desktop.el's business, so it should be fixed there. Why does "emacs -nw" at all save frame coordinates if they cannot be restored? > > Or if you do need it, why does it have to look so ad-hoc? If > > we want to support in frameset.el frames for which some frame > > parameters make no sense, let's do that explicitly, not by sweeping > > problems under the carpet by substituting some arbitrary values for > > those parameters that give us trouble. > > These values are not arbitrary. The function frame-monitor-attributes > used in the same fixed function frameset-move-onscreen returns on tty: > > ((geometry 0 0 80 23) > (workarea 0 0 80 23)) > > where 'left' and 'top' values are zero. That is arbitrary as well. I hope we can find a more elegant and explicit solution to this issue. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 12:58:06 2022 Received: (at 55070) by debbugs.gnu.org; 27 Apr 2022 16:58:06 +0000 Received: from localhost ([127.0.0.1]:44173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njkzO-0003uL-GQ for submit@debbugs.gnu.org; Wed, 27 Apr 2022 12:58:06 -0400 Received: from relay5-d.mail.gandi.net ([217.70.183.197]:42445) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njkzK-0003sf-5u; Wed, 27 Apr 2022 12:58:03 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 1AA691C0005; Wed, 27 Apr 2022 16:57:53 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> Date: Wed, 27 Apr 2022 19:53:43 +0300 In-Reply-To: <83o80nlnjm.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 26 Apr 2022 21:14:37 +0300") Message-ID: <86fslysc14.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) tags 55070 + patch quit >> >> ;; People don't expect emacs -nw, or --daemon, >> >> ;; to create graphical frames (bug#17693). >> >> ;; TODO perhaps there should be a separate value >> >> ;; for desktop-restore-frames to control this startup behavior? >> >> >> >> So this patch creates such separate values: >> > >> > Thanks, but I don't understand why you need the frameset part of the >> > patch. >> >> Because restoring frames on tty fails without this fix. > > Restoring frames is desktop.el's business, so it should be fixed > there. The sole purpose of frameset.el is to save and restore frames. So the bug was fixed in frameset.el. > Why does "emacs -nw" at all save frame coordinates if they > cannot be restored? "emacs -nw" doesn't save frame coordinates. >> > Or if you do need it, why does it have to look so ad-hoc? If >> > we want to support in frameset.el frames for which some frame >> > parameters make no sense, let's do that explicitly, not by sweeping >> > problems under the carpet by substituting some arbitrary values for >> > those parameters that give us trouble. >> >> These values are not arbitrary. The function frame-monitor-attributes >> used in the same fixed function frameset-move-onscreen returns on tty: >> >> ((geometry 0 0 80 23) >> (workarea 0 0 80 23)) >> >> where 'left' and 'top' values are zero. > > That is arbitrary as well. > > I hope we can find a more elegant and explicit solution to this issue. I provided the patch to fix this bug. If you know how to fix it better, this would be fine. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 13:02:21 2022 Received: (at 55070) by debbugs.gnu.org; 27 Apr 2022 17:02:21 +0000 Received: from localhost ([127.0.0.1]:44187 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njl3U-00068l-Gq for submit@debbugs.gnu.org; Wed, 27 Apr 2022 13:02:20 -0400 Received: from mail-pj1-f48.google.com ([209.85.216.48]:45763) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njl3S-000635-OE for 55070@debbugs.gnu.org; Wed, 27 Apr 2022 13:02:19 -0400 Received: by mail-pj1-f48.google.com with SMTP id w17-20020a17090a529100b001db302efed6so711023pjh.4 for <55070@debbugs.gnu.org>; Wed, 27 Apr 2022 10:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swenson.org; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=BzwFnMkifl7RLXuoUrEbWltduBB1zZiVgqas8R3yknA=; b=slZkzYwzjfue+diqZW0V4V9BW6rrbwJfckjpL1VXViMoyjsmGQm7F71am/tYv8ihC4 z0Mm58zfbbFeh0++PEVJQ4yHPcnfwwPY1a1wLsbQdqIpyGT6krNYWw16viBe/z3lsCk+ 3G/4WC9EiGh0m+JzDEn/gBKRwJY95XNYZ1NWY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=BzwFnMkifl7RLXuoUrEbWltduBB1zZiVgqas8R3yknA=; b=hem7ToyPvTxM8wZjb3mnXxsheXM1lfzfLVJ+GLo3xZVghHx121mVdVs7iMBiswA8fg bS0PCrMJIgQUO8QciKuKkAFtvBp6rJXwP4KuXCHe0CGr7GmvA8/0svDzFV6ucROIDMjs yvXMpzEt15DQu7NmdNbeDqV5klCunjtanWDmdSPIYsj2A2HuCayHfUsQurPRhZBtMmAB c85sMGy463XmefbZ+3t9VpNqJ4QA5wHHxUUpTXFMEz3sAt3uo1cwFQCvD9u8aSJb5Geh /ZKttVd5yQDuBg/m1VBBibUf+NWYxFm4gNG9AAxMMHSnZXpjZOhB2oy5QeMHjabGkW/g CUaA== X-Gm-Message-State: AOAM533UIKQJAIR3HtvQxFZsixGb7Nb20EpPEPVR9BWH7Kn/R0g5/Lih 8OSpuxU6cLVb8qhyy1l1djn3Ww== X-Google-Smtp-Source: ABdhPJyzti/vzTRH0uimcWYZ2UPfmJhPBPRREveT5ueBlqElIHuD61aRvQT/yNIe5f8RJiSgieY+lQ== X-Received: by 2002:a17:902:c78b:b0:15c:e5dc:4f63 with SMTP id w11-20020a170902c78b00b0015ce5dc4f63mr23047704pla.90.1651078931851; Wed, 27 Apr 2022 10:02:11 -0700 (PDT) Received: from [192.168.0.111] (c-73-189-24-121.hsd1.ca.comcast.net. [73.189.24.121]) by smtp.gmail.com with ESMTPSA id b29-20020a62a11d000000b0050d8d39892bsm967817pff.166.2022.04.27.10.02.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Apr 2022 10:02:11 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.60.22041000 Date: Wed, 27 Apr 2022 10:02:09 -0700 Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs From: Eric Swenson To: Juri Linkov , Eli Zaretskii Message-ID: <19755688-1BC3-45A0-854D-031469E50DB9@swenson.org> Thread-Topic: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> In-Reply-To: <86fslysc14.fsf@mail.linkov.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Did you provide another patch, Juri? Or is it the same one you provided ye= sterday in this thread? -- Eric =EF=BB=BFOn 4/27/22, 9:57 AM, "Juri Linkov" wrote: tags 55070 + patch quit >> >> ;; People don't expect emacs -nw, or --daemon, >> >> ;; to create graphical frames (bug#17693). >> >> ;; TODO perhaps there should be a separate value >> >> ;; for desktop-restore-frames to control this startup behavior? >> >> >> >> So this patch creates such separate values: >> > >> > Thanks, but I don't understand why you need the frameset part of t= he >> > patch. >> >> Because restoring frames on tty fails without this fix. > > Restoring frames is desktop.el's business, so it should be fixed > there. The sole purpose of frameset.el is to save and restore frames. So the bug was fixed in frameset.el. > Why does "emacs -nw" at all save frame coordinates if they > cannot be restored? "emacs -nw" doesn't save frame coordinates. >> > Or if you do need it, why does it have to look so ad-hoc? If >> > we want to support in frameset.el frames for which some frame >> > parameters make no sense, let's do that explicitly, not by sweepin= g >> > problems under the carpet by substituting some arbitrary values fo= r >> > those parameters that give us trouble. >> >> These values are not arbitrary. The function frame-monitor-attribut= es >> used in the same fixed function frameset-move-onscreen returns on tt= y: >> >> ((geometry 0 0 80 23) >> (workarea 0 0 80 23)) >> >> where 'left' and 'top' values are zero. > > That is arbitrary as well. > > I hope we can find a more elegant and explicit solution to this issue= . I provided the patch to fix this bug. If you know how to fix it better, this would be fine. From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 27 13:17:04 2022 Received: (at 55070) by debbugs.gnu.org; 27 Apr 2022 17:17:04 +0000 Received: from localhost ([127.0.0.1]:44211 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njlHj-0006eN-UF for submit@debbugs.gnu.org; Wed, 27 Apr 2022 13:17:04 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njlHi-0006dr-Rr for 55070@debbugs.gnu.org; Wed, 27 Apr 2022 13:17:03 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60986) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1njlHd-0000Bb-5E; Wed, 27 Apr 2022 13:16:57 -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=NCYtyttmuSC/VhvOmkty+PP442lWyxxPUGV4ZU+MUtA=; b=FsuxlE0w/UUF gIcLgkEI4nabhg9YFEH6/GFFv9D3SZrvhJZ3Nl84iVP0ZSnc7rcEmzcPZGIFPP/dxs1Kyc6P3xqev BKjNNgBvZoH7PSvHyB+CtlEcbJLD/D4/NkD5WKSUhRRlbo9D0jMrkNiCfCh1QuntljL7JAIak+Jwt HuJ4ZeppxWgcdcOZguE+ne4Mgi2iaO9vIegahMmNPsc8HnSisbPwWX89WcwE0FID4Wvuy7qSMxKRQ gf5TfV2pvMTWRtkWHs/42c/DQSNj0vWqfi1DgBZtrmkLR4tYzCbWo5KDJW39L7oeQE4uSL2lOhA90 TCDClepM5NsZ0b7ngwRmSw==; Received: from [87.69.77.57] (port=2937 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 1njlHb-0001Ji-Mv; Wed, 27 Apr 2022 13:16:56 -0400 Date: Wed, 27 Apr 2022 20:16:45 +0300 Message-Id: <83wnfabg5e.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86fslysc14.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 27 Apr 2022 19:53:43 +0300) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: larsi@gnus.org, eric@swenson.org, 55070@debbugs.gnu.org > Date: Wed, 27 Apr 2022 19:53:43 +0300 > > >> > Thanks, but I don't understand why you need the frameset part of the > >> > patch. > >> > >> Because restoring frames on tty fails without this fix. > > > > Restoring frames is desktop.el's business, so it should be fixed > > there. > > The sole purpose of frameset.el is to save and restore frames. > So the bug was fixed in frameset.el. If you want to teach frameset.el to deal with TTY frames, the patch should explicitly test for TTY frames _inside_ frameset.el. The way you proposed to fix it will do the same on GUI frames, where this situation _should_ signal an error. > > Why does "emacs -nw" at all save frame coordinates if they > > cannot be restored? > > "emacs -nw" doesn't save frame coordinates. Then the fix you proposed cannot help the OP, AFAIU, because his use case was to always use -nw sessions. > > I hope we can find a more elegant and explicit solution to this issue. > > I provided the patch to fix this bug. > If you know how to fix it better, this would be fine. I suggested a way to fix it. I'm not saying my suggestion is the only possible solution, but it's IMO better than what you proposed in at least one aspect. From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 03:09:17 2022 Received: (at 55070) by debbugs.gnu.org; 28 Apr 2022 07:09:17 +0000 Received: from localhost ([127.0.0.1]:45119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njyH7-0006di-JG for submit@debbugs.gnu.org; Thu, 28 Apr 2022 03:09:17 -0400 Received: from relay1-d.mail.gandi.net ([217.70.183.193]:37113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1njyH6-0006dT-1v for 55070@debbugs.gnu.org; Thu, 28 Apr 2022 03:09:16 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 7651A240014; Thu, 28 Apr 2022 07:09:07 +0000 (UTC) From: Juri Linkov To: Eric Swenson Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> Date: Thu, 28 Apr 2022 10:01:01 +0300 In-Reply-To: <19755688-1BC3-45A0-854D-031469E50DB9@swenson.org> (Eric Swenson's message of "Wed, 27 Apr 2022 10:02:09 -0700") Message-ID: <861qxhy9cz.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain > Did you provide another patch, Juri? > Or is it the same one you provided yesterday in this thread? It's the same patch. Please try it. Here it's again: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=desktop-restore-frames.patch diff --git a/lisp/desktop.el b/lisp/desktop.el index f41a41c3c3..15cd0bae89 100644 --- a/lisp/desktop.el +++ b/lisp/desktop.el @@ -412,7 +412,10 @@ desktop-restore-frames "When non-nil, save and restore the frame and window configuration. See related options `desktop-restore-reuses-frames', `desktop-restore-in-current-display', and `desktop-restore-forces-onscreen'." - :type 'boolean + :type '(choice (const :tag "Don't restore frames" nil) + (const :tag "Restore frames" t) + (const :tag "Restore only graphical frames" x) + (const :tag "Restore only -nw frames" tty)) :group 'desktop :version "24.4") @@ -1251,7 +1254,13 @@ desktop-lazy-timer ;; ---------------------------------------------------------------------------- (defun desktop-restoring-frameset-p () "True if calling `desktop-restore-frameset' will actually restore it." - (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t)) + (and (pcase desktop-restore-frames + ('x (display-graphic-p)) + ('tty (not (display-graphic-p))) + ('nil nil) + (_ t)) + desktop-saved-frameset + t)) (defun desktop-restore-frameset () "Restore the state of a set of frames. diff --git a/lisp/frameset.el b/lisp/frameset.el index 05884eed3a..32966376d8 100644 --- a/lisp/frameset.el +++ b/lisp/frameset.el @@ -883,8 +883,8 @@ frameset-move-onscreen (pcase-let* ((`(,left ,top ,width ,height) (cdadr (frame-monitor-attributes frame))) (right (+ left width -1)) (bottom (+ top height -1)) - (fr-left (frameset-compute-pos (frame-parameter frame 'left) left right)) - (fr-top (frameset-compute-pos (frame-parameter frame 'top) top bottom)) + (fr-left (frameset-compute-pos (or (frame-parameter frame 'left) 0) left right)) + (fr-top (frameset-compute-pos (or (frame-parameter frame 'top) 0) top bottom)) (ch-width (frame-char-width frame)) (ch-height (frame-char-height frame)) (fr-width (max (frame-pixel-width frame) (* ch-width (frame-width frame)))) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 12:19:09 2022 Received: (at 55070) by debbugs.gnu.org; 28 Apr 2022 16:19:09 +0000 Received: from localhost ([127.0.0.1]:49754 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk6rF-0008SI-BW for submit@debbugs.gnu.org; Thu, 28 Apr 2022 12:19:09 -0400 Received: from mail-pf1-f174.google.com ([209.85.210.174]:38833) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk6rD-0008Ru-Gu for 55070@debbugs.gnu.org; Thu, 28 Apr 2022 12:19:07 -0400 Received: by mail-pf1-f174.google.com with SMTP id g8so2257900pfh.5 for <55070@debbugs.gnu.org>; Thu, 28 Apr 2022 09:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swenson.org; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=NGWcemsqzqKu7mXKLr038tp8AP2f+nqJBfUxlxb4Tw4=; b=e8r6Fjb058Gf7qJYGrDU/cZUfkJhrtKDl76isVGGK89+vLrKfSyKuTt9mmmjVmVIxu dgtLGtkSd3ct6RP7mhrYlp3AEslXHKMcy0ppYYSqGRKlD+a1pgKe7wd1l6FztKalnoX/ jeKVOqMIo0rZ6BrTuTpOzXLPFnhka6b8tRgmE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=NGWcemsqzqKu7mXKLr038tp8AP2f+nqJBfUxlxb4Tw4=; b=q/S8CMNIPkRRbagkeyzM+rQrpBon03Ahh+eziCzeUBXr4MSlkCqOYI/KYiUmzDSsR6 TfZhnr3lfcsvBuE8Cz1BnhtuXYIMUAW+woAO/CVFVByQCOJv2HiR4uu62TQdRLuRLGgc 435EIhJpMuiPIst3tJIGIOnDnXN/JcSzb+c+yEul/eteiNb/qUE1pbp+GA6xS4XEwwkC vtwbFkwEjKKgQucYD5Ls+gqcZ5w+TkifdszeYuztLWZcv4rPKK53GifHHuosy5/5m9Dk hT+AoCdYfBaHbB+ozk+gu4D+H0ZCMH5EV40QEPhQzZKGiQPc9ms5T5JVz8wkvT2WVSAd ge1Q== X-Gm-Message-State: AOAM5322SRho1xKW7LZ11vmuSgp1wh8HXbQrMunkHdCU36/OTyvbR8En yvY2+zLfR4T5HfYbINFdbfyokQ== X-Google-Smtp-Source: ABdhPJz/fJ00qRtS17ZevvdOOsjdoaXush/fQNSn9VKg3esydy05U8SGIuc2lmJaX6kAYE+Bn5kWKg== X-Received: by 2002:a63:df18:0:b0:3ab:938b:e6c5 with SMTP id u24-20020a63df18000000b003ab938be6c5mr11234261pgg.165.1651162740658; Thu, 28 Apr 2022 09:19:00 -0700 (PDT) Received: from [192.168.0.111] (c-73-189-24-121.hsd1.ca.comcast.net. [73.189.24.121]) by smtp.gmail.com with ESMTPSA id 16-20020a621410000000b0050aca5f79f5sm307509pfu.97.2022.04.28.09.18.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Apr 2022 09:19:00 -0700 (PDT) User-Agent: Microsoft-MacOutlook/16.60.22041000 Date: Thu, 28 Apr 2022 09:18:59 -0700 Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs From: Eric Swenson To: Juri Linkov Message-ID: <5DA5751F-DC2F-4C40-AE30-DAF65BCF0572@swenson.org> Thread-Topic: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> In-Reply-To: <861qxhy9cz.fsf@mail.linkov.net> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) The patch worked great for me. I can restore saved sessions in both GUI an= d -nw mode. Thanks much. -- Eric =EF=BB=BFOn 4/28/22, 12:09 AM, "Juri Linkov" wrote: > Did you provide another patch, Juri? > Or is it the same one you provided yesterday in this thread? It's the same patch. Please try it. Here it's again: diff --git a/lisp/desktop.el b/lisp/desktop.el index f41a41c3c3..15cd0bae89 100644 --- a/lisp/desktop.el +++ b/lisp/desktop.el @@ -412,7 +412,10 @@ desktop-restore-frames "When non-nil, save and restore the frame and window configuration. See related options `desktop-restore-reuses-frames', `desktop-restore-in-current-display', and `desktop-restore-forces-onsc= reen'." - :type 'boolean + :type '(choice (const :tag "Don't restore frames" nil) + (const :tag "Restore frames" t) + (const :tag "Restore only graphical frames" x) + (const :tag "Restore only -nw frames" tty)) :group 'desktop :version "24.4") @@ -1251,7 +1254,13 @@ desktop-lazy-timer ;; -------------------------------------------------------------------= --------- (defun desktop-restoring-frameset-p () "True if calling `desktop-restore-frameset' will actually restore it= ." - (and desktop-restore-frames desktop-saved-frameset (display-graphic-= p) t)) + (and (pcase desktop-restore-frames + ('x (display-graphic-p)) + ('tty (not (display-graphic-p))) + ('nil nil) + (_ t)) + desktop-saved-frameset + t)) (defun desktop-restore-frameset () "Restore the state of a set of frames. diff --git a/lisp/frameset.el b/lisp/frameset.el index 05884eed3a..32966376d8 100644 --- a/lisp/frameset.el +++ b/lisp/frameset.el @@ -883,8 +883,8 @@ frameset-move-onscreen (pcase-let* ((`(,left ,top ,width ,height) (cdadr (frame-monitor-att= ributes frame))) (right (+ left width -1)) (bottom (+ top height -1)) - (fr-left (frameset-compute-pos (frame-parameter frame 'left) l= eft right)) - (fr-top (frameset-compute-pos (frame-parameter frame 'top) top= bottom)) + (fr-left (frameset-compute-pos (or (frame-parameter frame 'lef= t) 0) left right)) + (fr-top (frameset-compute-pos (or (frame-parameter frame 'top)= 0) top bottom)) (ch-width (frame-char-width frame)) (ch-height (frame-char-height frame)) (fr-width (max (frame-pixel-width frame) (* ch-width (frame-wi= dth frame)))) From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 28 14:03:35 2022 Received: (at 55070) by debbugs.gnu.org; 28 Apr 2022 18:03:35 +0000 Received: from localhost ([127.0.0.1]:49881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk8UJ-0002hz-5n for submit@debbugs.gnu.org; Thu, 28 Apr 2022 14:03:35 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:39011) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nk8UG-0002hG-7d for 55070@debbugs.gnu.org; Thu, 28 Apr 2022 14:03:32 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id D9B6D200003; Thu, 28 Apr 2022 18:03:24 +0000 (UTC) From: Juri Linkov To: Eric Swenson Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> Date: Thu, 28 Apr 2022 20:39:46 +0300 In-Reply-To: <5DA5751F-DC2F-4C40-AE30-DAF65BCF0572@swenson.org> (Eric Swenson's message of "Thu, 28 Apr 2022 09:18:59 -0700") Message-ID: <86a6c56ra5.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: 55070@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > The patch worked great for me. I can restore saved sessions > in both GUI and -nw mode. Thanks much. Thanks for confirming that the patch fixed the bug. Then let's wait when Eli will finish writing a better patch that does the same. From debbugs-submit-bounces@debbugs.gnu.org Sat Apr 30 04:42:51 2022 Received: (at 55070) by debbugs.gnu.org; 30 Apr 2022 08:42:51 +0000 Received: from localhost ([127.0.0.1]:55846 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkigk-00020n-Kd for submit@debbugs.gnu.org; Sat, 30 Apr 2022 04:42:50 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56134) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nkigi-00020a-RS for 55070@debbugs.gnu.org; Sat, 30 Apr 2022 04:42:49 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:41650) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nkigc-0005me-Ou; Sat, 30 Apr 2022 04:42: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=5xjpqB4rFYJFlBE4p0DxugWQtixDMZHsyVhiy7bjpDk=; b=h7OkuDJ1PNw8 f8kMcSLxsgrSph/FTlQ/bpz2SUg/NhUqcVloufyZT0zRR7OZVgoZyH84vECNUOwg+tBxCl2RToogh XVRRNNZ+vtsenELdULB1CcZ2aSCZJPh4fpiTOLZVp8JqmkcrA3778NzyeWxlzfSSoDT/eQjY9nnBw W0qIGR7GQiSIUU2mkp3mlOOMGXzqB6zGBahRQ2eTNFUKsxv1sg/9SWEAblWPZJBQSl0uDetoXOgwB bsh4Ps5bc5JGKCinL82y2cJwqqDTO+A8iEoWexqYXpwg8oScGVsWCmpCF64CIEZRBGzjMIco4zC6I AAPXHdbfNeWDQwax4TCNLw==; Received: from [87.69.77.57] (port=2779 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 1nkigc-0005zN-7J; Sat, 30 Apr 2022 04:42:42 -0400 Date: Sat, 30 Apr 2022 11:42:45 +0300 Message-Id: <83wnf77yii.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86a6c56ra5.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 28 Apr 2022 20:39:46 +0300) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: Eli Zaretskii , , <55070@debbugs.gnu.org> > Date: Thu, 28 Apr 2022 20:39:46 +0300 > > > The patch worked great for me. I can restore saved sessions > > in both GUI and -nw mode. Thanks much. > > Thanks for confirming that the patch fixed the bug. > Then let's wait when Eli will finish writing a better patch > that does the same. Please try the patch below. Its main idea is that calling frameset-move-onscreen makes no sense on a text-mode display, so I made desktop.el force frameset.el avoid calling that function in this case. The rest is basically a simple cleanup. In addition to testing the use case of both saving and restoring the desktop in a -nw session, I'd appreciate testing when the desktop was saved in a GUI session and is restored in a TTY session, and vice versa. Likewise for when the session in which the desktop is restored is a daemon session -- the main concern there is that a daemon session shouldn't restore frames at all. Thanks. diff --git a/lisp/desktop.el b/lisp/desktop.el index f41a41c..e438b98 100644 --- a/lisp/desktop.el +++ b/lisp/desktop.el @@ -434,7 +434,9 @@ desktop-restore-forces-onscreen Note that checking of frame boundaries is only approximate. It can fail to reliably detect frames whose onscreen/offscreen state depends on a few pixels, especially near the right / bottom borders -of the screen." +of the screen. +Text-mode frames are always considered onscreen, so this option has +no effect on restoring frames in a non-GUI session." :type '(choice (const :tag "Only fully offscreen frames" t) (const :tag "Also partially offscreen frames" all) (const :tag "Do not force frames onscreen" nil)) @@ -1251,7 +1253,11 @@ desktop-lazy-timer ;; ---------------------------------------------------------------------------- (defun desktop-restoring-frameset-p () "True if calling `desktop-restore-frameset' will actually restore it." - (and desktop-restore-frames desktop-saved-frameset (display-graphic-p) t)) + (and desktop-restore-frames desktop-saved-frameset + ;; Don't restore frames when the selected frame is the daemon's + ;; initial frame. + (not (and (daemonp) (not (frame-parameter nil 'client)))) + t)) (defun desktop-restore-frameset () "Restore the state of a set of frames. @@ -1262,7 +1268,8 @@ desktop-restore-frameset :reuse-frames (eq desktop-restore-reuses-frames t) :cleanup-frames (not (eq desktop-restore-reuses-frames 'keep)) :force-display desktop-restore-in-current-display - :force-onscreen desktop-restore-forces-onscreen))) + :force-onscreen (and desktop-restore-forces-onscreen + (display-graphic-p))))) ;; Just to silence the byte compiler. ;; Dynamically bound in `desktop-read'. diff --git a/lisp/frameset.el b/lisp/frameset.el index 05884ee..c97cef0 100644 --- a/lisp/frameset.el +++ b/lisp/frameset.el @@ -448,6 +448,7 @@ frameset-session-filter-alist (defvar frameset-persistent-filter-alist (append '((background-color . frameset-filter-sanitize-color) + (bottom . frameset-filter-shelve-param) (buffer-list . :never) (buffer-predicate . :never) (buried-buffer-list . :never) @@ -464,13 +465,20 @@ frameset-persistent-filter-alist (frameset--text-pixel-height . :save) (frameset--text-pixel-width . :save) (fullscreen . frameset-filter-shelve-param) + (GUI:bottom . frameset-filter-unshelve-param) (GUI:font . frameset-filter-unshelve-param) (GUI:fullscreen . frameset-filter-unshelve-param) (GUI:height . frameset-filter-unshelve-param) + (GUI:left . frameset-filter-unshelve-param) + (GUI:right . frameset-filter-unshelve-param) + (GUI:top . frameset-filter-unshelve-param) (GUI:width . frameset-filter-unshelve-param) (height . frameset-filter-shelve-param) + (left . frameset-filter-shelve-param) (parent-frame . :never) (mouse-wheel-frame . :never) + (right . frameset-filter-shelve-param) + (top . frameset-filter-shelve-param) (tty . frameset-filter-tty-to-GUI) (tty-type . frameset-filter-tty-to-GUI) (width . frameset-filter-shelve-param) From debbugs-submit-bounces@debbugs.gnu.org Sun May 01 13:48:22 2022 Received: (at 55070) by debbugs.gnu.org; 1 May 2022 17:48:22 +0000 Received: from localhost ([127.0.0.1]:34118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlDgE-0000V7-4S for submit@debbugs.gnu.org; Sun, 01 May 2022 13:48:22 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:33795) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlDgC-0000Uh-RU for 55070@debbugs.gnu.org; Sun, 01 May 2022 13:48:21 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id EB2501BF204; Sun, 1 May 2022 17:48:12 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> Date: Sun, 01 May 2022 20:25:52 +0300 In-Reply-To: <83wnf77yii.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Apr 2022 11:42:45 +0300") Message-ID: <86wnf5f8of.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > Please try the patch below. Its main idea is that calling > frameset-move-onscreen makes no sense on a text-mode display, so I > made desktop.el force frameset.el avoid calling that function in this > case. The rest is basically a simple cleanup. The patch works without problems (I didn't notice the argument :force-onscreen before). > In addition to testing the use case of both saving and restoring the > desktop in a -nw session, I'd appreciate testing when the desktop was > saved in a GUI session and is restored in a TTY session, and vice > versa. Saving the desktop in a GUI session and restoring in a TTY session adds an empty line between the top buffer and the tab bar when tab-bar-mode was enabled before saving. Saving the desktop in a TTY session and restoring in a GUI session restores only the first frame, but the message says 2 frames were restored. > Likewise for when the session in which the desktop is restored > is a daemon session -- the main concern there is that a daemon session > shouldn't restore frames at all. I don't use a daemon session, maybe someone could help to test it. From debbugs-submit-bounces@debbugs.gnu.org Tue May 03 12:31:03 2022 Received: (at 55070) by debbugs.gnu.org; 3 May 2022 16:31:03 +0000 Received: from localhost ([127.0.0.1]:40827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlvQU-0004F7-Rh for submit@debbugs.gnu.org; Tue, 03 May 2022 12:31:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54144) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlvQS-00047A-Nm for 55070@debbugs.gnu.org; Tue, 03 May 2022 12:31:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60926) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nlvQM-0000Y3-6I; Tue, 03 May 2022 12:30:54 -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=YdNMpBVLaynnVHAwnF/JOIrh6BhoVS85jC6ap2kTvH4=; b=semBG1t/sd2E KnQHl2nJHVPnhYuNAa3I9IYQ02MPl9fT1bj0WfLBsjM5GdDw+73guFn46JQXLPtEWUMogLexUr9om IbyedQzbCC8m8BupEP+hFX2lfQlVYXVwz9iRNULYQF4HarIJhjm3WystAKVIwIEMtYqZHD6FCSSBf /0oVQcqnzxFnRcTQzLFqeTcHipj+udKlxtmKgTWtYZWY5uCvh7O50TnP03ZGGKsldcw0TyhCvBAh0 JTwAzLwRyl2I68cwmX71awwyhoG77AeLRtTy9MeKm2/3Bcwo6I3CHgbJGzy62UFnTvaynoo4/dH3w LnZ466vBwwKs4Rb6i/6ZiQ==; Received: from [87.69.77.57] (port=4795 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 1nlvQI-0006Eb-Lm; Tue, 03 May 2022 12:30:52 -0400 Date: Tue, 03 May 2022 19:31:01 +0300 Message-Id: <83levi4lyy.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86wnf5f8of.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 01 May 2022 20:25:52 +0300) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: eric@swenson.org, larsi@gnus.org, 55070@debbugs.gnu.org > Date: Sun, 01 May 2022 20:25:52 +0300 > > > Please try the patch below. Its main idea is that calling > > frameset-move-onscreen makes no sense on a text-mode display, so I > > made desktop.el force frameset.el avoid calling that function in this > > case. The rest is basically a simple cleanup. > > The patch works without problems (I didn't notice > the argument :force-onscreen before). > > > In addition to testing the use case of both saving and restoring the > > desktop in a -nw session, I'd appreciate testing when the desktop was > > saved in a GUI session and is restored in a TTY session, and vice > > versa. > > Saving the desktop in a GUI session and restoring in a TTY session > adds an empty line between the top buffer and the tab bar when > tab-bar-mode was enabled before saving. This is a subtle bug in how we compute the tab-bar-lines frame parameter. Observe: emacs -Q M-x tab-bar-mode RET M-: (frame-parameter nil 'tab-bar-lines) => 2 Surprise! The problem is that the tab-bar line is slightly higher than the canonical line height of the frame, so when we compute the height in lines, we get 1 more. 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. I hope you can develop such a solution, so that tab bars could be meaningfully restored on TTY frames. Btw, what about tab-bar-show -- should it be saved as well? at least if its value is not the default? > Saving the desktop in a TTY session and restoring in a GUI session > restores only the first frame, but the message says 2 frames were restored. It did restore 2 frames (try evaluating '(frame-list)' and you will see). It's just that all the frames but the first one are invisible, because the frames restored from TTY-originated desktop have no 'visibility' parameter, so when they are restored on GUI display, that is interpreted as invisible frames. I think I fixed that now. > > Likewise for when the session in which the desktop is restored > > is a daemon session -- the main concern there is that a daemon session > > shouldn't restore frames at all. > > I don't use a daemon session, maybe someone could help to test it. OK, maybe Eric or someone else will. Anyway, I installed the changes on the master branch. I think we should leave this bug open until the tab-bar issue (and any other issues that might be left) are resolved. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue May 03 14:00:19 2022 Received: (at 55070) by debbugs.gnu.org; 3 May 2022 18:00:19 +0000 Received: from localhost ([127.0.0.1]:40998 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlwos-0001os-Kj for submit@debbugs.gnu.org; Tue, 03 May 2022 14:00:19 -0400 Received: from relay8-d.mail.gandi.net ([217.70.183.201]:35235) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nlwoq-0001oP-RQ for 55070@debbugs.gnu.org; Tue, 03 May 2022 14:00:17 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 18C4E1BF20B; Tue, 3 May 2022 18:00:08 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> Date: Tue, 03 May 2022 20:57:52 +0300 In-Reply-To: <83levi4lyy.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 03 May 2022 19:31:01 +0300") Message-ID: <86pmkufql3.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Saving the desktop in a GUI session and restoring in a TTY session >> adds an empty line between the top buffer and the tab bar when >> tab-bar-mode was enabled before saving. > > This is a subtle bug in how we compute the tab-bar-lines frame > parameter. Observe: > > emacs -Q > M-x tab-bar-mode RET > M-: (frame-parameter nil 'tab-bar-lines) => 2 > > Surprise! > > The problem is that the tab-bar line is slightly higher than the > canonical line height of the frame, so when we compute the height in > lines, we get 1 more. > > 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. > 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. > 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). So maybe desktop.el should call tab-bar--update-tab-bar-lines too. 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? From debbugs-submit-bounces@debbugs.gnu.org Tue May 03 14:28:50 2022 Received: (at 55070) by debbugs.gnu.org; 3 May 2022 18:28:50 +0000 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 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 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==; 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 Date: Tue, 03 May 2022 21:28:51 +0300 Message-Id: <83fslq4gik.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86pmkufql3.fsf@mail.linkov.net> (message from Juri Linkov on Tue, 03 May 2022 20:57:52 +0300) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From debbugs-submit-bounces@debbugs.gnu.org Thu May 05 12:38:55 2022 Received: (at 55070) by debbugs.gnu.org; 5 May 2022 16:38:55 +0000 Received: from localhost ([127.0.0.1]:46341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmeVD-0007ea-0e for submit@debbugs.gnu.org; Thu, 05 May 2022 12:38:55 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:60529) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmeVB-0007e9-QI for 55070@debbugs.gnu.org; Thu, 05 May 2022 12:38:54 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id EE2C420003; Thu, 5 May 2022 16:38:45 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> <83fslq4gik.fsf@gnu.org> Date: Thu, 05 May 2022 19:35:06 +0300 In-Reply-To: <83fslq4gik.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 03 May 2022 21:28:51 +0300") Message-ID: <86ilqkrntx.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain >> 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. So now this is implemented in the attached patch. The call to tab-bar-mode takes care about recalculating the correct values of the tab-bar-line frame parameter. >> 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. The same call to tab-bar-mode also takes care about creating the buttons. >> 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? tab-bar-mode takes care about future frames by adjusting default-frame-alist. >> 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. Right, the users can change the order in their init files to customize this behavior. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=desktop-tab-bar-mode.patch diff --git a/lisp/desktop.el b/lisp/desktop.el index e438b98c0e..0f1e3f289a 100644 --- a/lisp/desktop.el +++ b/lisp/desktop.el @@ -1269,7 +1269,12 @@ desktop-restore-frameset :cleanup-frames (not (eq desktop-restore-reuses-frames 'keep)) :force-display desktop-restore-in-current-display :force-onscreen (and desktop-restore-forces-onscreen - (display-graphic-p))))) + (display-graphic-p))) + (when (seq-some + (lambda (frame) + (menu-bar-positive-p (frame-parameter frame 'tab-bar-lines))) + (frame-list)) + (tab-bar-mode 1)))) ;; Just to silence the byte compiler. ;; Dynamically bound in `desktop-read'. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 05 12:51:23 2022 Received: (at 55070) by debbugs.gnu.org; 5 May 2022 16:51:23 +0000 Received: from localhost ([127.0.0.1]:46389 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmehG-00082R-UG for submit@debbugs.gnu.org; Thu, 05 May 2022 12:51:23 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmehE-000827-Vz for 55070@debbugs.gnu.org; Thu, 05 May 2022 12:51:21 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:54888) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nmeh8-0005tV-Jn; Thu, 05 May 2022 12:51:14 -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=f/HTxwAleaCuN+hXohHSIpHj5YfcoqUDYuNFMIVOUto=; b=CxxRk+6DdBeS iqoSVVVuTbucT/jAwLocPENb2M5Z8bCbsY15L6dzDdkq3I8fQOtVo+ORMBvo0ir86o7gCTBUiZF1p iEEsHUa5O5N+lbxKNqxecUkpQbDnLBZ/o8SlG68JONBPqZKkYsCt6XGoOgxD7LWNLzsj31WV/3r2Q 0x9n+jvlZYqe01PILwaa9EDaS2EzoBvFuB0oz2GRwC9bFvxdmtcMHn5N994/1kytEAuJdP2slq0U2 0EB955UIXboeVNifrKNpDAYJ423RO1oCohTCCTjGLCUqd/OVmb2JINCl7ZHfXNrUvHRf/WbM+vrNh JmuE0UEGYsulj556zT/AYQ==; Received: from [87.69.77.57] (port=1512 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 1nmeh7-0007Bf-T4; Thu, 05 May 2022 12:51:14 -0400 Date: Thu, 05 May 2022 19:51:00 +0300 Message-Id: <834k233ouj.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <86ilqkrntx.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 05 May 2022 19:35:06 +0300) Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs 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> <83fslq4gik.fsf@gnu.org> <86ilqkrntx.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: eric@swenson.org, larsi@gnus.org, 55070@debbugs.gnu.org > Date: Thu, 05 May 2022 19:35:06 +0300 > > >> 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. > > So now this is implemented in the attached patch. The call to > tab-bar-mode takes care about recalculating the correct values > of the tab-bar-line frame parameter. Thanks, it LGTM, but please explain in a comment to that code why this has to be done when restoring frames. From debbugs-submit-bounces@debbugs.gnu.org Thu May 05 14:09:30 2022 Received: (at 55070) by debbugs.gnu.org; 5 May 2022 18:09:30 +0000 Received: from localhost ([127.0.0.1]:46446 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmfus-0001fA-Hj for submit@debbugs.gnu.org; Thu, 05 May 2022 14:09:30 -0400 Received: from relay12.mail.gandi.net ([217.70.178.232]:32963) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nmfuq-0001er-IR; Thu, 05 May 2022 14:09:28 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 31798200009; Thu, 5 May 2022 18:09:20 +0000 (UTC) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#55070: 28.1; desktop-load doesn't work in -nw (non-gui) emacs Organization: LINKOV.NET 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> <83fslq4gik.fsf@gnu.org> <86ilqkrntx.fsf@mail.linkov.net> <834k233ouj.fsf@gnu.org> Date: Thu, 05 May 2022 21:08:57 +0300 In-Reply-To: <834k233ouj.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 05 May 2022 19:51:00 +0300") Message-ID: <86ilqjrgw6.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 55070 Cc: eric@swenson.org, 55070@debbugs.gnu.org, larsi@gnus.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) close 55070 29.0.50 thanks >> So now this is implemented in the attached patch. The call to >> tab-bar-mode takes care about recalculating the correct values >> of the tab-bar-line frame parameter. > > Thanks, it LGTM, but please explain in a comment to that code why this > has to be done when restoring frames. Done. From unknown Fri Aug 15 03:57:33 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 03 Jun 2022 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator