cxterm-devel — cxterm developers' discussion list

Re: [cxterm-devel] latest software

[<hin...@ya...>]

Yes, ifcss.org is defunct. But you can get it from:

http://sourceforge.net/projects/cxterm/

Prebuilt RPMS are available - made on glibc 2.2.5 
(slackware 9), and should be usable for Redhat
7.2 or 7.3 onwards.

Check the news items, and there are two post-5.2.3
enhancements, so you might want to get the CVS version
instead, or at least download about 5 files
from webCVS in addition to v5.2.3.

 --- Jun Sun <js...@ju...> wrote: > 
> hi,
> 
> I wonder where I can find the latest software
> package?
> ftp.ifcss.org site does not seem to be working.
> 
> Also, is there any pre-built RPM packages for redhat
> linux?
> 
> Thanks.
> 
> Jun
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An
> INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10%
> Monthly Commission!
> INetU Dedicated Managed Hosting
> http://www.inetu.net/partner/index.php
> _______________________________________________
> cxterm-devel mailing list
> cxt...@li...
>
https://lists.sourceforge.net/lists/listinfo/cxterm-devel 

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

[cxterm-devel] latest software

[Jun S. <js...@ju...>]

hi,

I wonder where I can find the latest software package?
ftp.ifcss.org site does not seem to be working.

Also, is there any pre-built RPM packages for redhat linux?

Thanks.

Jun

Re: [cxterm-devel] change screen rows (25) in cygwin

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

ho...@ya... wrote:
> Finally :) I got it right. I tried with the latest
> CXTERM code in CVS after updating Cygwin to the latest
> version. Termcap and terminfo are patched. Everything
> works fine now. Vi and Lynx works with any number of
> rows. Even resize works in realtime. Thank you very
> much.

Glad to hear. That's still a bit strange - 5.2.2 and 5.2.3
doesn't differ much by essence (just fixing some compiler
warnings, configure-based build on cygwin, etc) and
not in its terminal emulation handling anyway, and CVS only
differs from 5.2.3 by the addition of those termcap/terminfo
notes (unless the others had added stuff since). I am surprised
that simply adding the termcap/terminfo entries to 5.2.2
doesn't improve it immediately.

It is probably a mistake/oversight of the original authors
to remove the termcap/terminfo files - they were always,
and still are, bundled with almost any version of xterm out
there to go with the features as implemented in that version.
That way, even if the X-server and its bundled termcap/terminfo
has changed, it is still always possible to make the X-client
work properly.

Re: [cxterm-devel] change screen rows (25) in cygwin

[<ho...@ya...>]

Finally :) I got it right. I tried with the latest
CXTERM code in CVS after updating Cygwin to the latest
version. Termcap and terminfo are patched. Everything
works fine now. Vi and Lynx works with any number of
rows. Even resize works in realtime. Thank you very
much.

John


