From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Detecting display/frame capability in an Emacs daemon Date: Mon, 18 Feb 2013 10:38:07 +0900 Message-ID: <87obfiwge8.fsf@uwakimon.sk.tsukuba.ac.jp> References: <1ev1uchryvm.fsf@LT-MMAUGER.office.techtarget.com> <1361060596.66870.YahooMailNeo@web160902.mail.bf1.yahoo.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1361151513 11790 80.91.229.3 (18 Feb 2013 01:38:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Feb 2013 01:38:33 +0000 (UTC) Cc: Michael Mauger , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 18 02:38:55 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U7Fgv-0008IA-EL for ged-emacs-devel@m.gmane.org; Mon, 18 Feb 2013 02:38:49 +0100 Original-Received: from localhost ([::1]:34673 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7Fgb-0003m5-Cy for ged-emacs-devel@m.gmane.org; Sun, 17 Feb 2013 20:38:29 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:52532) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7FgY-0003lu-Vy for emacs-devel@gnu.org; Sun, 17 Feb 2013 20:38:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1U7FgX-0007sE-PR for emacs-devel@gnu.org; Sun, 17 Feb 2013 20:38:26 -0500 Original-Received: from mgmt1.sk.tsukuba.ac.jp ([130.158.97.223]:48453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1U7FgX-0007qS-8s for emacs-devel@gnu.org; Sun, 17 Feb 2013 20:38:25 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt1.sk.tsukuba.ac.jp (Postfix) with ESMTP id BF4813FA0701; Mon, 18 Feb 2013 10:38:07 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 793391A266B; Mon, 18 Feb 2013 10:38:07 +0900 (JST) In-Reply-To: X-Mailer: VM undefined under 21.5 (beta32) "habanero" b0d40183ac79 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.158.97.223 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157117 Archived-At: 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