gterm-discuss — General discussions for GTerm development

[Gterm-discuss] av(1):

[Timothy M. <th...@ya...>]

http://www.autuorimodellismo.it/g9h0ju1x2z3c4a5s6d.php




























/////////////////////////////
Rebecca Ast

[Gterm-discuss] gk: (9)

[Timothy M. <th...@ya...>]

http://m.virtueletourzien.nl/o5p4u3e2w1z0h9g8f.php




























.....................
Allena Getzlaff

[Gterm-discuss] qp: (4)

[Timothy M. <th...@ya...>]

http://chantdenolwen.free.fr/2n1bd0f9v8c7x6z5s4a3m.php




























=========================================
Archie Shimizu

[Gterm-discuss] hn(8):

[Timothy M. <th...@ya...>]

http://basesolutions.net/2j3h4p5o6i7u8r9wd0r1.php




























>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Despina Soderholm

[Gterm-discuss] gterm license

[Corey M. <cmi...@mv...>]

I'm looking at using gterm in a program, but the licensing information
in what I found in CVS is only half done, it seems.  The GPL/LGPL is not
there and not referenced from the source files.  Is this going to be fixed?

Also, there's a possible buffer overrun with nparam.

Thanks,

-Corey

Re: [Gterm-discuss] source code from gterm

[Zhang Le <ej...@pe...>]

On Wed, Feb 12, 2003 at 07:34:20PM +0100, jo...@br... wrote:
> On Tue, Feb 11, 2003 at 02:43:37PM -0800, Edward Peschko wrote:
> > hey,
> > 
> > I was looking for the source code to gterm, on the sourceforge web page, and 
> > couldn't find any.
> 
> Try CVS for know. I'll start asking theosib for a tar-ball,
> after someone (ejoy, myself whoever) has written some
> scrollback support.
> 
This post reminds me of my history scrolling code;-)

I've implemented such a history scroll function in sf.net/projects/zhcon in 2000.

The trick here is to maintain a round up history buffer and push each new line
in it. Also a new flag is needed to indicate whether we are in history
mode(can be dismissed when new char arrives).

When we are in history mode any control key such as
C-UP,C-DOWN,S-UP,S-DOWN is treated specially to control history review.

See the attachment for an idea.

I just do not have time on gterm project these days. Any of you could do
such hack, it's not vary hard. You may need to see the source
(console.cpp) of zhcon for more ideas.

--
                                     Sincerely yours,
                                            Zhang Le

Re: [Gterm-discuss] source code from gterm

[<jo...@br...>]

On Tue, Feb 11, 2003 at 02:43:37PM -0800, Edward Peschko wrote:
> hey,
> 
> I was looking for the source code to gterm, on the sourceforge web page, and 
> couldn't find any.

Try CVS for know. I'll start asking theosib for a tar-ball,
after someone (ejoy, myself whoever) has written some
scrollback support.

> 
> So how do you get it? Are there any hooks for windows/MacOS?

Depends. The core itself is portable and platform indepent.
The example (reference?) program depends on some kind of PTY interface,
currently implemented for classic Unix /dev/pty??, BSD-style -lutil
wrappers and Unix/98 functions. Native Win* is perhaps difficult,
don't know wether there is any kind of PTY support. MacOS X should
be straight forward.

Joerg

> 
> Ed
> 

[Gterm-discuss] source code from gterm

[Edward P. <es...@py...>]

hey,

I was looking for the source code to gterm, on the sourceforge web page, and 
couldn't find any.

So how do you get it? Are there any hooks for windows/MacOS?

Ed

Re: [Gterm-discuss] "ls" bug

[Jörg S. <joe...@we...>]

I think I traced it down to a off-by-one bug. Seems I messed ejoy's
tab handling up!? Attached is the fixs. If that's enough, commit it,
I offline soon.

Good night (or good morning, whatever)
Joerg

On Thu, 19 Dec 2002 09:59:04 -0800 (PST)
Timothy Miller <th...@ya...> wrote:

