From: Juanma Barranquero <lekktu@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Emacs developers <emacs-devel@gnu.org>
Subject: Re: GUI vs TTY when saving & restoring framesets
Date: Mon, 23 Jan 2017 15:15:52 +0100 [thread overview]
Message-ID: <CAAeL0SQcAONrk4UZKtG2J0j2CGOAdRBfqOwNVYgO9TvjRuxCPg@mail.gmail.com> (raw)
In-Reply-To: <83d1fe4fcq.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2483 bytes --]
On Mon, Jan 23, 2017 at 4:36 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> That's fine with me, but if you read bug#17693, you will see that the
> original report there explicitly describes a situation where GUI
> frames were created by restoring desktop in a -nw session.
It wasn't the intention. OTOH, as a -nw session on GNU/Linux can have both
GUI and tty frames, I'm not sure it is a bug, just we're entering
unspecified territory. I mean, what if the user creates a GUI frame from a
-nw session, and then exits and reenters Emacs in -nw mode. Shouldn't the
GUI frame be restored too? We haven't decided (likely because the issue
didn't present itself earlier than that bug report) how to deal when
running mixed frames' instances.
Thinking about these issues, I suddenly realized that, if we were to treat
-nw and GUI sessions as different (frameset-wise, I mean), we could just
save the GUI frameset and the -nw frameset as distinct entities in the
desktop file, and just restore the one appropriate. No mixing.
Currently, if you have an emacs GUI instance with frames A, B, and C. exit
it, then enter a -nw session, frameset-restore tries to create frames A',
B' and C' which share as many characteristics from A, B and C as possible.
Obviously not size or position, but windows, buffers shown in them, etc.
Then you return to GUI and get back A, B and C (assuming the -nw session
didn't change or delete them). Well, it's not what happens *now*, but it is
how the code was designed to perform.
But, is that what the user expects? Wouldn't it be easier to keep these
kinds of sessions apart?
Additionally, frameset.el is designed to allow manipulation of framesets as
objects, meaning that nothing precludes saving several of them (either in
the desktop save file, or another file) with some kind of user identifier
(a name or whatever) and then restoring on demand the desired frameset.
It's just that desktop.el takes the easiest route, which is to save and
restore a single frameset. But perhaps this isn't how we should be doing it.
All of this (bugs aside) is easy to implement, but before changing one line
of code we should know what we want.
> Because the original code had worse problems, and we didn't know how
> to fix it better than that.
Wouldn't want anyone to believe that I was complaining or belittling you or
anyone who had to deal with these bugs, I'm deeply sorry. Not my intention
at all. It's me who wrote the code and went MIA. My fault entirely.
[-- Attachment #2: Type: text/html, Size: 2884 bytes --]
next prev parent reply other threads:[~2017-01-23 14:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-22 4:21 GUI vs TTY when saving & restoring framesets Juanma Barranquero
2017-01-22 4:23 ` Juanma Barranquero
2017-01-22 13:27 ` Alan Mackenzie
2017-01-22 16:31 ` Eli Zaretskii
2017-01-22 18:00 ` Alan Mackenzie
2017-01-22 18:14 ` Eli Zaretskii
2017-01-22 18:55 ` Alan Mackenzie
2017-01-22 19:11 ` Eli Zaretskii
2017-01-22 19:38 ` Alan Mackenzie
2017-01-22 20:03 ` Eli Zaretskii
2017-01-22 20:44 ` Alan Mackenzie
2017-01-22 21:06 ` Juanma Barranquero
2017-01-23 17:39 ` Andreas Schwab
2017-01-23 18:02 ` martin rudalics
2017-01-22 16:23 ` Eli Zaretskii
2017-01-22 21:15 ` Juanma Barranquero
2017-01-23 3:36 ` Eli Zaretskii
2017-01-23 14:15 ` Juanma Barranquero [this message]
2017-01-23 15:49 ` Eli Zaretskii
2017-01-23 16:14 ` Juanma Barranquero
2017-01-23 16:16 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAeL0SQcAONrk4UZKtG2J0j2CGOAdRBfqOwNVYgO9TvjRuxCPg@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).