Detecting display/frame capability in an Emacs daemon

Detecting display/frame capability in an Emacs daemon

[michael]

I have a cloud based Emacs initialization file that I use on three
machines: 2 GNU/Linux X based and 1 Cygwin (with w32 GUI).  In the
script I set the default font and the font for a couple of faces.  Since
not all of the machines have the same set of fonts, my initialization
uses `x-list-fonts' to see if a particular font is available.  If a font
is not available it falls back on to the next font on my preferred list.
For example, I prefer DejaVu Mono, but if it's not available I'll try
Liberation Mono, and then Lucida Console.

If I start Emacs with just "emacs" my frame pops up with the best
preferred font.  If, however, I start up with "emacs --daemon", no frame
appears (as expected until I request one with "emacsclient").  Since no
initial frame is displayed, the GUI has not been initialized and I get
an error message in my *Messages* buffer when I try to inspect available
fonts.  That makes sense.

My goal was to then find a hook to attach to that was after the GUI had
been initialized so that I could probe the fonts.  I tried
'after-make-frame-functions' and checking (display-graphic-p) before I
look for fonts, and while I don't get an error indicating that the GUI
is not yet initialized, the x-list-fonts function always returns nil and
thus I get the default Emacs fonts rather than one I had chosen.  Once
the frame appears, I can run the same function and my fonts now appear. 

So, my question is: Is this a bug?  Is there a prescribed way of doing
this in an Emacs daemon?  (Setting the font is not a problem, it's the
checking for the existence of the font that causes trouble.)  Is this a
missing feature/enhancement?

--Michael 

Re: Detecting display/frame capability in an Emacs daemon

[Stefan Monnier]

> For example, I prefer DejaVu Mono, but if it's not available I'll try
> Liberation Mono, and then Lucida Console.

I recommend you use face-font-family-alternatives, so you don't have to
use x-list-fonts and the fallback between the different alternatives is
done automatically by the C code.


        Stefan

Re: Detecting display/frame capability in an Emacs daemon

[Richard Stallman]

    I have a cloud based Emacs initialization file 

I have no idea what that means -- it is because the term "cloud" is so
nebulous.  "Cloud computing" is used to refer to many different scenarios
which shouldn't be lumped together.

When someone says "cloud", typically he means one of these many
scenarios.  Often I can guess which scenario he means, but this time I
can't guess.

What are you actually doing?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Detecting display/frame capability in an Emacs daemon

[Michael Mauger]

>________________________________
> From: Richard Stallman <rms@gnu.org>
>Cc: emacs-devel@gnu.org 
>Sent: Saturday, February 16, 2013 9:07 AM
>Subject: Re: Detecting display/frame capability in an Emacs daemon
> 
>    I have a cloud based Emacs initialization file 
>
>I have no idea what that means -- it is because the term "cloud" is so
>nebulous.  "Cloud computing" is used to refer to many different scenarios
>which shouldn't be lumped together.
>
>When someone says "cloud", typically he means one of these many
>scenarios.  Often I can guess which scenario he means, but this time I
>can't guess.
>
>What are you actually doing?
>
>-- 
>Dr Richard Stallman


I apologize for the lack or clarity.  I have a website hosted on a VM on my 
personal machine.  The site is powered by ownCloud and made available 
on the broader tubes with pagekite.  ownCloud provides a client tool that
replicates my GNU Emacs, shell and database configurations among my 
personal machines and work machines.  So essentially I am using the 
exact same initialization files on multiple machines with different OS's and,
in this case, different fonts.

In the meantime, I have come up with a working solution to my problem, 
but I may have encountered a serious bug.  I'm working to reduce it to a
repeatable recipe, but I had the Emacs trunk crash on me multiple times.
Bug report in progress.

-- Michael

http://ownCloud.org
https://pagekite.net

Re: Detecting display/frame capability in an Emacs daemon

[Richard Stallman]

    I apologize for the lack or clarity.  I have a website hosted on a VM on my 
    personal machine.  The site is powered by ownCloud and made available 
    on the broader tubes with pagekite.  ownCloud provides a client tool that
    replicates my GNU Emacs, shell and database configurations among my 
    personal machines and work machines.  So essentially I am using the 
    exact same initialization files on multiple machines with different OS's and,
    in this case, different fonts.

It sounds like you're synching files among your machines.  I am
unfamiliar with the things you are using but I do it with rsync.  It
would be a clear thing if that damned "cloud" didn't obscure it.

    I'm working to reduce it to a
    repeatable recipe, but I had the Emacs trunk crash on me multiple times.
    Bug report in progress.

Thanks for helping out.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Detecting display/frame capability in an Emacs daemon

[Stephen J. Turnbull]

Richard Stallman writes:

 > It sounds like you're synching files among your machines.

That's the implementation, according to Michael's more recent post.
But that's not what he's doing.  What he's *doing* is *sharing*
certain resources among his machines.

 > I am unfamiliar with the things you are using but I do it with
 > rsync.  It would be a clear thing if that damned "cloud" didn't
 > obscure it.

Not "obscure", "abstract".  "Cloud" vs. "site" is just URN vs. URL.
DNS and netnews are early examples of cloud services.

It's true that in many cases, "cloud" is the wrong level of
abstraction for debugging many problems (eg, if the files are *not*
being synched), and of course it has unattractive "code is law"
implications when embedded in less-than-free applications.

But in this particular case it seems to be precisely the right level
of abstraction.  The "cloud" abstraction seems to be appropriate,
because his problem is that he *does* get the same file in different
places and *doesn't* care where the original is located (or even if
there *is* a consistent location of the original!), *but* the file's
content is more or less inappropriate for some of those places.  ISTM
a "good" solution to Michael's problem would involve "fonts" and other
resources that are "cloud compatible".  These could be virtual fonts,
such as "Monospace", which are aliases for "appropriate" local fonts,
or they could be actual fonts accessible via the cloud.

For GNU systems (and other systems that support fontconfig),
fonts.conf allows host-by-host configuration of aliases.  I wonder if
Michael wouldn't be better off using fontconfig to solve this problem,
since that would benefit all his applications that share configuration
of fonts (whether implicitly "in the cloud" or explicitly by rsync or
sneakernet or Tramp).

I guess in the long run Emacs could help by switching specifications
to "virtual" fonts in the above sense.

Steve

Re: Detecting display/frame capability in an Emacs daemon

[Richard Stallman]

     > I am unfamiliar with the things you are using but I do it with
     > rsync.  It would be a clear thing if that damned "cloud" didn't
     > obscure it.

    Not "obscure", "abstract".

I meant "obscure".  The term "cloud computing" is not a clean
abstraction but a confusion between different and unrelated ways
of using the network.

    But in this particular case it seems to be precisely the right level
    of abstraction.

I disagree.  The abstraction you have in mind is just one of the
several unrelated meanings that people use "cloud computing" for.

I think file synching is the right term for this.  The difference
between that and "sharing resources among his own machines" is so small
that they seem equivalent to me, which means it is not wrong.

However, "cloud computing" means other very different things as well.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Detecting display/frame capability in an Emacs daemon

[Stephen J. Turnbull]

Richard Stallman writes:
 >      > I am unfamiliar with the things you are using but I do it with
 >      > rsync.  It would be a clear thing if that damned "cloud" didn't
 >      > obscure it.
 > 
 >     Not "obscure", "abstract".
 > 
 > I meant "obscure".

I know you did; you always mean what you say.

That doesn't mean your meaning is always useful.  In this case, I
don't think it is.  I think that Emacs should deal with this issue on
the more abstract level of resource shared by hosts of varying
capability, which is reasonably accurately expressed by "cloud".

 > The term "cloud computing" is not a clean abstraction but a
 > confusion between different and unrelated ways of using the
 > network.

As you just wrote yourself, they're related by use of the network.

Mere presence of the network already implies that Emacs users must be
concerned with different instances of Emacs using the same resources
in different contexts, with those differences being more or less
unpredictable as hosts of varying kinds connect to and disconnect from
the network.

It may not be Emacs's business to be concerned with that, I don't
know.  However, "the cloud" makes such sharing far more accessible to
both busy users who don't care to shoulder administrative burden of
less sophisticated resource-sharing protocols, and unsophisticated
users.  I think the demand for an Emacs that works and plays well with
both the "cloud" of transparently shared resources, and the varied
underlying implementations of that idea, will increase in the future.

 > I think file synching is the right term for this.

I disagree.  File synching is an implementation.  The OP doesn't care
that the files exist in multiple places, however, and he would indeed
have similar problems with NFS or Tramp (where the file is fetched
over the network, though one is implemented in the OS and the other in
Emacs) or with Coda FS (where the files are cached, the network use is
reduced to a quick version check if the cache is fresh, and the cached
files are not accessible to the user by a local name).  The
implementation doesn't matter; what matters is the abstract idea of a
resource automatically shared by different instances of Emacs.  "In
the cloud" is a reasonable informal expression of this concept.

 > The difference between that and "sharing resources among his own
 > machines" is so small that they seem equivalent to me, which means
 > it is not wrong.

Many resources are not file-based.  For example, the OP's question
about determining display capability would matter if you use Emacs to
invoke a remote program that generates an image locally.  I don't know
what the capabilities of OpenCloud are, but I wouldn't be surprised if
it included such remote processing.

How is the difference between sharing such resources and synching
files "so small that they seem equivalent"?

Re: Detecting display/frame capability in an Emacs daemon

[Richard Stallman]

      I think that Emacs should deal with this issue on
    the more abstract level of resource shared by hosts of varying
    capability, which is reasonably accurately expressed by "cloud".

The term "cloud computing" is not a clear way to refer to that,
because it is used for several other things too.

Also, "resource" is vague: using files is very different from
using printers.  A person might want to do both, but we
need to keep in mind that they are different issues.

     > The term "cloud computing" is not a clean abstraction but a
     > confusion between different and unrelated ways of using the
     > network.

    As you just wrote yourself, they're related by use of the network.

Yes, but that doesn't make them similar in any significant way.

      However, "the cloud" makes such sharing far more accessible to
    both busy users who don't care to shoulder administrative burden of
    less sophisticated resource-sharing protocols, and unsophisticated
    users.

Perhaps some specific practice has this benefit.  What I object to
is using the general term "cloud" which lumps it together
with other, quite different practices.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call

Re: Detecting display/frame capability in an Emacs daemon

[Stephen J. Turnbull]

Richard Stallman writes:

 > A person might want to do both, but we need to keep in mind that
 > they are different issues.

Not always.  That's the point of abstraction.