Re: Detecting display/frame capability in an Emacs daemon

["Stephen J. Turnbull" <stephen@xemacs.org>]

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