--- Hin-Tak Leung <hin...@ya...> wrote:
> That's very wierd... I just did it (attached
> screenshots).
> At first my vi looked broken, but then I remember I
> only had the terminfo
> installed, so I checked vi and indeed vi is linked
> against
> termcap, rather than ncurses, so I quickly appended
> the termcap as well, and it worked like a charm. I
> can
> even resize *after* launching either application
> to have the content resizing dynamically. (vi does
> resize dynamically,
> lynx just needs scrolling down and up again to
> pursuade it to do so).
> With these termcap and terminfo files, you should
> set TERM to "cxterm"
> (TERM is set to cxterm by default, in fact, if the
> termcap/terminfo
> entries are found - otherwise it is set to xterm
> which is very
> broken, because Xfree86's xterm is very much more
> advanced than
> the version of  xterm from which cxterm derived, and
> current Xfree86's
> xterm termcap/terminfo entry is very wrong for
> cxterm which is almost
> 8 years older). The correct way to install the
> termcap file is just
> to append to the system one ( "cat cxterm.termcap >>
> /etc/termcap"),
> and for terminfo, just to do "tic cxterm.terminfo".
> (The latter can be
> done by an ordinary user, in which case the terminfo
> file is
> installed under "$HOME/.terminfo/" rather than
> system-wide "/usr/share/terminfo"
> for installation by root).
> 
>
=================================================================
>  > ldd /usr/bin/vi
>          libtermcap.so.2 => /lib/libtermcap.so.2
> (0x4001d000)
>          libresolv.so.2 => /lib/libresolv.so.2
> (0x40022000)
>          libc.so.6 => /lib/libc.so.6 (0x40033000)
>          /lib/ld-linux.so.2 => /lib/ld-linux.so.2
> (0x40000000)
>  > ldd /usr/bin/lynx
>          libz.so.1 => /usr/lib/libz.so.1
> (0x4001d000)
>          libncurses.so.5 => /lib/libncurses.so.5
> (0x4002b000)
>          libssl.so.0 => /usr/lib/libssl.so.0
> (0x40067000)
>          libcrypto.so.0 => /usr/lib/libcrypto.so.0
> (0x40098000)
>          libc.so.6 => /lib/libc.so.6 (0x40195000)
>          libdl.so.2 => /lib/libdl.so.2 (0x402c8000)
>          /lib/ld-linux.so.2 => /lib/ld-linux.so.2
> (0x40000000)
>  > lynx --version
> Lynx Version 2.8.4rel.1 (17 Jul 2001)
> libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.7a
> Built on linux-gnu Mar  2 2003 15:40:43
> 
>  > vi --version
> elvis 2.1_4
> Copyright (c) 1995-1999 by Steve Kirkendall
>
================================================================
> 
> ho...@ya... wrote:
> > Thank you. I tried with 5.2.2 by appending the
> termcap
> > and converting the terminfo file with no error.
> But vi
> > and lynx still behave the same, only 25 lines.
> Resize
> > still doesn't work. Since my system is a little
> bit
> > messy right now, I will continue trying (cvs
> 5.2.4).
> > Thanks again.
> > 
> > John
> > 
> 

> ATTACHMENT part 2 image/png name=vi-syslog.png


> ATTACHMENT part 3 image/png name=lynx-yahoo.png
> # $Xorg: termcap,v 1.3 2000/08/17 19:55:10 cpqbld
> Exp $
> #
> cvs|cxterm|cxterm-24|cxterms|cvs100|cxterm terminal
> emulator (X Window System):\
> 	:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:\
> 	:rs=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:\
> 
> :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:DO=\E[%dB:UP=\E[%dA:\
> 	:LE=\E[%dD:RI=\E[%dC:\
> 	:al=\E[L:am:\
> 	:bl=^G:\
> 
>
:bs:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:co#80:\
> 	:cs=\E[%i%d;%dr:ct=\E[3g:\
> 	:dc=\E[P:dl=\E[M:\
> 	:ho=\E[H:\
> 	:im=\E[4h:ei=\E[4l:mi:\
> 	:ks=\E[?1h\E=:ke=\E[?1l\E>:\
> 	:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
> 
> :k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:\
> 	:k;=\E[21~:\
> 
> :F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\
> 
> :F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:\
> 	:kn#20:\
> 	:@0=\E[1~:kI=\E[2~:kD=\E[3~:\
> 	:*6=\E[4~:kP=\E[5~:kN=\E[6~:\
> 	:km:\
> 	:kb=^H:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:\
> 	:li#24:md=\E[1m:me=\E[m:mr=\E[7m:ms:nd=\E[C:pt:\
> 	:eA=\E)0:as=^N:ae=^O:\
> 	:ml=\El:mu=\Em:\
> 	:sc=\E7:rc=\E8:sf=\n:so=\E[7m:se=\E[m:sr=\EM:\
> 	:ti=\E7\E[?47h:te=\E[2J\E[?47l\E8:\
> 	:up=\E[A:us=\E[4m:ue=\E[m:xn:
> cv2|cxterm-65|cxterm with tall window 65x80 (X
> Window System):\
> 	:li#65:tc=cxterm:
> cvb|cxterm-bold|cxterm with bold instead of
> underline (X Window System):\
> 	:us=\E[1m:tc=cxterm:
> cvb|cxterm-boldso|cxterm with bold for standout (X
> Window System):\
> 	:so=\E[1m:tc=cxterm:
> #
> # vi may work better with this entry, because vi
> # doesn't use insert mode much
> cvi|cxterm-ic|cxterm-vi|cxterm with insert character
> instead of insert mode:\
> 	:im=:ei=:mi@:ic=\E[@:IC=\E[%d@:tc=cxterm:
> > # $Xorg: terminfo,v 1.3 2000/08/17 19:55:10 cpqbld
> Exp $
> # meml locks memory above the cursor; memu unlocks
> (ala HP terminals)
> #
> cxterm|cxterm-24|cxterms|cvs100|cxterm terminal
> emulator (X Window System),
> 	is2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>,
> 	rs2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>,
> 	am, bel=^G,
> 	cols#80, lines#24,
> 	clear=\E[H\E[2J, cup=\E[%i%p1%d;%p2%dH,
> 	csr=\E[%i%p1%d;%p2%dr,
> 	cud=\E[%p1%dB, cud1=\n, cuu=\E[%p1%dA, cuu1=\E[A,
> 	cub=\E[%p1%dD, cub1=\b,	cuf=\E[%p1%dC, cuf1=\E[C,
> 	el=\E[K, ed=\E[J,
> 	home=\E[H, ht=^I, ind=^J, cr=^M,
> 	km,
> 	smir=\E[4h, rmir=\E[4l, mir,
> 	smso=\E[7m, rmso=\E[m, smul=\E[4m, rmul=\E[m,
> 	bold=\E[1m, rev=\E[7m, blink@, sgr0=\E[m, msgr,
> 	enacs=\E)0, smacs=^N, rmacs=^O,
> 	smkx=\E[?1h\E=, rmkx=\E[?1l\E>,
> 	kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
> 	kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
> kf9=\E[20~,
> 	kf10=\E[21~,
> 	kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
> kf15=\E[28~,
> 	kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
> kf20=\E[34~,
> 	kfnd=\E[1~, kich1=\E[2~, kdch1=\E[3~,
> 	kslt=\E[4~, kpp=\E[5~, knp=\E[6~,
> 	kbs=\b,	kcuu1=\EOA, kcud1=\EOB, kcuf1=\EOC,
> kcub1=\EOD,
> 	meml=\El, memu=\Em,
> 	smcup=\E7\E[?47h, rmcup=\E[2J\E[?47l\E8,
> 	sc=\E7, rc=\E8,
> 	il=\E[%p1%dL, dl=\E[%p1%dM, il1=\E[L, dl1=\E[M,
> 	ri=\EM,
> 	dch=\E[%p1%dP, dch1=\E[P,
> 	tbc=\E[3g,
> 	xenl,
> cxterm-65|cxterm with tall window 65x80 (X Window
> System),
> 	lines#65,
> 	use=cxterm,
> cxterm-bold|cxterm with bold instead of underline (X
> Window System),
> 	smul=\E[1m, use=cxterm,
> cxterm-boldso|cxterm with bold for standout (X
> Window System),
> 	smso=\E[1m, use=cxterm,
> #
> # vi may work better with this entry, because vi
> # doesn't use insert mode much
> cxterm-ic|cxterm-vi|cxterm with insert character
> instead of insert mode,
> 	smir@, rmir@, mir@, ich1=\E[@, ich=\E[%p1%d@,
> use=cxterm,
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

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.

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

[Thomas W. <mi...@to...>]

Dear Hin-Tak Leung,

you wrote to Ziying Sherwin:

> If you could kindly point out where the errors are, we can correct them.

> Indeed, Kya, etc are somewhat like dipthoughs(spelling?) in English.
> A friend of mine (English, but married a Japanese lady) did mention
> something about that when I introduce him to cxterm a very long time
> ago.
> ...
> I have a very elementary understanding of Japanese (and I can always ask
> some
> Japanese friends if in doubt), so if you could tell me what you think
> they the corrections are, we'll consider putting it in.

> The tit files are in the source bundle, so if you can edit them and send
> over your modified version we'll discuss this further.
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 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?
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?


> In fact I do have two private dictionaries which I haven't included in
> the source - one is basically your idea of hirahana+katakana, plus
> all JIS level 1 kanji's in their Kan? readings in one mapping (I later
> realize On? reading is probably more useful as that's how Japanese
> people pronounce the kanji's); the other's ChangJie (the fastest Chinese
> input method) converted to do japanese Kanji input. They are both
> somewhat strange, and not to everybody's taste, but that's the
> strength of Cxterm's input system - it is extendable.
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.


> Ziying Sherwin wrote:
> > 
> > We have been using cxterm on the Unix platform. And We are glad to 
> > see somebody finally volunteering the maintainance work.
> > 
> > Recently, we noticed an error on the Japanese input mapping in files
> > HIRAGANA.cit, KATAKANA.cit and ROMKANA.cit. According to the
> > documentation
> > coming with the cxterm application, the double-character entries they
> > have
> > (like for "kya", "shu" in HIRAGANA.utf) should be multiple-choice
> > mappings.
> > But from my limited Japanese knowledge, they should be a two-character
> > mappings and not choices. The first character is in normal size and
> > the
> > second one in a smaller size located in the left bottom.
> > 
> > I just wonder whether my guess is valid. Do you happen to know where
> > the 
> > Japanese keyboard mapping files come from and whether they have been
> > used by 
> > native Japanese-speakers?

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

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

If you could kindly point out where the errors are, we can correct them.

The cit files are compiled from the tit files (which are basically
two-column tables with a small header of about 30 lines). Slightly off-topic,
I have already recently located the original authors and asked for their
permission to become official and other issues; but haven't heard from them yet.

Indeed, Kya, etc are somewhat like dipthoughs(spelling?) in English.
A friend of mine (English, but married a Japanese lady) did mention
something about that when I introduce him to cxterm a very long time ago.

AFAIIK, the Japanese parts are just there for "completeness" (and so is
the Korean part) and had not been shown much interest by the native speakers.
The Japanese have much more intuitive (to them) ways of inputting
characters than the primitive ones available within cxterm. The have complete
libraries (Wnn, Canna are some of the better known ones, which are shipped
with Redhat), and their own input mechanisms (called Kinput, I seems to
recall, which has nothing to do with KDE) which are quite a lot more advanced.
The native Japanese speakers do their typing rather differently than
how cxterm does Japanese - a close friend of mine (Japanese) run the
Japanese version of MacOS and the way he types is quite different,
and much easier to him.

I have a very elementary understanding of Japanese (and I can always ask some
Japanese friends if in doubt), so if you could tell me what you think
they the corrections are, we'll consider putting it in.

The tit files are in the source bundle, so if you can edit them and send
over your modified version we'll discuss this further.

(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...)

In fact I do have two private dictionaries which I haven't included in
the source - one is basically your idea of hirahana+katakana, plus
all JIS level 1 kanji's in their Kan? readings in one mapping (I later
realize On? reading is probably more useful as that's how Japanese
people pronounce the kanji's); the other's ChangJie (the fastest Chinese
input method) converted to do japanese Kanji input. They are both
somewhat strange, and not to everybody's taste, but that's the
strength of Cxterm's input system - it is extendable.

Ziying Sherwin wrote:
> 
> 
> I have been using cxterm on the Unix platform for a while. And I am glad to 
> see somebody finally volunteering the maintainance work.
> 
> Recently, we noticed an error on the Japanese input mapping in files
> HIRAGANA.cit, KATAKANA.cit and ROMKANA.cit. According to the documentation
> coming with the cxterm application, the double-character entries they have
> (like for "kya", "shu" in HIRAGANA.utf) should be multiple-choice mappings.
> But from my limited Japanese knowledge, they should be a two-character
> mappings and not choices. The first character is in normal size and the
> second one in a smaller size located in the left bottom.
> 
> I just wonder whether my guess is valid. Do you happen to know where the 
> Japanese keyboard mapping files come from and whether they have been used by 
> native Japanese-speakers?
> 
> Thanks. Ziying
> 
> 

Re: [cxterm-devel] change screen rows (25) in cygwin

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

That's very wierd... I just did it (attached screenshots).
At first my vi looked broken, but then I remember I only had the terminfo
installed, so I checked vi and indeed vi is linked against
termcap, rather than ncurses, so I quickly appended
the termcap as well, and it worked like a charm. I can
even resize *after* launching either application
to have the content resizing dynamically. (vi does resize dynamically,
lynx just needs scrolling down and up again to pursuade it to do so).
With these termcap and terminfo files, you should set TERM to "cxterm"
(TERM is set to cxterm by default, in fact, if the termcap/terminfo
entries are found - otherwise it is set to xterm which is very
broken, because Xfree86's xterm is very much more advanced than
the version of  xterm from which cxterm derived, and current Xfree86's
xterm termcap/terminfo entry is very wrong for cxterm which is almost
8 years older). The correct way to install the termcap file is just
to append to the system one ( "cat cxterm.termcap >> /etc/termcap"),
and for terminfo, just to do "tic cxterm.terminfo". (The latter can be
done by an ordinary user, in which case the terminfo file is
installed under "$HOME/.terminfo/" rather than system-wide "/usr/share/terminfo"
for installation by root).

=================================================================
 > ldd /usr/bin/vi
         libtermcap.so.2 => /lib/libtermcap.so.2 (0x4001d000)
         libresolv.so.2 => /lib/libresolv.so.2 (0x40022000)
         libc.so.6 => /lib/libc.so.6 (0x40033000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
 > ldd /usr/bin/lynx
         libz.so.1 => /usr/lib/libz.so.1 (0x4001d000)
         libncurses.so.5 => /lib/libncurses.so.5 (0x4002b000)
         libssl.so.0 => /usr/lib/libssl.so.0 (0x40067000)
         libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x40098000)
         libc.so.6 => /lib/libc.so.6 (0x40195000)
         libdl.so.2 => /lib/libdl.so.2 (0x402c8000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
 > lynx --version
Lynx Version 2.8.4rel.1 (17 Jul 2001)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.7a
Built on linux-gnu Mar  2 2003 15:40:43

 > vi --version
elvis 2.1_4
Copyright (c) 1995-1999 by Steve Kirkendall
================================================================

ho...@ya... wrote:
> Thank you. I tried with 5.2.2 by appending the termcap
> and converting the terminfo file with no error. But vi
> and lynx still behave the same, only 25 lines. Resize
> still doesn't work. Since my system is a little bit
> messy right now, I will continue trying (cvs 5.2.4).
> Thanks again.
> 
> John
> 

Re: [cxterm-devel] change screen rows (25) in cygwin

[<ho...@ya...>]

Thank you. I tried with 5.2.2 by appending the termcap
and converting the terminfo file with no error. But vi
and lynx still behave the same, only 25 lines. Resize
still doesn't work. Since my system is a little bit
messy right now, I will continue trying (cvs 5.2.4).
Thanks again.

John


--- Hin-Tak Leung <hin...@ya...> wrote:
> Figured out this problem finally. Commited to CVS
> but
> didn't made into 5.2.3, would be in 5.2.4 , I guess.
> 
> 
> Hin-Tak Leung wrote:
> > Don't know if you have solved this, but I just
> found
> > somewhat surprisingly that setting TERM to vt100
> > works far better than the default (xterm). Very
> strange.
> > 
> > ho...@ya... wrote:
> > 
> >> I tried it on Linux (Mandrake 9.0 2.4.19-16mdk)
> and
> >> found,
> >> - resize works automatically and manually
> >> - VI works - "stty rows" works
> >> - lynx rows and display are messy if the default
> >> terminal is "xterm". However, after I use "cxterm
> -tn
> >> rxvt -geometry 80x40" or "cxterm -tn vt220
> -geometry
> >> 80x40", it seems working correctly.
> >>
> >> For now I have not tried the latest cygwin.
> >>
> >> John
> >>
> > 
> > Screen corruption problem when using full-screen
> programs
> like lynx, emacs, or vi:
> ========================
> 
> Thanks to some hints on the web site of Thomas
> Dickey 
> (http://dickey.his.com/xterm/xterm.html) - author of
> xterm and
> some other programs on Xfree86. Basically he was
> complaining
> about most of the xterm derivatives on the market
> and said none of
> them does ANSI escape sequence properly (including
> CXterm). And
> he explained that xterm in the latest XFree86 does
> it far better...
> 
> There's the problem. CXterm uses the xterm
> termcap/terminfo entries.
> As xterm in XFree86 got better over the years, its
> termcap/terminfo
> entries had changed; whereas CXterm is essentially
> stuck in time
> with X Consortium's initial X11R6. In fact X.Org's
> latest X11R6.6
> ships the same termcap for their xterm as X
> Consortium did 10 years ago, 
> so the problem is just that XFree86 has moved
> onwards a lot. 
> 
> CXterm looks for a "cxterm" termcap/terminfo entries
> before falling
> back to those of xterm's. So to make CXterm work
> properly,
> just append "cxterm.termcap" to "/etc/termcap", and
> run 
> "tic cxterm.terminfo" as root so that some cxterm
> entries get
> added to the terminfo database. These two files are
> adapted from
> X.Org's X11R6.6.
>   
> --
> Hin-Tak Leung <ht...@us...>> #
$Xorg: terminfo,v 1.3 2000/08/17 19:55:10 cpqbld
> Exp $
> # meml locks memory above the cursor; memu unlocks
> (ala HP terminals)
> #
> cxterm|cxterm-24|cxterms|cvs100|cxterm terminal
> emulator (X Window System),
> 	is2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>,
> 	rs2=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>,
> 	am, bel=^G,
> 	cols#80, lines#24,
> 	clear=\E[H\E[2J, cup=\E[%i%p1%d;%p2%dH,
> 	csr=\E[%i%p1%d;%p2%dr,
> 	cud=\E[%p1%dB, cud1=\n, cuu=\E[%p1%dA, cuu1=\E[A,
> 	cub=\E[%p1%dD, cub1=\b,	cuf=\E[%p1%dC, cuf1=\E[C,
> 	el=\E[K, ed=\E[J,
> 	home=\E[H, ht=^I, ind=^J, cr=^M,
> 	km,
> 	smir=\E[4h, rmir=\E[4l, mir,
> 	smso=\E[7m, rmso=\E[m, smul=\E[4m, rmul=\E[m,
> 	bold=\E[1m, rev=\E[7m, blink@, sgr0=\E[m, msgr,
> 	enacs=\E)0, smacs=^N, rmacs=^O,
> 	smkx=\E[?1h\E=, rmkx=\E[?1l\E>,
> 	kf1=\EOP, kf2=\EOQ, kf3=\EOR, kf4=\EOS,
> 	kf5=\E[15~, kf6=\E[17~, kf7=\E[18~, kf8=\E[19~,
> kf9=\E[20~,
> 	kf10=\E[21~,
> 	kf11=\E[23~, kf12=\E[24~, kf13=\E[25~, kf14=\E[26~,
> kf15=\E[28~,
> 	kf16=\E[29~, kf17=\E[31~, kf18=\E[32~, kf19=\E[33~,
> kf20=\E[34~,
> 	kfnd=\E[1~, kich1=\E[2~, kdch1=\E[3~,
> 	kslt=\E[4~, kpp=\E[5~, knp=\E[6~,
> 	kbs=\b,	kcuu1=\EOA, kcud1=\EOB, kcuf1=\EOC,
> kcub1=\EOD,
> 	meml=\El, memu=\Em,
> 	smcup=\E7\E[?47h, rmcup=\E[2J\E[?47l\E8,
> 	sc=\E7, rc=\E8,
> 	il=\E[%p1%dL, dl=\E[%p1%dM, il1=\E[L, dl1=\E[M,
> 	ri=\EM,
> 	dch=\E[%p1%dP, dch1=\E[P,
> 	tbc=\E[3g,
> 	xenl,
> cxterm-65|cxterm with tall window 65x80 (X Window
> System),
> 	lines#65,
> 	use=cxterm,
> cxterm-bold|cxterm with bold instead of underline (X
> Window System),
> 	smul=\E[1m, use=cxterm,
> cxterm-boldso|cxterm with bold for standout (X
> Window System),
> 	smso=\E[1m, use=cxterm,
> #
> # vi may work better with this entry, because vi
> # doesn't use insert mode much
> cxterm-ic|cxterm-vi|cxterm with insert character
> instead of insert mode,
> 	smir@, rmir@, mir@, ich1=\E[@, ich=\E[%p1%d@,
> use=cxterm,
> > # $Xorg: termcap,v 1.3 2000/08/17 19:55:10 cpqbld
> Exp $
> #
> cvs|cxterm|cxterm-24|cxterms|cvs100|cxterm terminal
> emulator (X Window System):\
> 	:is=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:\
> 	:rs=\E7\E[r\E[m\E[?7h\E[?1;3;4;6l\E[4l\E8\E>:\
> 
> :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:DO=\E[%dB:UP=\E[%dA:\
> 	:LE=\E[%dD:RI=\E[%dC:\
> 	:al=\E[L:am:\
> 	:bl=^G:\
> 
>
:bs:cd=\E[J:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:co#80:\
> 	:cs=\E[%i%d;%dr:ct=\E[3g:\
> 	:dc=\E[P:dl=\E[M:\
> 	:ho=\E[H:\
> 	:im=\E[4h:ei=\E[4l:mi:\
> 	:ks=\E[?1h\E=:ke=\E[?1l\E>:\
> 	:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:\
> 
> :k5=\E[15~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:\
> 	:k;=\E[21~:\
> 
> :F1=\E[23~:F2=\E[24~:F3=\E[25~:F4=\E[26~:F5=\E[28~:\
> 
> :F6=\E[29~:F7=\E[31~:F8=\E[32~:F9=\E[33~:FA=\E[34~:\
> 	:kn#20:\
> 	:@0=\E[1~:kI=\E[2~:kD=\E[3~:\
> 	:*6=\E[4~:kP=\E[5~:kN=\E[6~:\
> 	:km:\
> 	:kb=^H:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:\
> 	:li#24:md=\E[1m:me=\E[m:mr=\E[7m:ms:nd=\E[C:pt:\
> 	:eA=\E)0:as=^N:ae=^O:\
> 	:ml=\El:mu=\Em:\
> 	:sc=\E7:rc=\E8:sf=\n:so=\E[7m:se=\E[m:sr=\EM:\
> 	:ti=\E7\E[?47h:te=\E[2J\E[?47l\E8:\
> 	:up=\E[A:us=\E[4m:ue=\E[m:xn:
> cv2|cxterm-65|cxterm with tall window 65x80 (X
> Window System):\
> 	:li#65:tc=cxterm:
> cvb|cxterm-bold|cxterm with bold instead of
> underline (X Window System):\
> 	:us=\E[1m:tc=cxterm:
> cvb|cxterm-boldso|cxterm with bold for standout (X
> Window System):\
> 	:so=\E[1m:tc=cxterm:
> #
> # vi may work better with this entry, because vi
> # doesn't use insert mode much
> cvi|cxterm-ic|cxterm-vi|cxterm with insert character
> instead of insert mode:\
> 	:im=:ei=:mi@:ic=\E[@:IC=\E[%d@:tc=cxterm:
> 


__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

Re: [cxterm-devel] change screen rows (25) in cygwin

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

Figured out this problem finally. Commited to CVS but
didn't made into 5.2.3, would be in 5.2.4 , I guess.


Hin-Tak Leung wrote:
> Don't know if you have solved this, but I just found
> somewhat surprisingly that setting TERM to vt100
> works far better than the default (xterm). Very strange.
> 
> ho...@ya... wrote:
> 
>> I tried it on Linux (Mandrake 9.0 2.4.19-16mdk) and
>> found,
>> - resize works automatically and manually
>> - VI works - "stty rows" works
>> - lynx rows and display are messy if the default
>> terminal is "xterm". However, after I use "cxterm -tn
>> rxvt -geometry 80x40" or "cxterm -tn vt220 -geometry
>> 80x40", it seems working correctly.
>>
>> For now I have not tried the latest cygwin.
>>
>> John
>>
> 

Re: [cxterm-devel] change screen rows (25) in cygwin

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

Don't know if you have solved this, but I just found
somewhat surprisingly that setting TERM to vt100
works far better than the default (xterm). Very strange.

ho...@ya... wrote:
> I tried it on Linux (Mandrake 9.0 2.4.19-16mdk) and
> found,
> - resize works automatically and manually
> - VI works 
> - "stty rows" works
> - lynx rows and display are messy if the default
> terminal is "xterm". However, after I use "cxterm -tn
> rxvt -geometry 80x40" or "cxterm -tn vt220 -geometry
> 80x40", it seems working correctly.
> 
> For now I have not tried the latest cygwin.
> 
> John
> 

Re: [cxterm-devel] change screen rows (25) in cygwin

[<ho...@ya...>]

I tried it on Linux (Mandrake 9.0 2.4.19-16mdk) and
found,
- resize works automatically and manually
- VI works 
- "stty rows" works
- lynx rows and display are messy if the default
terminal is "xterm". However, after I use "cxterm -tn
rxvt -geometry 80x40" or "cxterm -tn vt220 -geometry
80x40", it seems working correctly.

For now I have not tried the latest cygwin.

John


--- Hin-Tak Leung <hin...@ya...> wrote:
> On my linux box, vi (termcap) doesn't have this
> problem,
> but lynx (ncurses) does.
> 
> ==================================
> vi --version
> elvis 2.1_4
> 
> lynx --version
> Lynx Version 2.8.4rel.1 (17 Jul 2001)
> libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.6c
> Built on linux-gnu Apr 15 2002 17:51:47
> =================================
> 
> Now that's an interesting difference - if I remember
> correctly, cygwin ships vim for its vi clone. Also,
> lynx on my system doesn't exactly break - it is the
> *first* screen lynx draws which is of the wrong
> size;
> if you navigate, it seems to figure out the screen
> size afterwards. But the status stuff is still in
> the
> old (wrong) place. So it seems that the
> screen-refresh/screen-clear code is a bit broken.
> 
> ho...@ya... wrote:
> > Hi,
> > 
> > Both vi and lynx have the problem here. vi uses
> > termcap while lynx uses terminfo.
> > 
> > 
> >>What version of cygwin are you using? ("uname
> -a").
> >>
> > 
> > 
> > I haven't updated the cygwin core package for a
> long
> > time. It is,
> > CYGWIN_NT-5.1 MYSTAR 1.3.5(0.47/3/2) 2001-11-13
> 23:16
> > i686 unknow
> > 
> > I just made a quick switch to a newer version:
> > CYGWIN_NT-5.1 MYSTAR 1.3.12(0.54/3/2) 2002-07-06
> 02:16
> > i686 unknown
> > But the problem looks the same. I will find some
> time
> > to try the latest Cygwin.
> > 
> > Thanks,
> > ---
> > John
> > 
> > 
> > --- Hin-Tak Leung <hin...@ya...>
> wrote:
> > 
> >>That seems to a a genuine bug - or rather, a
> >>"feature";
> >>I think the idea is that CXTerm doesn't want
> >>daugter applications to know about the extra
> >>input area at the bottom, so it does some screwy
> >>thing
> >>with the columns, rows and doesn't quite pass
> along
> >>how
> >>big the screen is.
> >>
> >>Lynx has this problem, but vi does see the resize
> on
> >>my system (slackware 8.1).
> >>
> >>Hmm, I don't use CXterm under Cygwin anymore,
> >>but I don't think it had problem resizing even
> then.
> > 
> > 
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Tax Center - forms, calculators, tips, more
> > http://taxes.yahoo.com/
> > 
> > 
> >
>
-------------------------------------------------------
> > This SF.net email is sponsored by: SlickEdit Inc.
> Develop an edge.
> > The most comprehensive and flexible code editor
> you can use.
> > Code faster. C/C++, C#, Java, HTML, XML, many
> more. FREE 30-Day Trial.
> > www.slickedit.com/sourceforge
> > _______________________________________________
> > cxterm-devel mailing list
> > cxt...@li...
> >
>
https://lists.sourceforge.net/lists/listinfo/cxterm-devel
> > 
> 
> __________________________________________________
> Do You Yahoo!?
> Everything you'll ever need on one web page
> from News and Sport to Email and Music Charts
> http://uk.my.yahoo.com


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [cxterm-devel] change screen rows (25) in cygwin

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

On my linux box, vi (termcap) doesn't have this problem,
but lynx (ncurses) does.

==================================
vi --version
elvis 2.1_4

lynx --version
Lynx Version 2.8.4rel.1 (17 Jul 2001)
libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.6c
Built on linux-gnu Apr 15 2002 17:51:47
=================================

Now that's an interesting difference - if I remember
correctly, cygwin ships vim for its vi clone. Also,
lynx on my system doesn't exactly break - it is the
*first* screen lynx draws which is of the wrong size;
if you navigate, it seems to figure out the screen
size afterwards. But the status stuff is still in the
old (wrong) place. So it seems that the
screen-refresh/screen-clear code is a bit broken.

ho...@ya... wrote:
> Hi,
> 
> Both vi and lynx have the problem here. vi uses
> termcap while lynx uses terminfo.
> 
> 
>>What version of cygwin are you using? ("uname -a").
>>
> 
> 
> I haven't updated the cygwin core package for a long
> time. It is,
> CYGWIN_NT-5.1 MYSTAR 1.3.5(0.47/3/2) 2001-11-13 23:16
> i686 unknow
> 
> I just made a quick switch to a newer version:
> CYGWIN_NT-5.1 MYSTAR 1.3.12(0.54/3/2) 2002-07-06 02:16
> i686 unknown
> But the problem looks the same. I will find some time
> to try the latest Cygwin.
> 
> Thanks,
> ---
> John
> 
> 
> --- Hin-Tak Leung <hin...@ya...> wrote:
> 
>>That seems to a a genuine bug - or rather, a
>>"feature";
>>I think the idea is that CXTerm doesn't want
>>daugter applications to know about the extra
>>input area at the bottom, so it does some screwy
>>thing
>>with the columns, rows and doesn't quite pass along
>>how
>>big the screen is.
>>
>>Lynx has this problem, but vi does see the resize on
>>my system (slackware 8.1).
>>
>>Hmm, I don't use CXterm under Cygwin anymore,
>>but I don't think it had problem resizing even then.
> 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> cxterm-devel mailing list
> cxt...@li...
> https://lists.sourceforge.net/lists/listinfo/cxterm-devel
> 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

Re: [cxterm-devel] change screen rows (25) in cygwin

[<ho...@ya...>]

Hi,

Both vi and lynx have the problem here. vi uses
termcap while lynx uses terminfo.

> What version of cygwin are you using? ("uname -a").
> 

I haven't updated the cygwin core package for a long
time. It is,
CYGWIN_NT-5.1 MYSTAR 1.3.5(0.47/3/2) 2001-11-13 23:16
i686 unknow

I just made a quick switch to a newer version:
CYGWIN_NT-5.1 MYSTAR 1.3.12(0.54/3/2) 2002-07-06 02:16
i686 unknown
But the problem looks the same. I will find some time
to try the latest Cygwin.

Thanks,
---
John


--- Hin-Tak Leung <hin...@ya...> wrote:
> That seems to a a genuine bug - or rather, a
> "feature";
> I think the idea is that CXTerm doesn't want
> daugter applications to know about the extra
> input area at the bottom, so it does some screwy
> thing
> with the columns, rows and doesn't quite pass along
> how
> big the screen is.
> 
> Lynx has this problem, but vi does see the resize on
> my system (slackware 8.1).
> 
> Hmm, I don't use CXterm under Cygwin anymore,
> but I don't think it had problem resizing even then.


__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [cxterm-devel] change screen rows (25) in cygwin

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

That seems to a a genuine bug - or rather, a "feature";
I think the idea is that CXTerm doesn't want
daugter applications to know about the extra
input area at the bottom, so it does some screwy thing
with the columns, rows and doesn't quite pass along how
big the screen is.

Lynx has this problem, but vi does see the resize on
my system (slackware 8.1).

Hmm, I don't use CXterm under Cygwin anymore,
but I don't think it had problem resizing even then.
What version of cygwin are you using? ("uname -a").

ho...@ya... wrote:
> Hi,
> 
> I have this problem and don't know how to solve it. In
> cxterm, the number of rows is always 25 in
> applications like vi and lynx. I tried "stty rows 40"
> but "stty -a" showing rows not changed. I tried 25 in
> $LINES or $TERMCAP to 40. I tried modify /etc/termcap
> to remove lines/vi-entry or change 25 to 40. I tried
> convert the modified termcap to terminfo. None helped.
> I also noticed that "resize" didn't work and timeout.
> This is in Cygwin. Is it because the out-of-date
> version of cygwin that I am using? Could someone point
> out if there is a quick hack to modify some code in
> main.c to hardcode the 40. 
> 
> Thank you.
> 
> Regards,
> ---
> John
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Tax Center - forms, calculators, tips, more
> http://taxes.yahoo.com/
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> The most comprehensive and flexible code editor you can use.
> Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
> www.slickedit.com/sourceforge
> _______________________________________________
> cxterm-devel mailing list
> cxt...@li...
> https://lists.sourceforge.net/lists/listinfo/cxterm-devel
> 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

[cxterm-devel] change screen rows (25) in cygwin

[<ho...@ya...>]

Hi,

I have this problem and don't know how to solve it. In
cxterm, the number of rows is always 25 in
applications like vi and lynx. I tried "stty rows 40"
but "stty -a" showing rows not changed. I tried 25 in
$LINES or $TERMCAP to 40. I tried modify /etc/termcap
to remove lines/vi-entry or change 25 to 40. I tried
convert the modified termcap to terminfo. None helped.
I also noticed that "resize" didn't work and timeout.
This is in Cygwin. Is it because the out-of-date
version of cygwin that I am using? Could someone point
out if there is a quick hack to modify some code in
main.c to hardcode the 40. 

Thank you.

Regards,
---
John

__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - forms, calculators, tips, more
http://taxes.yahoo.com/

Re: [cxterm-devel] Error messages from installation

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

There is a file missing from the source bundle - I found this out about
1/2 year ago while building cxterm for Cygwin but haven't got
round to check it into CVS yet. Attached - just put it inside
the top-level directory. It is from automake 1.6.

Xin Li wrote:

>Hi,
>
>I typed "make" and got the following error
>
>make  all-recursive
>make[1]: Entering directory `/home/local/myhome/cxterm-5.2.2'
>Making all in cxterm
>make[2]: Entering directory `/home/local/myhome/cxterm-5.2.2/cxterm'
>source='button.c' object='button.o' libtool=no \
>depfile='.deps/button.Po' tmpdepfile='.deps/button.TPo' \
>depmode=none /bin/sh ../depcomp \
>gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c `test -f 'button.c' || echo
>'./'`button.c
>../depcomp: ../depcomp: No such file or directory
>make[2]: *** [button.o] Error 127
>make[2]: Leaving directory `/home/local/myhome/cxterm-5.2.2/cxterm'
>make[1]: *** [all-recursive] Error 1
>make[1]: Leaving directory `/home/local/myhome/cxterm-5.2.2'
>make: *** [all] Error 2
>
>Can anybody please help me? Thanks a lot in advance!
>
>Xin
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Get the new Palm Tungsten T 
>handheld. Power & Color in a compact size! 
>http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
>_______________________________________________
>cxterm-devel mailing list
>cxt...@li...
>https://lists.sourceforge.net/lists/listinfo/cxterm-devel
>
>  
>

[cxterm-devel] Error messages from installation

[Xin Li <xi...@al...>]

Hi,

I typed "make" and got the following error

make  all-recursive
make[1]: Entering directory `/home/local/myhome/cxterm-5.2.2'
Making all in cxterm
make[2]: Entering directory `/home/local/myhome/cxterm-5.2.2/cxterm'
source='button.c' object='button.o' libtool=no \
depfile='.deps/button.Po' tmpdepfile='.deps/button.TPo' \
depmode=none /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I..     -g -O2 -c `test -f 'button.c' || echo
'./'`button.c
../depcomp: ../depcomp: No such file or directory
make[2]: *** [button.o] Error 127
make[2]: Leaving directory `/home/local/myhome/cxterm-5.2.2/cxterm'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/local/myhome/cxterm-5.2.2'
make: *** [all] Error 2

Can anybody please help me? Thanks a lot in advance!

Xin

[cxterm-devel] cxterm big5 fonts

[<hin...@id...>]

Dear all,

Just got round to join the mailing list...

About the big5 font issue somebody posted a couple of months ago. 
A couple of japanese fonts and gb fonts comes with Xfree86/X-contrib 
for as long as I remember so they are available on most systems 
(all Xfree86-based systems [linux,FreeBSD, Cygwin...], Solaris, 
Tru64) but big5 standardization is a relatively late thing and 
didn't get into either Xfree86 or X contrib. So big5 font 
installation is normally required on a fresh system.
(I think the poster was lucky to have used a system which 
had the fonts installed previously).

As for Redhat 6.x/7.x, some recent linux system comes with
font servers and some extra CJK truetype fonts (Xfree86 bundles 
bitmap bdf/pcf fonts, and the cxterm font install also uses
bitmap fonts). For performance reasons, cxterm probably
should use/try bitmap font first, but I guess the launch script
should try to look for those true-type fonts also... something
to add to the TODO list... 

I'll try to add a note about this into the source distribution 
when I get round to do this.

Hin-Tak 

[cxterm-devel] .Xdefaults file

[Jun S. <js...@ju...>]

Somehow your reply took a long time get to my yahoo account
and your From field contains unresolvable domain name.

Anyhow, I check my ~/.Xdefaults.  There is nothing there related
to cxterm.

I am using RedHat Linux 6.2.

Jun

[Cxterm-devel] Re:

[Jun S. <jul...@ya...>]

On Wed, Mar 06, 2002 at 09:41:49PM -0500, Changsen Xu wrote:
> Could you try to use your mouse to click on "<" or ">",
> I can see previous/next 10 options with this method too.
>

Clicking works, but not pressing those keys.

I don't know for other, but clicking to choose is really troublesome
for me.

So it is a known bug then....  Maybe we should log it into the bug tracking
system so that we don't forget it later.

Jun

> Changsen
> 
> On Tue, 5 Mar 2002 19:55:46 -0800, Jun Sun wrote:
> > On Tue, Feb 26, 2002 at 06:43:17PM -0800, Changsen Xu wrote:
> > > Use "-/+" in stead of ">/<", 
> > 
> > That does not seem to work here.  So it works that way in your case?
> > 
> > Jun
> > 
> > > some developer before me made
> > > this change, maybe for compatibility with Windows, or just
> > > for easy to input ,/.
> > > 
> > > A cxterm-devel mailing list is just created, welcome to join
> > > and hack.
> > > 
> > > Regards,
> > > 
> > > Changsen
> > 
> > 

[Cxterm-devel] Re: font not found problem for -b5

[C.S. X. <xu...@ya...>]

There is one big5 font included, you need run "make
install-fonts"
to install it. Then `cxterm -b5` should work.

If you want to use other fonts, use 	`xlsfonts | grep
-i ...` to find its
name, replace old font name with it in the `cxterm`
script.

Changsen





__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/

[Cxterm-devel] Re: font not found problem for -b5

[Changsen Xu <cx...@nd...>]

There is one big5 font included, you need run "make install-fonts"
to install it. Then `cxterm -b5` should work.

If you want to use other fonts, use 	`xlsfonts | grep -i ...` to find its
name, replace old font name with it in the `cxterm` script.

Changsen

[Cxterm-devel] font not found problem for -b5

[Jun S. <jul...@ya...>]

Hi, guys,

I built and installed cxterm 5.22 on redhat 6.2.

When I tried to invoke 

	cxterm -b5

it gives

cxtermb5:  unable to open font "hku16et", trying "cclib16st"....
cxtermb5:  unable to locate a suitable Chinese font

I did not install the additional fonts.  I will try that in a moment.
However, what is interesting is that I think I actually have 
invoked this cxterm with -b5 before, and it worked.  Not sure why it
failed this time.

It also appears that my system don't have cclib16st font.  However
my system do have a bunch of "Song Ti" and "Fangsong Ti".  Is there a 
way I substitute with them?

Jun