unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Filipe Silva <filipe.silva@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: option for loading up a gui specific emacs daemon
Date: Wed, 14 Dec 2016 17:47:54 +0200	[thread overview]
Message-ID: <83shpqa4wl.fsf@gnu.org> (raw)
In-Reply-To: <CAEwkUWO9gechhCLGVpAd8iUu4yCi3xT-UyhBVkbfqKq00LGdRg@mail.gmail.com> (message from Filipe Silva on Tue, 13 Dec 2016 21:02:15 -0200)

> From: Filipe Silva <filipe.silva@gmail.com>
> Date: Tue, 13 Dec 2016 21:02:15 -0200
> 
> I'd like to load emacs with emacs --daemon=gui and then connect to it with emacsclient -c --sever-file=gui.
> 
> This works almost right. The problem is that various popular packages make extensive use of the
> (display-graphic-p) function/predicate to query frame capabilities. For example, a theme package may query
> (display-graphic-p) and assign gui or tty colors accordingly. 
> 
> the thing is that(display-graphic-p) always returns nil in a emacs --deamon type of loading, because emacs
> does not know if you are using emacsclient with a gui or a tty. 

If you remove the test from those packages, does everything else in
the package work correctly without signaling any errors?

You see, these tests are supposed to be made before calling APIs that
would otherwise signal an error or otherwise barf on non-GUI frames.
If removing the tests makes the package work fine in the daemon mode
or on a text-mode frame, it means the test is redundant and should
simply be removed.  Very few Emacs features really require GUI frames,
so it could be that these tests, or at least some of them, are
remnants from distant past, when many more features would only work in
GUI mode.

OTOH, if these tests are indeed required, then making them work in the
daemon will not provide any relief for you, because it will just delay
the error until later.

Does the above make sense?



  parent reply	other threads:[~2016-12-14 15:47 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-13 23:02 option for loading up a gui specific emacs daemon Filipe Silva
2016-12-13 23:14 ` Alex Hutcheson
2016-12-14  0:02 ` Kaushal Modi
2016-12-14 11:22   ` Filipe Silva
2016-12-14  1:34 ` Noam Postavsky
2016-12-14 11:11   ` Filipe Silva
2016-12-14 15:59     ` Noam Postavsky
2016-12-14 15:47 ` Eli Zaretskii [this message]
2016-12-15 13:10 ` Ken Raeburn

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=83shpqa4wl.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=filipe.silva@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 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).