From: Eli Zaretskii <eliz@gnu.org>
To: Daniel Colascione <dancol@dancol.org>
Cc: 34114@debbugs.gnu.org, karl@karlotness.com, kaushal.modi@gmail.com
Subject: bug#34114: 27.0.50: pdumper and themes with Emacs daemon
Date: Wed, 23 Jan 2019 07:32:25 +0200 [thread overview]
Message-ID: <92BA4FF9-C87A-4844-9114-7F716434681C@gnu.org> (raw)
In-Reply-To: <ed229163-5fca-4244-bb60-84fa6bb4033b@email.android.com>
On January 23, 2019 6:05:40 AM GMT+02:00, Daniel Colascione <dancol@dancol.org> wrote:
>
>
>
> On Jan 22, 2019 7:43 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > Cc: karl@karlotness.com, 34114@debbugs.gnu.org,
> kaushal.modi@gmail.com
> > From: Daniel Colascione <dancol@dancol.org>
> > Date: Tue, 22 Jan 2019 17:41:34 -0800
> >
> > > What is special about frames that precludes them from being
> recorded
> > > by the pdumper?
> >
> > Frames contain instance-specific state, and I don't think it makes
> sense
> > to try to pretend that individual frames survive from one Emacs
> > invocation to another.
>
> Sorry, I still don't think I understand: what is that
> instance-specific state, in terms of members of the frame object, or
> its attributes?
>
>
> A frame is always associated with a specific pty, specific X11 window,
> specific win32 window, etc. These concepts do not exist across
> different invocations of Emacs. I don't understand what you don't
> understand.
I didn't understand what you meant by "instance". I think I do now -- you mean output_method, output_data, and terminal members of struct frame? If so, these are (trivially) figured out for the initial frame, they are set to special values. And we delete that initial frame during startup, as soon as we can. So I don't think I understand the concerns. What specific problems could be caused by retaining this initial frame?
next prev parent reply other threads:[~2019-01-23 5:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-17 11:15 bug#34114: 27.0.50: pdumper and themes with Emacs daemon Karl Otness
2019-01-17 20:01 ` Kaushal Modi
2019-01-17 20:38 ` Kaushal Modi
2019-01-18 23:02 ` Karl Otness
2019-01-18 23:23 ` Daniel Colascione
2019-01-18 23:37 ` Karl Otness
2019-01-18 23:49 ` Daniel Colascione
2019-01-19 0:09 ` Karl Otness
2019-01-19 7:05 ` Eli Zaretskii
2019-01-21 22:59 ` Daniel Colascione
2019-01-22 16:28 ` Kaushal Modi
2019-01-22 16:45 ` Eli Zaretskii
2019-01-23 1:41 ` Daniel Colascione
2019-01-23 3:43 ` Eli Zaretskii
2019-01-23 4:05 ` Daniel Colascione
2019-01-23 5:32 ` Eli Zaretskii [this message]
2019-01-23 6:48 ` Daniel Colascione
2019-01-24 15:11 ` Eli Zaretskii
2019-01-24 19:22 ` Karl Otness
2019-01-26 10:22 ` Eli Zaretskii
2019-01-27 18:40 ` Kaushal Modi
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=92BA4FF9-C87A-4844-9114-7F716434681C@gnu.org \
--to=eliz@gnu.org \
--cc=34114@debbugs.gnu.org \
--cc=dancol@dancol.org \
--cc=karl@karlotness.com \
--cc=kaushal.modi@gmail.com \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.