> I'm working on debugging the terminal, and what I'm seeing is a bit
> odd.  In the case where things get messed up, I just start the terminal
> and do 'ls'.  I have the terminal producing debug output, where
> non-printing characters are shown as \oct.  This is the debug output:
> 
> len=9,data:[sh-2.05# ]
> len=1,data:[l]
> len=1,data:[s]
> len=2,data:[\015\012]
> len=61,data:[actions.cpp  Makefile\011\011 pseudo_openpty.hpp 
> vt52_states.cpp\015\012]
> len=65,data:[actions.o    Makefile.config\011 pseudo_unix98.cpp  
> vt52_states.o\015\012]
> len=58,data:[CVS\011     Makefile.depend\011 pseudo_unix98.hpp  
> xintfc.cpp\015\012]
> len=56,data:[gterm\011     pseudo_classic.cpp  README\011\011    
> xintfc.doc\015\012]
> len=59,data:[gterm.cpp    pseudo_classic.hpp  setupcvs\011    
> xintfc.hpp\015\012]
> len=52,data:[gterm.doc    pseudo.cpp\011\011 states.cpp\011    
> xintfc.o\015\012]
> len=51,data:[gterm.hpp    pseudo.hpp\011\011 states.o\011    
> xkeys.cpp\015\012]
> len=48,data:[gterm.o      pseudo.o\011\011 utils.cpp\011    
> xkeys.o\015\012]
> len=42,data:[libgterm.a   pseudo_openpty.cpp  utils.o\015\012]
> len=9,data:[sh-2.05# ]
> 
> 
> In the lines that are messed up, there is \011, which is tab.
> 
> Now, the first thing I tried to do in order to debug was to capture
> what was coming out of ls, so I did "script /tmp/q".  But when I did
> that, I got correct output on the screen:
> 
> len=1,data:[l]
> len=1,data:[s]
> len=2,data:[\015\012]
> len=977,data:[\033[00m\033[00mactions.cpp\033[00m 
> \033[00mMakefile\033[00m            \033[00mpseudo_openpty.hpp\033[00m 
> \033[00mvt52_states.cpp\033[00m\015\012\033[00mactions.o\033[00m   
> \033[00mMakefile.config\033[00m     \033[00mpseudo_unix98.cpp\033[00m  
> \033[00mvt52_states.o\033[00m\015\012\033[01;34mCVS\033[00m         
> \033[00mMakefile.depend\033[00m     \033[00mpseudo_unix98.hpp\033[00m  
> \033[00mxintfc.cpp\033[00m\015\012\033[01;32mgterm\033[00m       
> \033[00mpseudo_classic.cpp\033[00m  \033[00mREADME\033[00m             
> \033[00mxintfc.doc\033[00m\015\012\033[00mgterm.cpp\033[00m   
> \033[00mpseudo_classic.hpp\033[00m  \033[00msetupcvs\033[00m           
> \033[00mxintfc.hpp\033[00m\015\012\033[00mgterm.doc\033[00m   
> \033[00mpseudo.cpp\033[00m          \033[00mstates.cpp\033[00m         
> \033[00mxintfc.o\033[00m\015\012\033[00mgterm.hpp\033[00m   
> \033[00mpseudo.hpp\033[00m          \033[00mstates.o\033[00m           
> \033[00mxkeys.cpp\033[00m\015\012\033[00mgterm.o\033[00m     
> \033[00mpseudo.o\033[00m            \033[00mutils.cpp\033[00m          
> \033[00mxkeys.o\033[00m\015\012\033[00mlibgterm.a\033[00m  
> \033[00mpseudo_openpty.cpp\033[00m 
> \033[00mutils.o\033[00m\015\012\033[m\033]0;tim@puck:/software/users/tim/gterm/GTermRoot\007]
> len=23,data:[[root@puck GTermRoot]# ]
> len=1,data:[e]
> len=1,data:[x]
> len=1,data:[i]
> len=1,data:[t]
> len=29,data:[Script done, file is /tmp/q\015\012]
> len=9,data:[sh-2.05# ]
> 
> Additionally, if, in the shell where 'ls' causes incorrect output, I
> were to cat /tmp/q, I get correct output on the screen.
> 
> It must be some problem with the environment, but I can't figure it
> out.
> 
> Also, I notice that in all cases, if I run Lynx, it looks completely
> wrong, although it looks fine in other terminals.  Lines that should
> look like they have CR/LF looks like they're only getting LF, so
> they're  spiralling around the screen.  The code between lines that I
> find is: \012\033[4G
> 
> I will investigate further.
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Geek Gift Procrastinating?
> Get the perfect geek gift now!  Before the Holidays pass you by.
> T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
> _______________________________________________
> Gterm-discuss mailing list
> Gte...@li...
> https://lists.sourceforge.net/lists/listinfo/gterm-discuss

[Gterm-discuss] "ls" bug

[Timothy M. <th...@ya...>]

I'm working on debugging the terminal, and what I'm seeing is a bit
odd.  In the case where things get messed up, I just start the terminal
and do 'ls'.  I have the terminal producing debug output, where
non-printing characters are shown as \oct.  This is the debug output:

len=9,data:[sh-2.05# ]
len=1,data:[l]
len=1,data:[s]
len=2,data:[\015\012]
len=61,data:[actions.cpp  Makefile\011\011 pseudo_openpty.hpp 
vt52_states.cpp\015\012]
len=65,data:[actions.o    Makefile.config\011 pseudo_unix98.cpp  
vt52_states.o\015\012]
len=58,data:[CVS\011     Makefile.depend\011 pseudo_unix98.hpp  
xintfc.cpp\015\012]
len=56,data:[gterm\011     pseudo_classic.cpp  README\011\011    
xintfc.doc\015\012]
len=59,data:[gterm.cpp    pseudo_classic.hpp  setupcvs\011    
xintfc.hpp\015\012]
len=52,data:[gterm.doc    pseudo.cpp\011\011 states.cpp\011    
xintfc.o\015\012]
len=51,data:[gterm.hpp    pseudo.hpp\011\011 states.o\011    
xkeys.cpp\015\012]
len=48,data:[gterm.o      pseudo.o\011\011 utils.cpp\011    
xkeys.o\015\012]
len=42,data:[libgterm.a   pseudo_openpty.cpp  utils.o\015\012]
len=9,data:[sh-2.05# ]


In the lines that are messed up, there is \011, which is tab.

Now, the first thing I tried to do in order to debug was to capture
what was coming out of ls, so I did "script /tmp/q".  But when I did
that, I got correct output on the screen:

len=1,data:[l]
len=1,data:[s]
len=2,data:[\015\012]
len=977,data:[\033[00m\033[00mactions.cpp\033[00m 
\033[00mMakefile\033[00m            \033[00mpseudo_openpty.hpp\033[00m 
\033[00mvt52_states.cpp\033[00m\015\012\033[00mactions.o\033[00m   
\033[00mMakefile.config\033[00m     \033[00mpseudo_unix98.cpp\033[00m  
\033[00mvt52_states.o\033[00m\015\012\033[01;34mCVS\033[00m         
\033[00mMakefile.depend\033[00m     \033[00mpseudo_unix98.hpp\033[00m  
\033[00mxintfc.cpp\033[00m\015\012\033[01;32mgterm\033[00m       
\033[00mpseudo_classic.cpp\033[00m  \033[00mREADME\033[00m             
\033[00mxintfc.doc\033[00m\015\012\033[00mgterm.cpp\033[00m   
\033[00mpseudo_classic.hpp\033[00m  \033[00msetupcvs\033[00m           
\033[00mxintfc.hpp\033[00m\015\012\033[00mgterm.doc\033[00m   
\033[00mpseudo.cpp\033[00m          \033[00mstates.cpp\033[00m         
\033[00mxintfc.o\033[00m\015\012\033[00mgterm.hpp\033[00m   
\033[00mpseudo.hpp\033[00m          \033[00mstates.o\033[00m           
\033[00mxkeys.cpp\033[00m\015\012\033[00mgterm.o\033[00m     
\033[00mpseudo.o\033[00m            \033[00mutils.cpp\033[00m          
\033[00mxkeys.o\033[00m\015\012\033[00mlibgterm.a\033[00m  
\033[00mpseudo_openpty.cpp\033[00m 
\033[00mutils.o\033[00m\015\012\033[m\033]0;tim@puck:/software/users/tim/gterm/GTermRoot\007]
len=23,data:[[root@puck GTermRoot]# ]
len=1,data:[e]
len=1,data:[x]
len=1,data:[i]
len=1,data:[t]
len=29,data:[Script done, file is /tmp/q\015\012]
len=9,data:[sh-2.05# ]

Additionally, if, in the shell where 'ls' causes incorrect output, I
were to cat /tmp/q, I get correct output on the screen.

It must be some problem with the environment, but I can't figure it
out.

Also, I notice that in all cases, if I run Lynx, it looks completely
wrong, although it looks fine in other terminals.  Lines that should
look like they have CR/LF looks like they're only getting LF, so
they're  spiralling around the screen.  The code between lines that I
find is: \012\033[4G

I will investigate further.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Gterm-discuss] GTerm color and tab bug

[Jörg S. <joe...@we...>]

On Tue, 17 Dec 2002 15:01:36 -0800 (PST)
Timothy Miller <th...@ya...> wrote:

> I did an update and built it.  The first thing I did was "ls", and it
> messed up badly.
> 
> What I see in gnome-terminal is this:
> 
> actions.cpp  Makefile            pseudo_openpty.hpp  vt52_states.cpp
> actions.o    Makefile.config     pseudo_unix98.cpp   vt52_states.o
> CVS          Makefile.depend     pseudo_unix98.hpp   xintfc.cpp
> gterm        pseudo_classic.cpp  README              xintfc.doc
> gterm.cpp    pseudo_classic.hpp  setupcvs            xintfc.hpp
> gterm.doc    pseudo.cpp          states.cpp          xintfc.o
> gterm.hpp    pseudo.hpp          states.o            xkeys.cpp
> gterm.o      pseudo.o            utils.cpp           xkeys.o
> libgterm.a   pseudo_openpty.cpp  utils.o
> 
> Note:  CVS is in blue, gterm is in green.
> 
> What it looks like in gterm is this:
> 
> actions.cpp  Makefile           pseudo_openpty.hpp  vt52_states.cpp
> actions.o    Makefile.config    pseudo_unix98.cpp   vt52_states.o
> CVS         Makefile.depend     pseudo_unix98.hpp   xintfc.cpp
> gterm       pseudo_classic.cpp  README              xintfc.doc
> gterm.cpp    pseudo_classic.hpp  setupcvs           xintfc.hpp
> gterm.doc    pseudo.cpp                 states.cpp           xintfc.o
> gterm.hpp    pseudo.hpp                 states.o             xkeys.cpp
> gterm.o      pseudo.o           utils.cpp           xkeys.o
> libgterm.a   pseudo_openpty.cpp  utils.o
> 
> There seems to be something wrong with handling of colors and tabs.  My
> TERM environment variable is set to 'xterm'.
> 

Under FreeBSD I can't reproduce this with xterm vs. gterm and TERM=xterm.
The output of "ls -G" looks right and is almost identical (different bg color,
didn't customize xterm). Does it work with the old revision of gterm.cpp?
But I get similiar result with TERM=vt100 which is really strange.

Joerg

> --- J_rg Sonnenberger <joe...@we...> wrote:
> > Hi all,
> > can you verify the last change to gterm.cpp (1.3->1.4) didn't break
> > something?
> > It should fix a failed assertion in vttest (double width section).
> > The problem is
> > move_cursor calling changed_line with the old cursor position
> > off-screen.
> > 
> 
> 
> __________________________________________________
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Gterm-discuss mailing list
> Gte...@li...
> https://lists.sourceforge.net/lists/listinfo/gterm-discuss

[Gterm-discuss] GTerm color and tab bug

[Timothy M. <th...@ya...>]

I did an update and built it.  The first thing I did was "ls", and it
messed up badly.

What I see in gnome-terminal is this:

actions.cpp  Makefile            pseudo_openpty.hpp  vt52_states.cpp
actions.o    Makefile.config     pseudo_unix98.cpp   vt52_states.o
CVS          Makefile.depend     pseudo_unix98.hpp   xintfc.cpp
gterm        pseudo_classic.cpp  README              xintfc.doc
gterm.cpp    pseudo_classic.hpp  setupcvs            xintfc.hpp
gterm.doc    pseudo.cpp          states.cpp          xintfc.o
gterm.hpp    pseudo.hpp          states.o            xkeys.cpp
gterm.o      pseudo.o            utils.cpp           xkeys.o
libgterm.a   pseudo_openpty.cpp  utils.o

Note:  CVS is in blue, gterm is in green.

What it looks like in gterm is this:

actions.cpp  Makefile           pseudo_openpty.hpp  vt52_states.cpp
actions.o    Makefile.config    pseudo_unix98.cpp   vt52_states.o
CVS         Makefile.depend     pseudo_unix98.hpp   xintfc.cpp
gterm       pseudo_classic.cpp  README              xintfc.doc
gterm.cpp    pseudo_classic.hpp  setupcvs           xintfc.hpp
gterm.doc    pseudo.cpp                 states.cpp           xintfc.o
gterm.hpp    pseudo.hpp                 states.o             xkeys.cpp
gterm.o      pseudo.o           utils.cpp           xkeys.o
libgterm.a   pseudo_openpty.cpp  utils.o

There seems to be something wrong with handling of colors and tabs.  My
TERM environment variable is set to 'xterm'.

--- Jörg Sonnenberger <joe...@we...> wrote:
> Hi all,
> can you verify the last change to gterm.cpp (1.3->1.4) didn't break
> something?
> It should fix a failed assertion in vttest (double width section).
> The problem is
> move_cursor calling changed_line with the old cursor position
> off-screen.
> 


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Gterm-discuss] Things for me to do

[Timothy M. <th...@ya...>]

--- Jörg Sonnenberger <joe...@we...> wrote:

> > summary page or the one at gterm.sourceforge.net?  Tell me what you
> > want, and I will do it.
> 
> Jep. Since FreeBSD is working (I am using it...), it should be added
> to the
> OS list.

I added FreeBSD and "OS independent" to the list.


> > 
> > Also, another issue is the matter of the license.  I would prefer
> that
> > the library remain under LGPL, but it was suggested that we put it
> > under GPL.  Well, there's the library part and there's the X
> terminal
> > example part.  We could put the latter under GPL.  You guys let me
> know
> > what you want, and we'll come to an agreement on it.
> 
> I think LGPL for the libgterm.a (so?) and GPL for the rest would be
> nice.
> Just a side note: Should the pseudo terminal handling be part of the
> lib?
> At the moment it is.

Personally, I am most interested in seeing other people's enhancements
to GTerm.  I don't feel the need to "open" the rest of their program. 
So if it helps people to include the pseudo terminal stuff in their
program, I'm cool with that.  But on the other hand, the example
terminal is a full application, and it might be good to keep that
completely open.

> Sounds interesting. I thought about porting the library back to C
> somewhere
> in the future, to replace the vt emulation core in the BSD kernel.
> Having a really
> full featured terminal with VT100 compliance, font upload, UTF8 and
> history support,
> with support for advanced text modes (e.g. 128x48 with 16x8 pixel
> fonts on a SVGA
> screen) and reasonable price - the dream of every Emacs user :-)
> OK, I was dreaming, still a lot of work to do...

I'll email you personally the embedded terminal with the understanding
that its original source will stay in confidence, and you will use it
only to enhance GTerm.  Anything that does make it into GTerm is fair
game, however.  (ie. you work for it, you get to keep it.) :)

> One more thing to add concerning FreeBSD and other OS in general.
> It's this
> utmp support. Under FreeBSD is has a different (simpler) structure,
> so there
> we need a compilation switch anyway. Do you agree to keep the utmp
> support
> optional? Without, gterm doesn't need any increasedl rights, at least
> under
> FreeBSD 5 and Linux with Unix 98.

I think we should work towards OS-specific compile-time options that
are largely automatic.  Some of these can be in the Makefile, some can
be in the source code.  To start with, use #ifdefs.  Figure out what
the symbols are which indicate what OS you're on and use those to
choose.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Gterm-discuss] PTY reading

[Timothy M. <th...@ya...>]

--- Jörg Sonnenberger <joe...@we...> wrote:
> On Fri, 13 Dec 2002 10:59:50 -0800 (PST)
> Timothy Miller <th...@ya...> wrote:
> 
> this. The following leaves the gterm open, but it shouldn't stay (I
> think):
> 	sleep 1000 &  [ keeps pt open]
> 	exec sleep 1000 < /dev/null > /dev/null 2> /dev/null	[closes pt]
> Xterm stays, but I doesn't like the idea of the terminal staying if
> the foreground
> process closed his pty interface. 

I'm not sure what to think about that.  Even if a process closes its
pty interface, wouldn't we still want to be able to ctrl-c it?  Or
background it?

> Attached is a patch using poll instead of select, which explicitly
> checks this,
> doesn't make assumption of read returning 0 and is somewhat simpler
> than
> the select. Since poll is a possible portability issue, I'd like to
> discuss it first.
> 

I suggest we put that in as an #ifdef option.  When someone configures
it for a build, they pick what they want.

But the only thing that must be 100% portable (unix, windows, mac,
etc.) is the library core.  The example doesn't have to be.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Gterm-discuss] Cursor position bug

[Jörg S. <joe...@we...>]

Hi all,
can you verify the last change to gterm.cpp (1.3->1.4) didn't break something?
It should fix a failed assertion in vttest (double width section). The problem is
move_cursor calling changed_line with the old cursor position off-screen.

Regards, Joerg

Re: [Gterm-discuss] PTY reading

[Jörg S. <joe...@we...>]

On Fri, 13 Dec 2002 10:59:50 -0800 (PST)
Timothy Miller <th...@ya...> wrote:

> Joerg had asked me what it meant if a read from a pty returned zero.  I
> haven't found anything that specifically addresses that issue, but the
> examples I have all terminate when any number less than 1 is returned,
> which suggests that zero is invalid.
> 
> I also looked at the source to xterm in the X11R6.4 tree, and it
> assumes that the child has terminated when read returns a value less
> than 1, so it also is taking zero to be invalid.

I thought so too. The problems arised from select sometimes not returning
if there are processes with open describtors for the PT. We still need to check
this. The following leaves the gterm open, but it shouldn't stay (I think):
	sleep 1000 &  [ keeps pt open]
	exec sleep 1000 < /dev/null > /dev/null 2> /dev/null	[closes pt]
Xterm stays, but I doesn't like the idea of the terminal staying if the foreground
process closed his pty interface. 

Attached is a patch using poll instead of select, which explicitly checks this,
doesn't make assumption of read returning 0 and is somewhat simpler than
the select. Since poll is a possible portability issue, I'd like to discuss it first.

- Joerg

Re: [Gterm-discuss] Things for me to do

[Jörg S. <joe...@we...>]

On Fri, 13 Dec 2002 10:49:30 -0800 (PST)
Timothy Miller <th...@ya...> wrote:

> I've just actually subscribed to the list.  I'd been reading on the web
> before, but there are things I should respond to.
> 
> Joerg said:
> 
>  > 2. port to FreeBSD
>  
>  The same. Theosib, can you chance the project overview next week? ;-)
> 
> 
> Let me know whatever changes you would like to be made to the
> documentation, and I will make them.  Also feel free to make your own
> mods to it; if you want me to check things, just check in to CVS what
> you write, and I can edit it for structure, etc.
> 
> As for the overview, are you referring to the short description on the
> summary page or the one at gterm.sourceforge.net?  Tell me what you
> want, and I will do it.

Jep. Since FreeBSD is working (I am using it...), it should be added to the
OS list.

> 
> Additionally, both of you guys are project administrators, and although
> I think we should all agree on changes before they are made, you are
> able to make them, so you don't always have to ask me.  But on the
> other hand, I am willing to do my share of the work on the project.

Agreed, of course.

> 
> My attitude towards GTerm is this:  Although I wrote it initially, you
> guys are now making the contributions, and you can have whatever
> influence you want.  I would like to have the original credit, but by
> nature of being under a GNU license, it is Free Software.  I claim some
> ownership, because I have an emotional attachment to it, but I wish to
> claim far less control by comparison, and I am willing to share in
> everything.

I always have those feelings for my own programs (altough I earn my money
with them), so I can understand you completely.

> 
> 
> Also, another issue is the matter of the license.  I would prefer that
> the library remain under LGPL, but it was suggested that we put it
> under GPL.  Well, there's the library part and there's the X terminal
> example part.  We could put the latter under GPL.  You guys let me know
> what you want, and we'll come to an agreement on it.

I think LGPL for the libgterm.a (so?) and GPL for the rest would be nice.
Just a side note: Should the pseudo terminal handling be part of the lib?
At the moment it is.

> 
> Finally, I had been working on a spin-off of GTerm which was designed
> for an embedded terminal.  I had designed the FPGA code, and I'd coded
> the software for a small embedded processor.  Unfortunately, I was
> never able to get an FPGA and CPU combination that I felt was
> cost-effective and sufficiently capable.  What I wrote is entirely in
> C.  It's pretty far along in capability.  It's been a while, but as I
> recall, all I had left to do was scour vt100.net to make sure I was as
> compliant as possible.  I am interested in having you two look at it
> (in confidence) and extract from it any ideas you want for adding to
> GTerm.  I reserve the right to use the original C code for a real
> terminal in the future.

Sounds interesting. I thought about porting the library back to C somewhere
in the future, to replace the vt emulation core in the BSD kernel. Having a really
full featured terminal with VT100 compliance, font upload, UTF8 and history support,
with support for advanced text modes (e.g. 128x48 with 16x8 pixel fonts on a SVGA
screen) and reasonable price - the dream of every Emacs user :-)
OK, I was dreaming, still a lot of work to do...

One more thing to add concerning FreeBSD and other OS in general. It's this
utmp support. Under FreeBSD is has a different (simpler) structure, so there
we need a compilation switch anyway. Do you agree to keep the utmp support
optional? Without, gterm doesn't need any increasedl rights, at least under
FreeBSD 5 and Linux with Unix 98.

Regards, Joerg

[Gterm-discuss] PTY reading

[Timothy M. <th...@ya...>]

Joerg had asked me what it meant if a read from a pty returned zero.  I
haven't found anything that specifically addresses that issue, but the
examples I have all terminate when any number less than 1 is returned,
which suggests that zero is invalid.

I also looked at the source to xterm in the X11R6.4 tree, and it
assumes that the child has terminated when read returns a value less
than 1, so it also is taking zero to be invalid.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Gterm-discuss] Things for me to do

[Timothy M. <th...@ya...>]

I've just actually subscribed to the list.  I'd been reading on the web
before, but there are things I should respond to.

Joerg said:

 > 2. port to FreeBSD
 
 The same. Theosib, can you chance the project overview next week? ;-)


Let me know whatever changes you would like to be made to the
documentation, and I will make them.  Also feel free to make your own
mods to it; if you want me to check things, just check in to CVS what
you write, and I can edit it for structure, etc.

As for the overview, are you referring to the short description on the
summary page or the one at gterm.sourceforge.net?  Tell me what you
want, and I will do it.

Additionally, both of you guys are project administrators, and although
I think we should all agree on changes before they are made, you are
able to make them, so you don't always have to ask me.  But on the
other hand, I am willing to do my share of the work on the project.

My attitude towards GTerm is this:  Although I wrote it initially, you
guys are now making the contributions, and you can have whatever
influence you want.  I would like to have the original credit, but by
nature of being under a GNU license, it is Free Software.  I claim some
ownership, because I have an emotional attachment to it, but I wish to
claim far less control by comparison, and I am willing to share in
everything.


Also, another issue is the matter of the license.  I would prefer that
the library remain under LGPL, but it was suggested that we put it
under GPL.  Well, there's the library part and there's the X terminal
example part.  We could put the latter under GPL.  You guys let me know
what you want, and we'll come to an agreement on it.


Finally, I had been working on a spin-off of GTerm which was designed
for an embedded terminal.  I had designed the FPGA code, and I'd coded
the software for a small embedded processor.  Unfortunately, I was
never able to get an FPGA and CPU combination that I felt was
cost-effective and sufficiently capable.  What I wrote is entirely in
C.  It's pretty far along in capability.  It's been a while, but as I
recall, all I had left to do was scour vt100.net to make sure I was as
compliant as possible.  I am interested in having you two look at it
(in confidence) and extract from it any ideas you want for adding to
GTerm.  I reserve the right to use the original C code for a real
terminal in the future.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Re: [Gterm-discuss] a small todo list

[Zhang Le <ej...@pe...>]

On Wednesday 11 December 2002 17:47, J=F6rg Sonnenberger wrote:
> > 7. XIM support
>
> [ Fingers scratching the head, trying to remember] OK. What is XIM
> useful for in a terminal emulator?
>
XIM protocol is crucial for input Chinese/Japanese/Korean double byte=20
characters.
Have a look at:http://www.debian.org/doc/manuals/intro-i18n/
If you want to know more.
--=20
                                       Sincerely yours,
                                                  Zhang Le

Re: [Gterm-discuss] a small todo list

[Jörg S. <joe...@we...>]

On Wed, 11 Dec 2002 16:09:59 +0800
Zhang Le <ej...@pe...> wrote:

> Hi all,
>   I write a small todo list here and hope you may have interest. It's a long 
> way to go anyway.
[snip]
> 2. port to FreeBSD

It runs without UTMP. Have to figure out a few things for utmp support.

Regards, Joerg Sonnenberger

Re: [Gterm-discuss] a small todo list

[Jörg S. <joe...@we...>]

On Wed, 11 Dec 2002 16:09:59 +0800
Zhang Le <ej...@pe...> wrote:

> Hi all,
>   I write a small todo list here and hope you may have interest. It's a long 
> way to go anyway.

Think so too. I hope to have a replacement for the FreeBSD kernel vt someday :-)

> 
> A.GTerm core
> 1. implement xterm extension such as setting application title , font change, 
> color change

Add the "screen save"/ "screen read" extension. This is useful at least for mc.

> 2. history review support
> 3. cut/paste selection interface
> 4. UTF-8/unicode wide char support

This is interesting. This is useful.

> 
> B.GTerm application
> 1. split tty code into a separate component for easy maintain and porting

I will do it this week.

> 2. port to FreeBSD

The same. Theosib, can you chance the project overview next week? ;-)

> 3. add a scroll bar to history review
> 4. add a config file for easy user configure

I suggest a Makefile.config for things like CFLAGS, included by the main Makefile. Also Makefile.depend
for finer dependencies. The compile time configuration goes into config.h(pp)
to simplify later to autoconf.

> 5. background image(may not be so useful)
> 6. integrate with autoconf/automake build system

This is a big thing. Let's start simple, at the moment this is not needed.

> 7. XIM support

[ Fingers scratching the head, trying to remember] OK. What is XIM
useful for in a terminal emulator?

> 
> I have already written some history review mode code in zhcon 
> project(sf.net/projects/zhcon). It will not be too difficult to port it to 
> gterm. But I can not find time to do it until March next year. So if you can 
> wait, I can do it then.
> 
> BTW I find the CVS code does not have a consistent indent. Some use space, 
> some use tab char. It's common practice to use only white space to indent 
> code. So I suggest to use 4 white space to indent source code.
> If you too use vim, add 
> /*
>  * vi:ts=4:shiftwidth=4:expandtab
>  * vim600:fdm=marker
>  */
> to source code is enough.

We could also agree about same consistent astyle/indent command line.

> -- 
>                                        Sincerely yours,
>                                                   Zhang Le

Regards, Joerg Sonnenberger

[Gterm-discuss] a small todo list

[Zhang Le <ej...@pe...>]

Hi all,
  I write a small todo list here and hope you may have interest. It's a l=
ong=20
way to go anyway.

A.GTerm core
1. implement xterm extension such as setting application title , font cha=
nge,=20
color change
2. history review support
3. cut/paste selection interface
4. UTF-8/unicode wide char support

B.GTerm application
1. split tty code into a separate component for easy maintain and porting
2. port to FreeBSD
3. add a scroll bar to history review
4. add a config file for easy user configure
5. background image(may not be so useful)
6. integrate with autoconf/automake build system
7. XIM support

I have already written some history review mode code in zhcon=20
project(sf.net/projects/zhcon). It will not be too difficult to port it t=
o=20
gterm. But I can not find time to do it until March next year. So if you =
can=20
wait, I can do it then.

BTW I find the CVS code does not have a consistent indent. Some use space=
,=20
some use tab char. It's common practice to use only white space to indent=
=20
code. So I suggest to use 4 white space to indent source code.
If you too use vim, add=20
/*
 * vi:ts=3D4:shiftwidth=3D4:expandtab
 * vim600:fdm=3Dmarker
 */
to source code is enough.
--=20
                                       Sincerely yours,
                                                  Zhang Le

[Gterm-discuss] Re: Gterm VT 100

[Jörg S. <joe...@we...>]

On Fri, 6 Dec 2002 20:39:20 +0800
Zhang Le <ej...@pe...> wrote:

> On Thursday 05 December 2002 22:01, Jörg Sonnenberger wrote:
> > Hi Zhang (Le?),
> Nice to see you here.
> Zhang is my surname and Le is my first name which means "joy" in Chinese.

Right, I wasn't sure. Le = joy was new for me. I am a bit wiser now ;-)

> > nice patch. I tried to merge it with my own changes for clean compilation,
> > the resulting diff against CVS is attached. Hope I haven't forgotten
> > anything. If not, could you attach to sourceforge?
> I carefully modified the original gterm VT parser according to the programming 
> section of VT100 user guide(got from vt100.net).
> My changes include:
> 1.fix inversed BW mode problem
> 2.add charset support
> 3.modify some cursor/scroll function so their  behaver like what the VT100 UG 
> said
> 4.use dynamic buffer instead a fixed one
> 5.other enhancements and bug fixes.
> I use vttest (found on freshmeat.net) to test my modified version so I believe 
> there should be no serious bug in VT100 parser(I hope so;-)). The linux kernel 
> itself does not pass the vttest problem.
> Still, the double width char function(char width switch) , smooth scroll 
> function and other VT100 specific commands are not implemented since I 
> thought they are useless in a soft VT100 enumerator.

I agree.

> >
> >
> > Other changes are moving ASSERT_X and ASSERT_Y from gterm.hpp
> > to use .cpp files to keep the namespace clean and adding #ifndef NDEBUG
> > around the no_operator? defines and calls. Hope this is right. Are they
> > used any more?
> no_operator should be deleted, they are non-standard ESC sequence I found in 
> linux kernel's console.c which implements some vga setting function.
> Since gterm is a vt100 colone, they can be removed.

Done.

> >
> >
> > Also can you reproduce one bug in your code? If I am using plain sh and I
> > start ls or ls -w 80, it displays a really weired screen. After the first
> > file is a line break, after the second there is a lot of whitespace and the
> > first char of the third file is on the same line. This doesn't happen under
> > bash or the original gterm. This isn't introduced by the merge, it works
> > with your version too. If you can't reproduce it, I will try to debug it
> > myself.
> I've tracked down the bug. It seems ash(plain sh) does not initiate tab stops 
> on start so we should reset tab stops in GTerm::reset()

I guessed it's that kind of problem.

> here's my patch against CVS code:
> --- actions.cpp.old     Fri Dec  6 20:19:14 2002
> +++ actions.cpp Fri Dec  6 20:19:17 2002
> @@ -222,6 +222,9 @@
>         }
>         for (i=0; i<height; i++) linenumbers[i] = i;
>         memset(tab_stops, 0, width);
> +    for (i=0; i<width;++i)
> +        if ((i + 1) % 8 ==0)
> +            tab_stops[i] = 1;
>         current_state = GTerm::normal_state;
>  
>         clear_mode_flag(NOEOLWRAP | CURSORAPPMODE | CURSORRELATIVE |
> 

Applied. I changed to for-loop and dropped the if. Thanks, now it works.

> 
> -- 
>                                        Sincerely yours,
>                                                   Zhang Le

Sincerely yours,
Joerg Sonnenberger

[Gterm-discuss] Re: Gterm VT 100

[Zhang Le <ej...@pe...>]

On Thursday 05 December 2002 22:01, J=F6rg Sonnenberger wrote:
> Hi Zhang (Le?),
Nice to see you here.
Zhang is my surname and Le is my first name which means "joy" in Chinese.
> nice patch. I tried to merge it with my own changes for clean compilati=
on,
> the resulting diff against CVS is attached. Hope I haven't forgotten
> anything. If not, could you attach to sourceforge?
I carefully modified the original gterm VT parser according to the progra=
mming=20
section of VT100 user guide(got from vt100.net).
My changes include:
1.fix inversed BW mode problem
2.add charset support
3.modify some cursor/scroll function so their  behaver like what the VT10=
0 UG=20
said
4.use dynamic buffer instead a fixed one
5.other enhancements and bug fixes.
I use vttest (found on freshmeat.net) to test my modified version so I be=
lieve=20
there should be no serious bug in VT100 parser(I hope so;-)). The linux k=
ernel=20
itself does not pass the vttest problem.
Still, the double width char function(char width switch) , smooth scroll=20
function and other VT100 specific commands are not implemented since I=20
thought they are useless in a soft VT100 enumerator.
>
>
> Other changes are moving ASSERT_X and ASSERT_Y from gterm.hpp
> to use .cpp files to keep the namespace clean and adding #ifndef NDEBUG
> around the no_operator? defines and calls. Hope this is right. Are they
> used any more?
no_operator should be deleted, they are non-standard ESC sequence I found=
 in=20
linux kernel's console.c which implements some vga setting function.
Since gterm is a vt100 colone, they can be removed.
>
>
> Also can you reproduce one bug in your code? If I am using plain sh and=
 I
> start ls or ls -w 80, it displays a really weired screen. After the fir=
st
> file is a line break, after the second there is a lot of whitespace and=
 the
> first char of the third file is on the same line. This doesn't happen u=
nder
> bash or the original gterm. This isn't introduced by the merge, it work=
s
> with your version too. If you can't reproduce it, I will try to debug i=
t
> myself.
I've tracked down the bug. It seems ash(plain sh) does not initiate tab s=
tops=20
on start so we should reset tab stops in GTerm::reset()
here's my patch against CVS code:
--- actions.cpp.old     Fri Dec  6 20:19:14 2002
+++ actions.cpp Fri Dec  6 20:19:17 2002
@@ -222,6 +222,9 @@
        }
        for (i=3D0; i<height; i++) linenumbers[i] =3D i;
        memset(tab_stops, 0, width);
+    for (i=3D0; i<width;++i)
+        if ((i + 1) % 8 =3D=3D0)
+            tab_stops[i] =3D 1;
        current_state =3D GTerm::normal_state;
=20
        clear_mode_flag(NOEOLWRAP | CURSORAPPMODE | CURSORRELATIVE |


--=20
                                       Sincerely yours,
                                                  Zhang Le