8:18 a.m.
Moving discussion to xemacs-beta.
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
> Is there another way (i.e., not using the tag mule-fonts) to
> set fonts of existing faces for new charsets?
The reason for using this tag is to tell Custom _not_ to clear those
fonts from the faces. I don't know what Custom currently does, but
its attitude had always been "ALL FACES YOURS NOW FACES OURS ARE", and
it freely trashed anything it doesn't recognize as being specific to
some package.
The way to associate a font with a charset is simply to use an XLFD
that matches that charset. The match is defined by the 'registry
property of the charset. For example
(charset-registry 'ascii) => "\\(iso8859-[0-9]*\\|-ascii\\)"
(charset-registry 'latin-iso8859-15) => "iso8859-15"
Probably the first one should be fixed to match "iso646-irv" as well.
> I understand that the tag mule-fonts is only defined with Mule
> support, but I don't understand what this has to do with the
> console-type
Specifier tags are semantically significant to XEmacs core only when
they "match" a specific device. If any of the tags do not match a
particular device, then that specification will not be used on that
device.
For this reason, specifier tag definitions tend to collect in device
initialization code, although when used as "ids" for a particular
module's specifications there is no need for that. It's also true
that whether or not Mule is implemented has historically been strongly
associated with specific device types.
Ilya> You mean device type? Then the reason is that lisp code
Ilya> defining the tag is executed only when initializing devices
Ilya> of that type.
This was a partial cleanup by Ben. But he never had the problems with
Custom trashing his faces, so he may or may not have been aware of the
need for a specifier tag to protect non-ASCII/Latin-1 fonts from Custom.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
8:11 p.m.
New subject: gtk mule-fonts note
The reason for using this tag is to tell Custom _not_ to clear those
fonts from the faces. I don't know what Custom currently does
Its code does not even contain `mule-fonts' symbol. XEmacs core only
defines this tag on certain occasions, as described in
<02553f85227c66-gin(a)mo.msk.ru>, and does not use it otherwise. It is
used, however, by x-symbol package.
9:34 p.m.
New subject: gtk mule-fonts note
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
> The reason for using this tag is to tell Custom _not_ to clear
> those fonts from the faces. I don't know what Custom currently
> does
Ilya> Its code does not even contain `mule-fonts' symbol.
It doesn't need to. You can specify that a tagset must match exactly;
a tagset containing 'mule-fonts won't match a tagset that contains no
tags, and thus set-specifier can be used in such a way as to not
disturb other modules' specifications.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
6:05 p.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
. Use when adding specs
So the `mule-fonts' specifier tag is for use only while adding
specifications to specifier, and it is never used to restrict match
while instancing specifiers.
The tag is never used in specifications adding function calls done by
`custom'. The tag may be used in those calls done by `x-symbol'. So
`custom' allows and `x-symbol' requires the tag to be already defined.
Just the same other packages may wish to add specifications that are
intended for use by mule and must never be disturbed by `custom'.
Such an additions certainly must be done only when `(featurep 'mule)',
but other checks, including devices of what types currently exist,
look very hard to specify (and provide). In particular, in `x-symbol'
there are no obvious checks like that before using `mule-fonts'.
Then the tag must be defined not after initializing devices of
particular type, but just after loading `custom'. This must be done
once, with a single predicate function, not twice with different ones,
as done currently for X and GTK in 21.4. Since the tag is not
intended to restrict instancing, its predicate should return true
unconditionally.
. Use when instancing?
Or instancing restriction is also intended? Then there must be a list
of device types that "support mule", and device type maintainers must
update the list entries appropriately, so that a single predicate may
be written that just checks the list, which will be the `mule-fonts'
specifier tag predicate.
Perhaps the best is an additional field in generic device type data
that must be filled by device type maintainer, and a built-in
predicate that just returns it.
C core has to be changed anyway: even if the list is maintained in
elisp, there must be a comment in C code telling device type
maintainers to update it.
4:32 a.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> . Use when adding specs
Ilya> So the `mule-fonts' specifier tag is for use only while
Ilya> adding specifications to specifier, and it is never used to
Ilya> restrict match while instancing specifiers.
What makes you say that? I used to use it a lot in my own code, just
as x-symbol does.
Ilya> In particular, in `x-symbol' there are no obvious checks
Ilya> like that before using `mule-fonts'.
That's a bug in x-symbol, I'd say.
;; This can't hurt, unless there's other code that bogusly assumes
;; the specifier tag is defined in core.
(unless (valid-specifier-tag-p 'mule-fonts)
(define-specifier-tag 'mule-fonts))
Ilya> Then the tag must be defined not after initializing devices
Ilya> of particular type, but just after loading `custom'.
What makes you say this? Specifier tags can be defined any time
before use, even (as above) in user code.
Ilya> . Use when instancing?
Ilya> Or instancing restriction is also intended?
It wasn't historically. I don't know why Ben deleted that definition.
If you want to research the ChangeLogs and patches and explain what he
thought he was doing, fine. Or you can come up with more convincing
descriptions of what's going on and why what you propose is the right
thing to do. If not, I'm not going to approve much of anything until
I've had time to do that research myself, and it's not high priority.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:26 p.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
> So the `mule-fonts' specifier tag is for use only while
> adding specifications to specifier, and it is never used to
> restrict match while instancing specifiers.
What makes you say that? I used to use it a lot in my own code, just
as x-symbol does.
That is, only to ensure that specifications being added will not be
removed by other additions, but not for use in instancing. Then the
original point holds.
What makes you say this? Specifier tags can be defined any time
before use, even (as above) in user code.
The known usage of the tag suggests that it may be used in added
specifications regardless of types of devices currently initialized.
It must be defined before any possible use, that is, very early. Or
one has to scatter code like:
(unless (valid-specifier-tag-p 'mule-fonts)
(define-specifier-tag 'mule-fonts))
throughout packages.
If you want to research the ChangeLogs and patches and explain what
he
thought he was doing, fine.
Do not want. The highest priority for me is ensuring that
documentation answers to user (my) questions: "What is happening to my
fonts? Why is the text displayed in these particular ones?". That
is, describing the current rules.
6:30 a.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> That is, only to ensure that specifications being added will
Ilya> not be removed by other additions, but not for use in
Ilya> instancing.
My code did use it for instancing.
> What makes you say this? Specifier tags can be defined any
> time before use, even (as above) in user code.
Ilya> The known usage of the tag suggests that it may be used in
Ilya> added specifications regardless of types of devices
Ilya> currently initialized.
Sorry, no. Because Emacs Lisp by default uses dynamic binding and
run-time definition of various things, it's up to the user to verify
the usage of any given object. Evidently x-symbol thinks that the
'mule-fonts tag means something other than what it does (which is
currently unclear).
Ilya> It must be defined before any possible use, that is, very
Ilya> early. Or one has to scatter code like:
(unless (valid-specifier-tag-p 'mule-fonts)
(define-specifier-tag 'mule-fonts))
Ilya> throughout packages.
Yes. That is the correct approach.
> If you want to research the ChangeLogs and patches and explain
> what he thought he was doing, fine.
Ilya> Do not want. The highest priority for me is ensuring that
Ilya> documentation answers to user (my) questions: "What is
Ilya> happening to my fonts? Why is the text displayed in these
Ilya> particular ones?". That is, describing the current rules.
The implementation may very well not conform to the rules. Changing
the documentation to reflect the implementation would be to introduce
a bug.
If you want to conform to the implementation, that's fine, maybe even
necessary for your application. But it is wrong to change
documentation which may be correct (or at least not incorrect) to
reflect buggy behavior, and thus propagate that behavior.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
11:46 a.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
But it is wrong to change
documentation which may be correct (or at least not incorrect) to
reflect buggy behavior, and thus propagate that behavior.
If the "buggy behavior" stayed for years, and unlikely to change in
few days, users are entitled to know this - that is, to have it
documented.
2:16 p.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
If the "buggy behavior" stayed for years, and unlikely to
change in
few days, users are entitled to know this - that is, to have it
documented.
Certainly, if the current behavior is strange, incorrect, unclear,
likely to change in future, should not be depended on, the
documentation must also say so.
9:44 a.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
> If the "buggy behavior" stayed for years, and unlikely
to
> change in few days, users are entitled to know this - that is,
> to have it documented.
Ilya> Certainly, if the current behavior is strange, incorrect,
Ilya> unclear, likely to change in future, should not be depended
Ilya> on, the documentation must also say so.
It is documented: C-h C-w. That's all you can count on in 21.5; AFAIK
this stuff works as it has for many years in 21.4.
If it in fact causes problems in 21.4, let me know.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
3:19 p.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
It is documented: C-h C-w. That's all you can count on in 21.5;
AFAIK
this stuff works as it has for many years in 21.4.
It is largely the same in 21.4. Just as with thousands of `fboundp's,
why not replace all documentation with C-h C-w reference, then?
4:52 a.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
> It is documented: C-h C-w. That's all you can count on in
> 21.5; AFAIK this stuff works as it has for many years in 21.4.
Ilya> It is largely the same in 21.4. Just as with thousands of
Ilya> `fboundp's, why not replace all documentation with C-h C-w
Ilya> reference, then?
C-h C-w is the _existing_ documentation; the question is to replace
that with accurate documentation. Documentation is more or less a
promise; the C-h C-w promise is accurate as far as it goes (precisely
because it doesn't go very far). It is very bad practice to replace a
generic refusal to make a promise with a specific promise that you may
not want to keep.
You have said you're not interested in doing this right. So you are
going to have to wait until somebody who _is_ going to do it right
gets around to doing it right.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
5:59 a.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
The user point of view is quite different.
Documentation is more or less a promise
It is very bad practice to replace a
generic refusal to make a promise with a specific promise that you may
not want to keep.
That is, to keep documentation up-to-date with current behavior? Then
to figure out how to use software one has to dig in its internals,
which is often even harder than writing it from the scratch.
It is just a matter software design quality, a matter of clear idea of
what has to be implemented. So that one can make promises (in
documentation) and keep them. If one does not like this, he should
not write software.
Or, if he wrote it, describe how it behaves currently. And when
redesign it, update the documentation immediately, not as memoirs.
Leaving new behavior undocumented is ok for some short periods of
time. That is what beta for. But when it lasts since 1997-02-27
(as with "this is a trial implementation" phrase in `site-load.el'),
that looks at least strange.
You have said you're not interested in doing this right.
It is again a matter of what is called "right". For the user, it is
primarily correct documentation. It seems to me that current
functionality meets all needs of users like me - provided that it is
documented, so figuring out how to use is reasonably easy.
"Doing its right" as redesigning the behavior is completely different,
and it is really not that interesting for me.
11:35 a.m.
New subject: 'mule-fonts' hadling (Re: gtk mule-fonts note)
>>>> "Ilya" == Ilya N Golubev
<gin(a)mo.msk.ru> writes:
Ilya> The user point of view is quite different.
You wouldn't know the user point of view if it bit you; you are
dumping non-standard modules, something which has never been supported
beyond a wink dated 1997 in site-load.el, and no user has _ever_
complained in the interim.
> Documentation is more or less a promise
> It is very bad practice to replace a generic refusal to make a
> promise with a specific promise that you may not want to keep.
Ilya> That is, to keep documentation up-to-date with current
Ilya> behavior?
Yes.
If you want undefined behavior to be documented, you have to define it
first.
Please, stop wasting my time, or I'm going to have to kill-file you again.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
7510
days inactive
7517
days old
13 comments
2 participants
participants (2)
-
Ilya N. Golubev -
Stephen J. Turnbull