Date: Sun, 10 May 1998 21:49:37 +0900 From: KIRIYAMA Kazuhiko <kiri@kiri.toba-cmt.ac.jp> To: garyj@peedub.muc.de Cc: freebsd-ports@FreeBSD.ORG Subject: Re: ports/6548: New port: xemacs-mule-20.4 Message-ID: <19980510214937R.kiri@kiri.toba-cmt.ac.jp> In-Reply-To: Your message of "Sat, 9 May 1998 15:00:01 -0700 (PDT)" <199805092200.PAA19078@freefall.freebsd.org> References: <199805092200.PAA19078@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Dear Gary Jennejohn.
In Message-ID: <199805092200.PAA19078@freefall.freebsd.org>
Gary Jennejohn <garyj@peedub.muc.de> wrote :
> >>Description:
> >
> > I've made NEW ports xemacs-mule-20.4 which enables to treat
> > multilingal features of xemacs so-called "Mule" especially for
> > non-Latin people. This ports focus to Japanese with
> > Canna,Wnn4,Wnn6,SJ3 and SKK japanese input methods, but
> > extentions to any other languages such as Chinese or Korean
> > will be able to easily establish.
> >
>
> what does a separate xemacs-mule-20.4 port gain over doing
> ``USE_MULE=1 make install''
> with the existing xemacs-20.4 port ??
There are many points to gain over existing
editors/xemacs20. Especally following two points are important.
(1) Waste too long times and too spend resources to get *XEmacs Mule ports*
As you know, XEmacs is too big even though in binaries. Many user
for Japanese, Chinese or Korean doesn't want to spend long long
times for compiling from sources. It should be present as packages
of *XEmacs Mule ports*
(2) Can't enough supports input methods for Japanese, Chinese or
Korean
Apart from non-Latin people, we have specail characters and usages
in individual country, so we must transform alphbets to respective
language characters. Canns, Wnn4, Wnn6, SKK and SJ3 are these
tranform programs. Especially Wnn* are used in Japanese, Chinese or
Korean. It should be included in these input programs in *XEmacs
Mule ports*.
> Have you tried that out ?
No, but may be same as editors/xemacs-mule. I think that XEmacs ports
should be separate Latin XEmacs-port (existing editors/xemacs20) and
*XEmacs Mule ports*, at following points.
(1) Too different performance
According to ftp://ftp.xemacs.org/pub/tux/xemacs/xemacs-20.4/README,
Mule support reduce performancs more over 30% from non-Mule-XEmacs.
(2) Too different sizes
XEmacs/Mule is much more 32% to XEmacs in source level(with packed).
May be binaries are different as well.
(3) Can't be same as common region(architechcure indeoendent parts)
There can't be same common binaries(architechcure indeoendent parts)
between XEmacs(Latin) and XEmacs/Mule. So it can't be merge Latin
XEmacs-port and *XEmacs Mule ports*. Especially, as we take method to
keep common binary part and bring to additional binaries according to
indevidual language input methods for the sake of reducing resulting
binaries, so this is fatal.
> I won't address the japanese specific parts.
I think you've understand why I dared to make *XEmacs Mule ports*.
________________________________________________________________________
KIRIYAMA Kazuhiko <kiri@kiri.toba-cmt.ac.jp> Toba National College of
Maritime Technology
Department of Electronic Mechanical Engineering
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980510214937R.kiri>