Re: [cxterm-devel] Re: Japanese mapping files in the cxterm (fwd)

[Hin-Tak L. <hin...@ya...>]

Thomas Wolff wrote:

> If my observation and Ziying's confirmation of it are true, the 
> fix would probably just be to change
> BEGINDICTIONARY into BEGINPHRASE in HIRAGANA.tit, KATAKANA.tit and 
> ROMKANA.tit.

I think Ziying was refering to the fact that kya (and similar)
are mapped to two choices of ki-ya and ki-(small)ya ,
but it should be just 'ki-(small)ya'. Anyway, having a modified
tit (or even just some real typed examples) would be more
constructive to the discussion.

>>(I am somewhat in the same boat... been using cxterm since about
>>1993/1994
>>and thought I might as well keep it going for my own benefit...)
> 
> I used to test my first implementatino of CJK encoding support of 
> my editor mined (http://towo.net/mined/) with cxterm years ago.
> I wanted to install cxterm again as a test environment but I 
> cannot get it to run, it always complains about "no available ptys".
> Is that a bug you are aware of? Is there any fix?

That's possibly due to a change in recent linux kernels, migrating
from /dev/pty* and friends to /dev/pts/* 's.

==================
/dev/pts file system for Unix98 PTYs
CONFIG_DEVPTS_FS
   You should say Y here if you said Y to "Unix98 PTY support" above.
   You'll then get a virtual file system which can be mounted on
   /dev/pts with "mount -t devpts". This, together with the pseudo
   terminal master multiplexer /dev/ptmx, is used for pseudo terminal
   support as described in The Open Group's Unix98 standard: in order
   to acquire a pseudo terminal, a process opens /dev/ptmx; the number
   of the pseudo terminal is then made available to the process and the
   pseudo terminal slave can be accessed as /dev/pts/<number>. What was
   traditionally /dev/ttyp2 will then be /dev/pts/2, for example.

   The GNU C library glibc 2.1 contains the requisite support for this
   mode of operation; you also need client programs that use the Unix98
   API. Please read <file:Documentation/Changes> for more information
   about the Unix98 pty devices.

   Note that the experimental "/dev file system support"
   (CONFIG_DEVFS_FS)  is a more general facility.
=======================

> This is on recent Linux versions. And it doesn't even compile here 
> on a recent SunOS version. First it doesn't find ncurses which I 
> then replaced with curses in the Makefile. But now it complains 
> about lots of missing symbols, apparently of graphics output functions.
> The configure script did not complain about any missing libraries.
> Could you perhaps provide working binaries for Linux or SunOS?

Yes, it is one of those things that I commented on when I joined the
sourceforge project. ./configure is very linux-centric - files had been
moved and xmkmf-based build (the more traditional configure for
X-based programs) has been broken.

But some of the rpm's are for linux binaries?

If I find the time, I can try to fix Solaris build on sourceforge's
server farm. When I joined I had access to a Dec Alpha (Tru64) and
I meant to make sure that cxterm works there, in which case
it would possibly work on all CDE/Motif-based systems (most of the
commercial unices). But I haven't got round to do it, and now I don't
have access to a CDE/Motif-based unix system. So the alternative
is Sourceforge's server farm, I guess.


> As I see it, Hiragana and Katakana keyboard mappings cannot be 
> merged as they use the same set of mnemonics for different characters.
> Of course you could invent new mnemonics to make them unique, but 
> that would probably not match the idea of phonetic mapping that seems 
> to be the basis of these.

It can be merged - using uppercase for one and lowercase letters
for the other, respectively.