4:04 a.m.
I'm currently looking at the relationship of Custom to Mule, primarily
with respect to fonts.
[Aside to Kyle: I'll keep working on this but I no longer think I'll
have code to fix the custom-set-faces bug any time soon. For 21.0,
the redefinition of reset-faces looks like the way to go.]
Many of the face functions associated with Custom (some of which have
leaked into other libraries, such as lisp/faces.el) use terminology
different from that documented in Info | Lispref | Specifiers. For
example, some functions (eg `face-spec-set') specialize the specifier
concept of "locale" to "frame" (in the sense that the argument which
represents the specifier's locale is called "frame"; I don't think the
semantics are altered at all). In other cases the representation of
objects is changed. Eg, specifiers characterize the display with a
tag-set [simple list] like `(x color)' while Custom uses alists like
`((type x) (class color))'.
This use of two different interfaces in lisp/faces.el is quite
disconcerting. The functions defined below the comment "used to be in
cus-face.el but logically belong [in faces.el]" use a different (but
not obviously so and only indirectly documented) interface from the
rest of faces.el. It was very tempting to think that the DISPLAY
argument was just an alias for TAG-SET, but that's not so.
(1) Why does Custom do this with faces? For FSF compatibility? Or is
there a technical reason to do it for XEmacs too?
The kind of manipulation that Custom does with ordinary properties
mostly defeats the purpose of using specifiers, as far as I can see
anyway. In particular, this is going to make properly fixing the
"custom-set-faces nukes all of Mule's fonts and makes my XEmacs
blanch" bug quite complicated---and probably most of it will happen
outside the specifier functionality by manipulating those extra
properties. Extending Custom faces to handle customizing Mule fonts
is going to be even worse, I'm afraid. But specifiers are capable of
handling all these problems smoothly, simply by leaving them to work
by themselves. Or aren't they?
(2) Can the interface of a function like `faces-spec-set' in
lisp/faces.el be changed? (It's one of the ones moved from
cus-face.el.) I would like it to use the specifier interface (some
combination of FACE LOCALE TAG-SET EXACT-P HOW-TO-ADD) but I suspect
that that would cause problems in Custom. Would it be a problem to
add a (partially redundant) &optional tag-set argument?
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Telfax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."
2:15 p.m.
"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
Many of the face functions associated with Custom (some of which
have
leaked into other libraries, such as lisp/faces.el) use terminology
different from that documented in Info | Lispref | Specifiers.
The face specifications interface (see the documentation to `defface')
don't really have anything directly to do with XEmacs specifier
interface. Indirectly, it should solve a subset of the problem XEmacs
specifiers are supposed to solve.
For example, some functions (eg `face-spec-set') specialize the
specifier concept of "locale" to "frame" (in the sense that the
argument which represents the specifier's locale is called "frame";
I don't think the semantics are altered at all).
Historically, XEmacs at some point generalized `frame' to `locale'.
In other cases the representation of
objects is changed. Eg, specifiers characterize the display with a
tag-set [simple list] like `(x color)' while Custom uses alists like
`((type x) (class color))'.
Is that what a tag set is? I read the chapter about specifiers in the
XEmacs Lisp manual, and it was completely incomprehensible to me.
I wrote the face specification interface to have something simple I
could understand that would work the same on both Emacs and XEmacs,
and hoped someone someday would write a function to translate the
simple face specifications into XEmacs specifiers. Much the same idea
as easymenu is based on. I believe Hrvoje Niksic tried, but found
that the XEmacs specifiers missed some (tags?) necessary.
This use of two different interfaces in lisp/faces.el is quite
disconcerting. The functions defined below the comment "used to be in
cus-face.el but logically belong [in faces.el]" use a different (but
not obviously so and only indirectly documented) interface from the
rest of faces.el. It was very tempting to think that the DISPLAY
argument was just an alias for TAG-SET, but that's not so.
`face-spec-set' started life as an internal customize function, in the
custom namespace. RMS moved it from custom to `faces.el', and made it
public. I renamed the XEmacs version in `cus-face.el' to be consitent
with Emacs. Hrvoje moved it to `faces.el'.
(2) Can the interface of a function like `faces-spec-set' in
lisp/faces.el be changed?
Not incompatibly, since it is a public function (indirectly) imported
from Emacs. I see no reason custom has to use it, as long as the
`defface' and `custom-set-faces' interfaces doesn't change.
I think you should concentrate on implementing the interface of those
two functions, not `face-spec-set'.
3:50 a.m.
Thanks much for the reply, I have a much better idea of what I can
hack on, and what would just be sand ni the gears.
>>>> "Per" == Per Abrahamsen
<abraham(a)dina.kvl.dk> writes:
Per> "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
> Many of the face functions associated with Custom (some of
> which have leaked into other libraries, such as lisp/faces.el)
> use terminology different from that documented in Info |
> Lispref | Specifiers.
Per> The face specifications interface (see the documentation to
Per> `defface') don't really have anything directly to do with
Per> XEmacs specifier interface. Indirectly, it should solve a
Per> subset of the problem XEmacs specifiers are supposed to
Per> solve.
Unfortunately, that subset excludes Mule. One problem is that Mule
inherently involves multiple font families; there is simply no overlap
across existing fonts for Japanese, Chinese, and ISO-8859-1, for
example. "Unicode" is not an answer, "Unicode" is a question. That
is, semantically there are many arguments favoring unification of the
Han characters in Unicode, but visually it is not possible to come up
with fonts acceptable to both of the two flavors of Chinese, let alone
the Japanese and Koreans as well. Saying "use Unicode fonts" is
equivalent to giving up on "World Domination Now."
In any case there are as yet few Unicode fonts, only one incomplete
(AFAIK) free on, and as far as I know, no families that include bold
and italic (which are completely differently implemented in Japanese
in any case). It is unlikely that that kind of issue (typographical
faces) is going to get sorted out without a fair amount of
experimentation and displays of nationalistic chest-beating, based on
the history of Han unification.
> For example, some functions (eg `face-spec-set') specialize
the
> specifier concept of "locale" to "frame" (in the sense that the
> argument which represents the specifier's locale is called
> "frame"; I don't think the semantics are altered at all).
Per> Historically, XEmacs at some point generalized `frame' to
Per> `locale'.
OK.
> In other cases the representation of objects is changed. Eg,
> specifiers characterize the display with a tag-set [simple
> list] like `(x color)' while Custom uses alists like `((type x)
> (class color))'.
Per> Is that what a tag set is? I read the chapter about
Per> specifiers in the XEmacs Lisp manual, and it was completely
Per> incomprehensible to me.
Yes, that's what the built-in tags are for, and I agree that
"incomprehensible" is a good approximation to "excessively abstract."
Per> I wrote the face specification interface to have something
Per> simple I could understand that would work the same on both
Per> Emacs and XEmacs, and hoped someone someday would write a
Per> function to translate the simple face specifications into
Per> XEmacs specifiers. Much the same idea as easymenu is based
Per> on. I believe Hrvoje Niksic tried, but found that the XEmacs
Per> specifiers missed some (tags?) necessary.
OK, I'll look at this. Missing tags shouldn't be a problem, Custom
can define its own. Possibly there's something missing in the
semantics of specifiers, or maybe Hrvoje just didn't like the apparent
bloat.
> (2) Can the interface of a function like `faces-spec-set' in
> lisp/faces.el be changed?
Per> Not incompatibly, since it is a public function (indirectly)
Per> imported from Emacs. I see no reason custom has to use it,
Per> as long as the `defface' and `custom-set-faces' interfaces
Per> doesn't change.
Per> I think you should concentrate on implementing the interface
Per> of those two functions, not `face-spec-set'.
OK, I guess I'll just ignore the current implementation. When I have
something, I'll come back and show it, and you can educate me as to
what I've broken and I'll redo it. :-) At your convenience, of course.
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Telfax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for? "Free software rules."
9523
days inactive
9525
days old
2 comments
2 participants
participants (2)
-
Per Abrahamsen -
Stephen J. Turnbull