Re: [tlug] epcEditor

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

>>>>> "Jim" == Jim Breen <jwb@example.com> writes:

    Jim> ["Stephen J. Turnbull" (Re: [tlug] epcEditor) writes:]

    >>> I'm sure the program has many admirable features, but for now,
    >>> "handling UTF-8 well" means interfacing to systems lacking a
    >>> wide selection of Unicode fonts and input methods.

    Jim> Hmmmm. I think you are being a leetle rough in that
    Jim> comment.

I don't think so.  The fact is, they can brag about UTF-8 support but
that requires nothing of them---Tcl surely does it all.  Doing UTF-8
well for people with "modern" (ie, not *nix) systems is like doing
ASCII well---just don't do something stupid.

And they do nothing to work around the warts of Tcl.  Of course that's
not the epc people's job, but I already made that point.  I don't see
why you want to give them a gold star for avoiding work that really is
needed to enable a large potential audience segment.

Give them a gold star for what they have done that is innovative and
excellent.  For example, if Charles is happy about their presentation
of a multi-Asian-script dictionary, that presumably means that they
got the simplified and traditional and Japanese hanzi straight.  That
deserves a lot of points in my book.  But that's presumably not a
matter of handling UTF-8 (eg, Plane 14 tags).  Rather, it's a matter
of respecting the XML language tags that I'm sure are embedded in the
dictionary DTD.

Of course, using culturally appropriate fonts is a no-brainer in ISO
2022, since X11 made the convenient decision to use ISO character set
registries as part of the font descriptor.  But if you write code that
does the right thing with <div emphasis="strong">, you should be able
to do the right thing with <div lang="zh_CN">.

Actually, I bet this font choice is even embedded in Charles's style
sheet, not something the editor does.  Handling style sheets well is
hard and admirable, and I doubt a thrown-together editor would do the
trick.

    Jim> If I were to set up a Japanese locale here, and sprinkle XIM
    Jim> holy water over Canna and kinput2 I could probably get
    Jim> Japanese input going.

You shouldn't have to do that.  I really don't understand why now that
we have a pretty good grasp of what would be better than rigid
adherence to POSIX and XIM, people insist in interpreting POSIX and no
more.  Ie, if the editor uses any control sequences containing plain
ASCII (ie, no buckybits) as commands, you almost certainly are not
going to much like what XIM does with them.  vi-like editors can be
easily made to work well with XIM---just push state and force XIM off
on exit from insert mode, then pop state on entry to insert mode.
Modeless editors are much harder to do.

    Jim> Some bright spark should throw together an open source XML
    Jim> editor. Of course, for the time being the Unix/Linux version
    Jim> will have exactly the same input shortcomings.

Emacs already has a validating SGML editor, so don't expect me to do
it.  :-)

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.