tlug: Re: Emacs 20

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Krister" == Krister Joas <joask@example.com> writes:

    Krister> Craig Oda writes:
    >> you solved my problem.  Thank you.  I'm not that familiar with
    >> emacs, is fontset a new feature?  I wonder why I have to set
    >> the font to fontset-standard, shouldn't this be the default?

    Krister> I'm glad I could be of help.  The concept of fontsets has
    Krister> been around for a while, at least in earlier versions of
    Krister> Mule but I don't remember if was called something

Actually, Mule adopted it from X11R5 AFAIK.

    Krister> different.  I think fontsets are meant as a way to
    Krister> collect fonts which work together.  In my opinion this is

A fontset is an (as yet imperfect) attempt to collect the necessary
fonts to display all the charsets used by a locale.  One problem is
that this naturally got overloaded with face (eg, italic, bold) as
well as charset (ie, kanji, romaji, half-width kana).

    Krister> a big win compared to the heuristics used by XEmacs,
    Krister> which gets it wrong 90% of the time.  Scaling fonts is

XEmacs can use fontsets.  The resource works correctly when XEmacs is
built with that option.  However, this conflicts with use of XIM due
to buggy Xlibs, so the default is not to use it.  XIM gets precedence
because it was desired by Sun which was providing substantial
financial support.

    Krister> usually a bad idea in X, it looks terrible, especially

Not if you can afford scalable fonts.  They don't look as good as
tuned bitmap fonts, but they look OK.  More Sun influence....

    Krister> the Japanese fonts.  Regardless of how atrocious the
    Krister> innards of vanilla Emacs is compared to XEmacs, the FSF
    Krister> people at least manages fonts much better from a user's

Depends on whether you want ease of use or customizability.  XEmacs is 
much better at providing custom faces.  The tradeoff is that for
Japanese the number of customizations needed is squared because of the 
need for multiple charsets.

    >> I have one other question, have you been able to get bash to
    >> run within term of emacs and get it to display Japanese from
    >> the shell?  M-x term

    Krister> Hmm, I don't really know off hand but I would guess that
    Krister> you have to fiddle around with process coding systems.
    Krister> Have a look at the function set-process-coding-system for
    Krister> instance.  There might be a higher level interface too.

These functions are seriously broken in XEmacs.  Morioka-san did a lot 
of synching of XEmacs Mule with FSFmacs Mule just before the release
of XEmacs 20.3, but this was not included.  I think it was because at
that time they were still broken in FSF Mule.  Be careful.

    Krister> be because of bugs in Emacs.  I'll have a look later.

Despite what I said, maybe not.  Experimentation might give somethign
workable.

    Krister> The Mule part of Emacs 20 is actually reasonably well
    Krister> documented.  Check out the chapter about I18N in the info
    Krister> documentation.

Cool!

    >> GNU Emacs 20.2 seems considerably faster than XEmacs 20.3.

    Krister> Absolutely, XEmacs is just painfully slow.  Unfortunately

I generally don't find that to be true except when XEmacs is doing
things that AFAIK Emacs doesn't support yet (like inline graphics in
W3 or MIME documents).  I do find that large folders in VM tend to
slow things down, due to autosaves.

Also, I don't know how well XEmacs in an xterm compares to FSFmacs in
a frame in terms of capabilities, but that's much faster than XEmacs
in a frame due to much less garbage collection.  Most of the beta
testers for XEmacs believe that 20.x without Mule is much faster than
19.x (which never had Mule), and some feel 20.x without Mule is
somewhat faster than XEmacs 19.34.  (It's also faster than FSF Emacs
20, but that's not a fair comparison because of the Mule overhead.)

    Krister> vm isn't supported yet (but I use it anyway) on Emacs 20.
    Krister> One of these days I'll see if I can't make vm a little
    Krister> more well behaved with Emacs.

VM is not likely to be supported well in the near future by FSF Emacs
because Stallman made a design decision not to support some of the
abstractions that VM needs.  :-(
---------------------------------------------------------------
TLUG Meeting: To be announced
---------------------------------------------------------------
a word from the sponsor:
TWICS - Japan's First Public-Access Internet System
www.twics.com  info@example.com  Tel:03-3351-5977  Fax:03-3353-6096