6:23 p.m.
I am using xemacs 21.5.27 on Fedora 5.
./configure --prefix=/sw/xemacs-21.5.27 --without-debug --without-error-checking
--with-xft=emacs,tabs,menubars,gauges --with-mule
cd /sw/xemacs-21.5.27/lib/xemacs
tar -ztvf /sw/src/tarfiles/xemacs-sumo.tar.gz
Note: it is compiled with mule.
=======================================================================
Here are the partial results from locale -a
...
...
hebrew
he_IL
he_IL.iso88598
he_IL.utf8
...
ru_RU
ru_RU.iso88595
ru_RU.koi8r
ru_RU.utf8
russian
....
=======================================================================
I then use Firefox to go to a Russian site, and cut and paste into xemacs
This is in the *Warning* buffer
(1) (font/notice) Unable to instantiate font for charset cyrillic-iso8859-5, face default
I get a similar message for Hebrew
(2) (font/notice) Unable to instantiate font for charset hebrew-iso8859-8, face default
And this is standard output:
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 16 descent 4 width 10 height 23
initialized font monospace-12
initialized metrics ascent 16 descent 4 width 10 height 23
initialized font Luxi Mono-12:slant=110
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
checking if Luxi Mono-12:antialias=True:hintstyle=2:rgba=5:fontformat=Type
1:embeddedbitmap=True handles English
Xft font Luxi Mono-12:antialias=True:hintstyle=2:rgba=5:fontformat=Type
1:embeddedbitmap=True supports en
initialized metrics ascent 13 descent 3 width 8 height 18
initialized font Luxi
Mono-12:style=Regular:slant=0:weight=80:pixelsize=12.5:foundry=b&h:antialias=True:hintstyle=2:outline=True:scalable=True:dpi=75:rgba=5:fontformat=Type
1:embeddedbitmap=True
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 16 descent 4 width 10 height 23
initialized font Luxi Mono-12:slant=110
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
initialized metrics ascent 17 descent 4 width 10 height 23
initialized font Luxi Mono-12:weight=200
These are the lines when Russian is pasted
Xft font Luxi Mono-12:antialias=True:hintstyle=2:rgba=5:fontformat=Type
1:embeddedbitmap=True doesn't support cyrillic-iso8859-5
Xft font Sazanami
Mincho-12:familylang=en:stylelang=en:antialias=True:hintstyle=2:rgba=5:capability=otlayout\:kana:fontformat=TrueType:embeddedbitmap=False
doesn't support cyrillic-iso8859-5
These are the lines when Hebrew is pasted
checking if Luxi Mono-12:antialias=True:hintstyle=2:rgba=5:fontformat=Type
1:embeddedbitmap=True handles Hebrew
Xft font Luxi Mono-12:antialias=True:hintstyle=2:rgba=5:fontformat=Type
1:embeddedbitmap=True doesn't support he
checking if Sazanami
Mincho-12:familylang=en:stylelang=en:antialias=True:hintstyle=2:rgba=5:capability=otlayout\:kana:fontformat=TrueType:embeddedbitmap=False
handles Hebrew
Xft font Sazanami
Mincho-12:familylang=en:stylelang=en:antialias=True:hintstyle=2:rgba=5:capability=otlayout\:kana:fontformat=TrueType:embeddedbitmap=False
doesn't support he
=======================================================================
There is another problem with the fonts:
If I go to the Menu bar and choose Option/Font, _all_ the font names are greyed out. Luxi
Mono has a green diamond by it.
Why can't I choose other fonts?
Peter
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:53 a.m.
Peter Gordon writes:
I am using xemacs 21.5.27 on Fedora 5.
I hope you're not using the binary RPM provided by Fedora Core, I've
heard it's even more buggy than building from our source, and I don't
understand how the reported bugs could happen---I just send Fedora
Core customers back to Fedora.
./configure --prefix=/sw/xemacs-21.5.27 --without-debug
--without-error-checking --with-xft=emacs,tabs,menubars,gauges --with-mule
Non-Western European, non-Japanese languages are likely to lose with
this configuration unless you're a developer. Xft support is a work
in progress, and the font menus are known to be broken. Furthermore,
they're broken by design. I'm working on the design, and don't intend
to try to fix behavior in the short run.
--without-debug and --without-error-checking are highly risky; if you
have any problems at the C level (and I know of several that have been
identified since release of 21.5.27, including probable crashes),
you're just going to be told to build with --with-debug at least and
file a proper bug report. --with-debug has very little performance
impact.
As far as Unicode support is concerned, it's strictly external.
Internal encoding are still based on legacy national character sets
(as are those of all released Emacsen, including the release-in-
progress of GNU Emacs 22, except for the XEmacs/CHISE fork developed
at the University of Kyoto).
The code in src/objects-x.c is supposed to be able to handle various
charsets, why it doesn't like Hebrew and Russian I don't know. I'll
take a look at that, but can't promise rapid progress.
Sorry I can't be more optimistic. I hope the information is of use to
you, though.
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
9 a.m.
stephen(a)xemacs.org writes:
Peter Gordon writes:
> I am using xemacs 21.5.27 on Fedora 5.
I hope you're not using the binary RPM provided by Fedora Core, I've
heard it's even more buggy than building from our source, and I
don't understand how the reported bugs could happen---I just send
Fedora Core customers back to Fedora.
Well, RedHat _does_ need customers for their service business model.
Ok, that line does not really explain what Debian does, though.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
10:10 a.m.
On Wed, Nov 15 2006, stephen(a)xemacs.org wrote:
As far as Unicode support is concerned, it's strictly external.
Internal encoding are still based on legacy national character sets
(as are those of all released Emacsen, including the release-in-
progress of GNU Emacs 22, except for the XEmacs/CHISE fork developed
at the University of Kyoto).
If you also count forks: IIRC some Mac-only Emacs version is based on
the unicode-branch (to be Emacs 23 someday) of Emacs.
Bye, Reiner.
--
,,,
(o o)
---ooO-(_)-Ooo--- | PGP key available | http://rsteib.home.pages.de/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
4:42 p.m.
On Wed, 2006-11-15 at 11:53 +0900, stephen(a)xemacs.org wrote:
Peter Gordon writes:
> I am using xemacs 21.5.27 on Fedora 5.
I hope you're not using the binary RPM provided by Fedora Core, I've
heard it's even more buggy than building from our source, and I don't
understand how the reported bugs could happen---I just send Fedora
Core customers back to Fedora.
Fedora Core no longer provides XEmacs packages. Fedora Extras does (but
21.5.x is just for FC6+, so this isn't one of them).
And as the maintainer of said packages already for a while, I'd
appreciate some details about the bugs you're referring to (or if you
don't have the details, info where you've heard about them), ie. ones
that are present in the packages but not if one builds XEmacs from
source on the same target.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6:25 p.m.
Ville Skyttä writes:
And as the maintainer of said packages already for a while, I'd
appreciate some details about the bugs you're referring to (or if you
don't have the details, info where you've heard about them),
It was reported here within the last two weeks that in those packages
one gets errors about "not a coding category: iso-8859-15".
I'd never heard of such a bug before. I told the reporter to report
to Fedora, as it doesn't make any sense to me.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:05 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
Ville Skyttä writes:
> And as the maintainer of said packages already for a while, I'd
> appreciate some details about the bugs you're referring to (or if you
> don't have the details, info where you've heard about them),
It was reported here within the last two weeks that in those packages
one gets errors about "not a coding category: iso-8859-15".
I'd never heard of such a bug before. I told the reporter to report
to Fedora, as it doesn't make any sense to me.
You mean, you don't _remember_ having heard of such a bug before. We
went through something like this previously, and you said that XEmacs
could not expected to track all coding systems that Emacs developers
chose to invent.
Such an error could be triggered by an explicit coding cookie, or
(like when I reported the problem and you ultimately dismissed as
can't/won't fix) by restoring a desktop to XEmacs that had been saved
with desktop.el from an Emacs session.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
7:34 p.m.
Ar an cúigiú lá déag de mí na Samhain, scríobh David Kastrup:
> [...] It was reported here within the last two weeks that in
those
> packages one gets errors about "not a coding category: iso-8859-15".
>
> I'd never heard of such a bug before. I told the reporter to report
> to Fedora, as it doesn't make any sense to me.
You mean, you don't _remember_ having heard of such a bug before. We
went through something like this previously, and you said that XEmacs
could not expected to track all coding systems that Emacs developers
chose to invent.
No, he means he’d never heard of it before. A coding category is something
distinct from a coding system in XEmacs.
http://google.com/search?q="Unrecognized+coding+category" (reflecting the
exact error) gives our source code a bug report from one Matteo Corti on
FC6; the same search in Google groups gives Matteo’s bug and the discussion
on that only. And the only time the string occurs in my local archive of the
last two years of XEmacs mail is where Stephen is replying to a bug report
from François Jouve last Friday.
--
Santa Maradona, priez pour moi!
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
8:17 p.m.
On Thu, 2006-11-16 at 03:25 +0900, Stephen J. Turnbull wrote:
Ville Skyttä writes:
> And as the maintainer of said packages already for a while, I'd
> appreciate some details about the bugs you're referring to (or if you
> don't have the details, info where you've heard about them),
It was reported here within the last two weeks that in those packages
one gets errors about "not a coding category: iso-8859-15".
Ok, without knowing the context, it smells like a bug in the packages'
site-start.el language environment setup stuff that was reported some
time ago: https://bugzilla.redhat.com/213582
By the way, once it graduates, hopefully the patch Aidan posted recently
about language environment auto-setup will make that stuff unnecessary.
Mike, the part of the site-start.el being discussed is derived from the
SuSE XEmacs packages, so you may be interested in taking a look at the
above report and to check if the SuSE packages are affected too.
I'd never heard of such a bug before. I told the reporter to
report
to Fedora, as it doesn't make any sense to me.
Thanks. No problem with that obviously, but I found the wording and
generalization in your reply to the next user of said OS who dared to
ask something probably entirely unrelated strange and somewhat
offensive.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
2:23 a.m.
Ville Skyttä writes:
Thanks. No problem with that obviously, but I found the wording and
generalization in your reply to the next user of said OS who dared to
ask something probably entirely unrelated strange and somewhat
offensive.
Ville, nothing personal, but nobody has recommended that anybody
distribute 21.5. We tell individual users in certain circumstances
(Mule on Windows, Xft, etc) to use it, but that implies a level of
sophistication way above what yum requires. I don't want *any*
reports on alpha-quality code in Mule and Xft from people who cannot
build XEmacs themselves; we don't have time---right now the project
has only one active core developer (and that's Aidan, not me).
Obviously many users who sure can build XEmacs themselves will use the
packaged version for convenience, but the average quality of report is
surely going to be much lower than from the DIY crowd.
If you want to distribute, you are going to have to answer for your
patches and your site-start, just as any user has to answer for his
patches and init file. Fedora users should go to Fedora *first*, SuSE
users should go to SuSE *first*, and so on, because we can't answer
questions about code we can't see.
What do I mean by "answer for"? How about we create a repository for
packaging, say etc/distros/{fedora-core,suse,debian,gentoo,mandriva,
freebsd,macports,...}, which you distro-based maintainers can update
with your packaging meta-data and patches? I know Debian has its
patch file which creates the ./debian directory etc, I suppose you
must have a metadata format for organizing each package. Just shlep
it in, commit, and tag with your package version. Of course this
wouldn't be distributed in tarballs, and it should be a separate repo
(eg, in the XEmacs packages tree).
Then when I get a report from a Fedora user, I can check out the
relevant patches to see what they're using; if there's no tag for that
rpm, *then* I'll send them to you.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta
6407
days inactive
6410
days old
9 comments
6 participants
participants (6)
-
Aidan Kehoe -
David Kastrup -
Peter Gordon -
Reiner Steib -
Stephen J. Turnbull -
Ville Skyttä