7:52 p.m.
If building with XFontSet support (--with-xfs), I think it would be neat
to also get *menubar*FontSet stuff in Emacs.ad enabled by default,
instead of *menubar*Font.
I don't know if this is a piece of cake to implement, if not, maybe a
line or two in the configure output that would advice the user to do
this manually would be nice.
RedHat builds --with-xfs, and below is the patch they (have to) apply to
Emacs.ad to get the menubars look nice.
--- xemacs-21.1.14/etc/Emacs.ad.xfs Fri Jun 22 10:20:01 2001
+++ xemacs-21.1.14/etc/Emacs.ad Fri Jun 22 10:20:35 2001
＠＠ -196,8 +196,8 ＠＠
! *menubar*FontSet: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*, \
! -*-*-*-*-*-*-*-120-*-jisx0208.1983-0
!
-*menubar*Font: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*
-*popup*Font: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*
+*menubar*FontSet: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*
+*popup*FontSet: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*
! Font in the Motif dialog boxes.
! (Motif uses `fontList' while most other things use `font' - if you don't
--
\/ille Skyttä
ville.skytta at xemacs.org
2:20 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> If building with XFontSet support (--with-xfs), I think it
Ville> would be neat to also get *menubar*FontSet stuff in
Ville> Emacs.ad enabled by default, instead of *menubar*Font.
Go ahead and apply the patch to 21.5. I'll have to take a look at it
before putting it in 21.4, but I think our code will handle this
whether it's with-mule or not.
Red Hat really really sucks. There is no excuse whatsoever for not
passing this kind of trivial patch back upstream. Even less for not
informing us about the Hannibal Lecter ld (both Debian and SuSE did,
by contrast).
I think I'm going to go through the patches applied by the major
distros, and make a Hall of OSS Shame page, listing their NON-
contributions.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
6:43 a.m.
>>>> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
Stephen> I think I'm going to go through the patches applied by the major
Stephen> distros, and make a Hall of OSS Shame page, listing their NON-
Stephen> contributions.
hey stephen do you want the FreeBSD patches for 21.4.8
i can gzip them and email them to you if you wish :)
--
XEmacs Advocate | Do not try the patience of Wizards,
FreeBSD Devote | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver at xemacs.org> <GnuPG KeyID: AE51D190>
8:29 p.m.
On Tue, 2002-08-27 at 04:20, Stephen J. Turnbull wrote:
Ville> If building with XFontSet support (--with-xfs), I think
it
Ville> would be neat to also get *menubar*FontSet stuff in
Ville> Emacs.ad enabled by default, instead of *menubar*Font.
Go ahead and apply the patch to 21.5. I'll have to take a look at it
before putting it in 21.4, but I think our code will handle this
whether it's with-mule or not.
But I don't think that patch does The Right Thing. The patch
unconditionally removes *menubar*Font entries in Emacs.ad, which I think
will screw people not building --with-xfs. As long as RH is building
--with-xfs, they can safely apply it.
Instead, I think the real fix would be to put the *menubar*Font stuff
and *menubar*FontSet things in Emacs.ad inside some #ifdef -like things,
and the build process would enable the correct one of those, based on if
XFontSet support is requested when building. Or if it doesn't hurt
anyone, maybe just enable both *Font and *FontSet by default.
If I knew how to do the #ifdef -like stuff, I would already have done
it. Too bad it's beyond my autoconf/Makefile skills, so please someone
pick this one it up...
Red Hat really really sucks. There is no excuse whatsoever for not
passing this kind of trivial patch back upstream. Even less for not
informing us about the Hannibal Lecter ld (both Debian and SuSE did,
by contrast).
:/ I've been working a bit with the spec file for the RPM they have in
rawhide, and as of now, AFAICT all my fixes to it have been applied
(except for upgrading to 21.4.9) in the latest RPM, 21.4.8-16 (not at
ftp.redhat.com yet). Maybe we'll see a pretty sane XEmacs in their next
version.
I think I'm going to go through the patches applied by the major
distros, and make a Hall of OSS Shame page, listing their NON-
contributions.
Hihi...
Anyway, to save you some trouble, here's the other patch (there are 2 in
total) RH applies to their XEmacs, I don't really have a clue if it's
useful or Bad. It's called "xemacs-21-cursor.patch", is pretty old and
looks like it applies to the GTK version (no, they're not building a GTK
XEmacs). I can forward comments upstream.
--- gtk-xemacs/src/redisplay-tty.c.cursor Tue Nov 28 18:24:15 2000
+++ gtk-xemacs/src/redisplay-tty.c Tue Nov 28 18:25:09 2000
＠＠ -1236,7 +1236,7 ＠＠
}
TTY_SD (c).cursor_visible = tgetstr ("ve", &bufptr);
- TTY_SD (c).cursor_normal = tgetstr ("vs", &bufptr);
+ TTY_SD (c).cursor_normal = tgetstr ("ve", &bufptr);
TTY_SD (c).init_motion = tgetstr ("ti", &bufptr);
TTY_SD (c).end_motion = tgetstr ("te", &bufptr);
TTY_SD (c).keypad_on = tgetstr ("ks", &bufptr);
--
\/ille Skyttä
ville.skytta at xemacs.org
3:59 a.m.
>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> But I don't think that patch does The Right Thing. The
Ville> patch unconditionally removes *menubar*Font entries in
Ville> Emacs.ad, which I think will screw people not building
Ville> --with-xfs. As long as RH is building --with-xfs, they can
Ville> safely apply it.
Ah, OK. Just uncomment the menubar*FontSet part. If --with-xfs=no,
XEmacs totally ignores FontSet resources. If --with-xfs=yes, XEmacs
prefers the FontSet resource, then falls back to the Font resource.
Ie, the #ifdef'ing is done by XEmacs resource management. ;-)
Ville> :/ I've been working a bit with the spec file for the RPM
Ville> they have in rawhide, and as of now, AFAICT all my fixes to
Ville> it have been applied (except for upgrading to 21.4.9) in
Ville> the latest RPM, 21.4.8-16 (not at ftp.redhat.com yet).
It's not the sanity of their XEmacs that's at issue. Although I rant
about them and Mandrake, it's free software. They can and should do
what they like---as long as they don't ask _us_ to support _their_ users.
It's their general practice of withholding[1] improvements from the
community. Then people build our version, and report to us bugs that
Red Hat has uncontributed fixes for, and normal behavior that Mandrake
has turned into a bug by changing the behavior of their XEmacs
version.
Footnotes:
[1] Yes, insiders tell me that management is aware of the issue but
provides no positive incentive to developers to send patches upstream.
Whether this is "evil" or not is arguable, but certainly I feel much
more comfortable with Debian maintainers who generally make themselves
familiar to the upstream project.
I know the SuSE maintainer from another forum, so it's not fair to
compare SuSE vs. Red Hat on this (and SuSE is primarily responsible
for the multibyte brain damage in XFree86 that I've ranted about
elsewhere, I believe). However, our relationship does show that
commercial distros can profitably be friends with upstream
maintainers. Just as we (especially _you_) try to maintain good
relationships with the package maintainers who are upstream from _us_.
OTOH, maybe that lack of relationship just shows the low rank of
XEmacs in the Red Hat scheme of priorities. If you've got time, maybe
you could butter up the Red Hat guy and get them to promote us. Eg,
provide a GTK build.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
11:49 p.m.
On Wed, 2002-08-28 at 05:59, Stephen J. Turnbull wrote:
Ville> But I don't think that patch does The Right Thing.
The
Ville> patch unconditionally removes *menubar*Font entries in
Ville> Emacs.ad, which I think will screw people not building
Ville> --with-xfs. As long as RH is building --with-xfs, they can
Ville> safely apply it.
Ah, OK. Just uncomment the menubar*FontSet part. If --with-xfs=no,
XEmacs totally ignores FontSet resources. If --with-xfs=yes, XEmacs
prefers the FontSet resource, then falls back to the Font resource.
Ie, the #ifdef'ing is done by XEmacs resource management. ;-)
Allright, neat. The patch has just appeared in xemacs-patches.
Ville> :/ I've been working a bit with the spec file for
the RPM
Ville> they have in rawhide, and as of now, AFAICT all my fixes to
Ville> it have been applied (except for upgrading to 21.4.9) in
Ville> the latest RPM, 21.4.8-16 (not at ftp.redhat.com yet).
It's not the sanity of their XEmacs that's at issue. Although I rant
about them and Mandrake, it's free software. They can and should do
what they like---as long as they don't ask _us_ to support _their_ users.
Agreed, but I'm afraid they don't have to ask. At least some of their
users will just ask us directly :/ We benefit from distros providing
better XEmacsen too.
--
\/ille Skyttä
ville.skytta at xemacs.org
1:50 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
SuSE is primarily responsible for the multibyte brain damage in
XFree86 that I've ranted about elsewhere, I believe
You mean stuff like Xutf8LookupString()?
Why do you think SuSE did that?
--
Mike Fabian <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
2:14 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> But I don't think that patch does The Right Thing. The
Ville> patch unconditionally removes *menubar*Font entries in
Ville> Emacs.ad, which I think will screw people not building
Ville> --with-xfs. As long as RH is building --with-xfs, they can
Ville> safely apply it.
Ah, OK. Just uncomment the menubar*FontSet part. If --with-xfs=no,
XEmacs totally ignores FontSet resources. If --with-xfs=yes, XEmacs
prefers the FontSet resource, then falls back to the Font resource.
Ie, the #ifdef'ing is done by XEmacs resource management. ;-)
Yes, it appears to be OK to leave the Font resources in, and just
add the fontSet resources.
--
Mike Fabian <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
2:40 p.m.
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Ville" == Ville Skytt <Ville>
writes:
Ville> If building with XFontSet support (--with-xfs), I think it
Ville> would be neat to also get *menubar*FontSet stuff in
Ville> Emacs.ad enabled by default, instead of *menubar*Font.
Go ahead and apply the patch to 21.5. I'll have to take a look at it
before putting it in 21.4, but I think our code will handle this
whether it's with-mule or not.
Red Hat really really sucks. There is no excuse whatsoever for not
passing this kind of trivial patch back upstream. Even less for not
informing us about the Hannibal Lecter ld (both Debian and SuSE did,
by contrast).
I have also applied a patch to the app-default files recently to
improve the behaviour especially in UTF-8 locales. I wanted
to submit it of course but I was busy and forgot. Sorry.
Patch attached. This patch just adds
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!! FontSet for menus when you use --with-xfs or --with-xim=xlib.
*fontSet:
-gnu-unifont-medium-r-normal--16-160-75-75-p-80-iso10646-1,-*-*-medium-r-normal--16-*-*-*-c-*-*-*
to all the app-default files for all currently available languages:
xemacs-21.4.8.orig/etc/Emacs.ad xemacs-21.4.8/etc/Emacs.ad
packages/mule-packages/locale/app-defaults/de/Emacs
packages/mule-packages/locale/app-defaults/fr/Emacs
packages/mule-packages/locale/app-defaults/ja/Emacs
packages/mule-packages/locale/app-defaults/ro/Emacs
I don't use
*FontSet: -*-helvetica-bold-r-*-*-*-120-*-*-*-*-iso8859-*
because this would neither work in ja_JP.eucJP nor in UTF-8 locales.
I believe the fontSet I am currently specifying is a reasonable
default, -*-*-medium-r-normal--16-*-*-*-c-*-*-* will match something
reasonable almost always. At least for the European languages,
Japanese, Korean, and simp. Chinese there are fonts matching that
pattern already in XFree86. Trad. Chines fonts matching that pattern
are in the GNU Intlfonts 1.2 packages. Therefore this pattern should
almost always work.
For iso10646-1 I explicitely specify the GNU Unicode font, because
-*-*-medium-r-normal--16-*-*-*-c-*-*-* would also match fonts
containing only half-width or only full-width characters in UTF-8
locale. This would not work well for ja_JP.UTF-8. I believe among the
bitmap fonts covering both half-width and full-width characters, the
GNU Unicode font is most likely to be installed. I know that it is
installed by default on SuSE Linux.
Therefore I believe the fontSet I chose above should almost always
work.
If XEmacs is started e.g. like
LANG=ja_JP xemacs
it won't find
/usr/share/xemacs/mule-packages/etc/app-defaults/ja/Emacs
there I create symlinks when installing in the xemacs.spec file:
# add Japanese translations for liece menus to Japanese app-defaults:
cat packages/xemacs-packages/liece/etc/Emacs.ad >>
/usr/share/xemacs/mule-packages/etc/app-defaults/ja/Emacs
# Make symlinks for international app-defaults:
ln -sf de /usr/share/xemacs/mule-packages/etc/app-defaults/de_DE
ln -sf de /usr/share/xemacs/mule-packages/etc/app-defaults/de_DE＠euro
ln -sf fr /usr/share/xemacs/mule-packages/etc/app-defaults/fr_FR
ln -sf fr /usr/share/xemacs/mule-packages/etc/app-defaults/fr_FR＠euro
ln -sf ja /usr/share/xemacs/mule-packages/etc/app-defaults/ja_JP
ln -sf ja /usr/share/xemacs/mule-packages/etc/app-defaults/ja_JP.ujis
ln -sf ja /usr/share/xemacs/mule-packages/etc/app-defaults/ja_JP.EUC
ln -sf ja /usr/share/xemacs/mule-packages/etc/app-defaults/ja_JP.eucJP
ln -sf ro /usr/share/xemacs/mule-packages/etc/app-defaults/ro_RO
and to make it work in the UTF-8 locales as well, I create UTF-8
versions of the app-defaults files from the original versions
and store them in xx_YY.UTF-8 directories:
# create international app-defaults for UTF-8 locales:
pushd /usr/share/xemacs/mule-packages/etc/app-defaults/
for i in de_DE fr_FR ja_JP ro_RO
do
mkdir $i.UTF-8
iconv -f $(LC_ALL=$i locale charmap) -t UTF-8 < $i/Emacs >
$i.UTF-8/Emacs
perl -pi -e 's/-\*- coding:.*-\*-/-\*- coding: utf-8 -\*-/'
$i.UTF-8/Emacs
done
popd
# install the standard app-defaults file used for all languages
# which don't have their own app-defaults file above:
mkdir -p /usr/X11R6/lib/X11/app-defaults/
install -m 644 etc/Emacs.ad /usr/X11R6/lib/X11/app-defaults/XEmacs
--
Mike Fabian <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
2:54 p.m.
New subject: Patch: use correct encoding for the output of LC_ALL=ja_JP.UTF-8 xemacs --help
Another small fix I recently applied to the SuSE xemacs package:
- use the correct encoding for the output of
'LC_ALL=ja_JP.eucJP xemacs --help',
'LC_ALL=ja_JP.UTF-8 xemacs --help', and
'LC_ALL=ja_JP.SJIS xemacs --help'.
Patches is here:
--- packages/mule-packages/locale/start-files/ja/locale-start.el 2000-03-10
08:41:32.000000000 +0100
+++ packages.new/mule-packages/locale/start-files/ja/locale-start.el 2002-08-19
23:35:24.000000000 +0200
＠＠ -78,6 +78,14 ＠＠
(defun command-line-do-help (arg)
"Print the XEmacs usage message and exit."
+ (let ((charmap (shell-command-to-string "locale charmap")))
+ (cond ((string-match "UTF-8" charmap)
+ (require 'un-define)
+ (set-terminal-coding-system 'utf-8))
+ ((string-match "EUC-JP" charmap)
+ (set-terminal-coding-system 'euc-jp))
+ ((string-match "SHIFT_JIS" charmap)
+ (set-terminal-coding-system 'shift_jis))))
(let ((standard-output 'external-debugging-output))
(princ (concat "\n" (emacs-version) "\n\n"))
(princ
--
Mike Fabian <mfabian(a)suse.de> http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。
3:48 a.m.
>>>> "Mike" == Mike Fabian
<mfabian(a)suse.de> writes:
Mike> "Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
> SuSE is primarily responsible for the multibyte brain damage in
> XFree86 that I've ranted about elsewhere, I believe
Mike> You mean stuff like Xutf8LookupString()?
Mike> Why do you think SuSE did that?
Dirk Hohndel seemed to think it was a good idea at Linux something or
other in '99 (maybe an early Li18nux meeting?), and there were another
SuSE person who is/was involved in Li18nux (Chris somebody? female)
who was talking about it at a Li18nux BOF at another Tokyo Linux
confabulation. To the best of my memory they were at least
encouraging its use as "the standard."
If I've misspoken, I'm very sorry. (And if you know where the idea
came from---ie, who pushed it---I'll correct my citation.)
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
7909
days inactive
7923
days old
10 comments
4 participants
participants (4)
-
Mike FABIAN -
Rendhalver [Peter Brown] -
Stephen J. Turnbull -
Ville Skyttä