From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Adrian Robert Newsgroups: gmane.emacs.devel Subject: Re: macos.texi updated Date: Tue, 18 Oct 2005 14:29:19 -0400 Message-ID: References: <8C0A68AE-EF12-4D6C-9879-D0FF3B04DE1B@mac.com> <87r7bhw2o8.fsf-monnier+emacs@gnu.org> <991DC775-381E-4B96-BBC6-B3701CCD6EAD@cogsci.ucsd.edu> <3158D814-131C-469F-9DCF-3E678AC27957@cogsci.ucsd.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/mixed; boundary="===============0741326021==" X-Trace: sea.gmane.org 1129660335 12440 80.91.229.2 (18 Oct 2005 18:32:15 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 Oct 2005 18:32:15 +0000 (UTC) Cc: mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 18 20:32:09 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ERwEd-0000Bz-KL for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2005 20:30:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERwEc-00057W-UQ for ged-emacs-devel@m.gmane.org; Tue, 18 Oct 2005 14:30:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ERwEL-000579-Nl for emacs-devel@gnu.org; Tue, 18 Oct 2005 14:30:34 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ERwEK-00055p-E6 for emacs-devel@gnu.org; Tue, 18 Oct 2005 14:30:33 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ERwEK-00055g-Bg for emacs-devel@gnu.org; Tue, 18 Oct 2005 14:30:32 -0400 Original-Received: from [140.251.0.25] (helo=smtp-in2.med.cornell.edu) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ERwEF-0008BM-9Z; Tue, 18 Oct 2005 14:30:27 -0400 Original-Received: from mpx1.med.cornell.edu (biglb-vlan511vip.med.cornell.edu [140.251.11.120]) by smtp-in2.med.cornell.edu (Switch-3.1.6/Switch-3.1.6) with ESMTP id j9IITKni210856; Tue, 18 Oct 2005 14:29:21 -0400 Original-Received: from [140.251.33.115] by mpx1.med.cornell.edu (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTP id <0IOK006R3JCWDZ70@mpx1.med.cornell.edu>; Tue, 18 Oct 2005 14:29:20 -0400 (EDT) In-reply-to: Original-To: rms@gnu.org X-Mailer: Apple Mail (2.734) X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, Antispam-Data: 2005.10.18.19 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:44271 Archived-At: --===============0741326021== Content-type: multipart/alternative; boundary=Apple-Mail-1-1029104241 --Apple-Mail-1-1029104241 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Oct 11, 2005, at 10:44 AM, Richard M. Stallman wrote: > (I guess I was > trying to say, "drop XLFD, and if some functionality is lost, > update > the lisp syntax to fix it".) > > We don't need to change Emacs for that. You should be able, already, > to do whatever you like in Emacs without using XLFD syntax. What > is there > that cannot be done except with XLFD syntax? Since I use Emacs on Aqua, which does not expose XLFD anywhere, I can't speak directly as a user. But looking at the situation from the inside on the unicode-2 branch, it appears that there are several major places in the code that expect all of the information for specifying a font to be contained in a single string. At the elisp- wielding-user-visible level this manifests in what you pass to and get back from x-list-fonts, as well as any font-setting functions, setting font as a frame parameter, etc... I can't tell whether other platforms could use some other single-string-specifies-all format besides XLFD (not that this would be natural), or if other code in fontset.c and xfaces.c requires these names to be XLFD. All I know is that in the Cocoa port, I'm having trouble getting the full font machinery working without putting all font info into string names. In any case, both lisp code and user mailing list traffic for the Mac Carbon emacs contain numerous references to XLFD. E.g.: See for example: http://search.gmane.org/?query=-apple- courier&email=&group=gmane.emacs.macintosh.osx&sort=relevance&DEFAULTOP= and&xP=apple-.&xFILTERS=Gemacs.macintosh.osx---A http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/macemacsjp/carbon_font/ carbon-font.el Anyway, I will drop this now due to an intense lack of interest from anyone else on this list ;), and come back when 22 is out and/or I have some code to show.. > I think perhaps some > command line option uses it. We could replace that option with > one that uses a different syntax, but what syntax should it be? > > .default { > font-family: courier; > font-size: 13pt; > font-weight: bold; > font-style: italic; > } > > I don't think that is useful in an Emacs context. > It is no easier to type, no more concise, than a list > of face attributes in Lisp syntax. Where would we possibly > want to use it? My point was that the XLFD is so concise and cryptic as to be a real hassle no matter what it's used for. I really don't see any typing savings for something like emacs -font '-*-courier-*-*-*--12-*-*-*-*-*-*-*' or even emacs -font '-*-courier-*-*-*--12-*' vs. emacs -font '{ font-family: courier font-size: 12pt }' If you're not cutting/pasting the font, counting out how many asterisks you need and deciding where to put the '12' are far more time-consuming than punching out the few extra characters for CSS- style. And if you are cutting/pasting, there's no difference, besides readability. But given that things are as they are, I see no reason to add a new syntax either if it's not needed for lisp customization -- using XLFD on the command line seems fine since users on the non-X systems rarely use command-line invocation anyhow. --Apple-Mail-1-1029104241 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Oct 11, 2005, = at 10:44 AM, Richard M. Stallman wrote:

=A0 =A0= =A0 (I guess I was =A0
=A0 =A0 trying to say, "drop XLFD, and = if some functionality is lost, update =A0
=A0 =A0 the lisp = syntax to fix it".)

We don't need to change = Emacs for that.=A0 You should be able, already,
to do whatever = you like in Emacs without using XLFD syntax.=A0 What is = there
that cannot be done except with XLFD = syntax?

Since I use Emacs on Aqua, = which does not expose XLFD anywhere, I can't speak directly as a user.=A0 = But looking at the situation from the inside on the unicode-2 branch, it = appears that there are several major places in the code that expect all = of the information for specifying a font to be contained in a single = string.=A0 At the elisp-wielding-user-visible level this = manifests in what you pass to and get back from x-list-fonts, as well as = any font-setting functions, setting font as a frame parameter, etc...=A0 = I can't tell whether other platforms could use some other = single-string-specifies-all format besides XLFD (not that this would be = natural), or if other code in fontset.c and xfaces.c requires these = names to be XLFD.=A0 All I know is that in the Cocoa port, I'm having = trouble getting the full font machinery working without putting all font = info into string names.

In any case, both lisp code = and user mailing list traffic for the Mac Carbon emacs contain numerous = references to XLFD.=A0 E.g.:

See for = example:


http://cvs.sourceforge.jp/cgi-bin/viewcvs.cgi/macemacsj= p/carbon_font/carbon-font.el

Anyway, I will drop this = now due to an intense lack of interest from anyone else on this list ;), = and come back when 22 is out and/or I have some code to = show..


=A0 I think perhaps some
command line = option uses it.=A0 We could replace that option with
one that = uses a different syntax, but what syntax should it = be?

=A0 =A0 .default {
=A0=A0 =A0 = font-family: courier;
=A0=A0 =A0 font-size: 13pt;
=A0=A0= =A0 font-weight: bold;
=A0=A0 =A0 font-style: = italic;
=A0 =A0 }

I don't think that = is useful in an Emacs context.
It is no easier to type, no = more concise, than a list
of face attributes in Lisp syntax.=A0 = Where would we possibly
want to use = it?

My point was that the XLFD = is so concise and cryptic as to be a real hassle no matter what it's = used for. =A0I really don't see any typing savings for something = like

emacs = -font '-*-courier-*-*-*--12-*-*-*-*-*-*-*'

or even

emacs -font = '-*-courier-*-*-*--12-*'

vs.

emacs -font '{ font-family: = courier font-size: 12pt }'

If you're not = cutting/pasting the font, counting out how many asterisks you need and = deciding where to put the '12' are far more time-consuming than punching = out the few extra characters for CSS-style.=A0 And if you are = cutting/pasting, there's no difference, besides = readability.

But given that things are as they are, = I see no reason to add a new syntax either if it's not needed for lisp = customization -- using XLFD on the command line seems fine since users = on the non-X systems rarely use command-line invocation = anyhow.

= --Apple-Mail-1-1029104241-- --===============0741326021== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emacs-devel mailing list Emacs-devel@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-devel --===============0741326021==--