nterm a vt100 emulator

nterm a vt100 emulator

[Ivan Kanis]

Hello,

This a vt100 emulator for emacs. It has a lot of rough edges. As it
stands it passes the first 3 tests of vttest. I have another project
coming up so I won't be able to work on nterm for a while.

http://kanis.fr/nterm.html

Kind regards,
-- 
Ivan
Kanis http://kanis.fr

Wisdom is oftentimes nearer when we stoop than when we soar.
    -- William Wordsworth 

Re: nterm a vt100 emulator

[Stefan Monnier]

> This a vt100 emulator for Emacs. It has a lot of rough edges. As it
> stands it passes the first 3 tests of vttest. I have another project
> coming up so I won't be able to work on nterm for a while.

Could you expand a bit on it?  Mostly, how does it compare to term.el
and terminal.el?


        Stefan


PS: also if anyone knows how term.el and terminal.el compare, that would
also be useful to know (and put it in those files's commentary).

Re: nterm a vt100 emulator

[Miles Bader]

Ivan Kanis <expire-by-2009-10-20@kanis.fr> writes:
> This a vt100 emulator for emacs. It has a lot of rough edges. As it
> stands it passes the first 3 tests of vttest. I have another project
> coming up so I won't be able to work on nterm for a while.
>
> http://kanis.fr/nterm.html

We've already got two different terminal emulators in Emacs (with
completely separate code bases); do we really want a third...?

-Miles

-- 
Friendship, n. A ship big enough to carry two in fair weather, but only one
in foul.

Re: nterm a vt100 emulator

[Ivan Kanis]

Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:

>> This a vt100 emulator for Emacs. It has a lot of rough edges. As it
>> stands it passes the first 3 tests of vttest. I have another project
>> coming up so I won't be able to work on nterm for a while.
>
> Could you expand a bit on it?  Mostly, how does it compare to term.el
> and terminal.el?

Hi Stefan,

I wrote it because I couldn't fix the cursor bug in term. term and
terminal are not meant to be full emulation. term has a pager and
line mode which nterm doesn't do. nterm doesn't track current directory
like term does. I can't comment on terminal, I haven't used it.

Nterm is meant to be a full vt100 compatible terminal emulator. It has
the following features:

- G0 G1 switching with SI and SO
- special graphics characters (used for line drawing)
- US and UK character set.
- blinking, bright, underline and reverse rendition
- scroll up and down including within top and bottom margin
- switch terminal background color
- switch between 80 and 132 columns screen
- tabulation set and reset
- all VT100 escape sequences are handled

Things that remains to do:
- Double width character
- Double height character
- Sanitize keyboard map
- ANSI color
- VT52 compatibility mode

I think nterm is easier to maintain than term. One look at term's
term-emulate-terminal function should convince anyone that term cannot be
maintained anymore. Compare with nterm equivalent function nterm-emulate
it is only 25 lines long.

It has a recording mode (C-c r) so that you can record and replay
traces. It has a terminal memory so that area of the terminal can be
redrawn for blinking and changing screen background. There is a memory
dump mode (C-c m) that allows the programmer to examine the memory.
-- 
Ivan
Kanis http://kanis.fr

The cause of these complaints lies in WinZip, which turns an all
upper-case directory into an all lower case one in a fit of
helpfulness
    -- Ant Documentation 

Re: nterm a vt100 emulator

[Dan Nicolaescu]

Miles Bader <miles@gnu.org> writes:

  > Ivan Kanis <expire-by-2009-10-20@kanis.fr> writes:
  > > This a vt100 emulator for emacs. It has a lot of rough edges. As it
  > > stands it passes the first 3 tests of vttest. I have another project
  > > coming up so I won't be able to work on nterm for a while.
  > >
  > > http://kanis.fr/nterm.html
  > 
  > We've already got two different terminal emulators in Emacs (with
  > completely separate code bases); do we really want a third...?

IMO a third one could be considered as a replacement for term.el (never
seen terminal.el).   But only if it's actively maintained.

term.el is not very maintainable, some bugs are quite hard to fix.

Also nterm.el seems to be trying to emulate vt100.  Nowadays all
terminal emulators try to emulate xterm, which is the de facto standard...

Re: nterm a vt100 emulator

[Stefan Monnier]

>> Could you expand a bit on it?  Mostly, how does it compare to term.el
>> and terminal.el?

> Hi Stefan,

> I wrote it because I couldn't fix the cursor bug in term.

That was my guess as well ;-)

> term and terminal are not meant to be full emulation.  term has
> a pager and line mode which nterm doesn't do.  nterm doesn't track
> current directory like term does.

That makes it sound like nterm is like term but with less features.
I'm sure there's an upside to it.  Also, if you could explain how these
different design decisions affect the ability to fix the original cursor
bug, that would be great.

> I can't comment on terminal, I haven't used it.

Neither have I.  Has someone used it?  Should we move it to `lisp/obsolete'?

> Things that remains to do:
> - Double width character
> - Double height character
> - Sanitize keyboard map
> - ANSI color
> - VT52 compatibility mode

Does it adapt to a window's size or does it have a fixed size
independent from the window where the buffer is displayed?

> I think nterm is easier to maintain than term.  One look at term's
> term-emulate-terminal function should convince anyone that term cannot
> be maintained anymore.  Compare with nterm equivalent function
> nterm-emulate it is only 25 lines long.

term.el's maintainability is indeed a problem.


        Stefan

Re: nterm a vt100 emulator

[Miles Bader]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I can't comment on terminal, I haven't used it.
>
> Neither have I.  Has someone used it?  Should we move it to `lisp/obsolete'?

I vaguely recall that the last time I complained about the duplication
on this list, there was some objection to doing so, but I don't recall
the reason.  Per's README certainly makes it sound like term.el is
(functionally) a superset...

The different emulators have different methods of allowing emacs escape
sequences to be entered while still trying to send raw keys to the
process; maybe that was it?

-Miles

-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: nterm a vt100 emulator

[Ivan Kanis]

Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> term and terminal are not meant to be full emulation.  term has
>> a pager and line mode which nterm doesn't do.  nterm doesn't track
>> current directory like term does.
>
> That makes it sound like nterm is like term but with less features.
> I'm sure there's an upside to it.  Also, if you could explain how these
> different design decisions affect the ability to fix the original cursor
> bug, that would be great.

The recorder takes a trace of characters received by the
terminal. Someone can easily reproduce a bug by replaying the trace
both on xterm and nterm. I don't think term has that feature.

For now it's only a vt100 emulator, I think it can become a xterm
emulator with a little bit of work.

> Does it adapt to a window's size or does it have a fixed size
> independent from the window where the buffer is displayed?

It has a fixed size for now.
-- 
Ivan
Kanis http://kanis.fr

Wisdom is oftentimes nearer when we stoop than when we soar.
    -- William Wordsworth 

Re: nterm a vt100 emulator

[Dan Nicolaescu]

Ivan Kanis <expire-by-2009-10-25@kanis.fr> writes:

  > Stefan Monnier <monnier@iro.umontreal.ca> wrote:
  > 
  > >> term and terminal are not meant to be full emulation.  term has
  > >> a pager and line mode which nterm doesn't do.  nterm doesn't track
  > >> current directory like term does.
  > >
  > > That makes it sound like nterm is like term but with less features.
  > > I'm sure there's an upside to it.  Also, if you could explain how these
  > > different design decisions affect the ability to fix the original cursor
  > > bug, that would be great.
  > 
  > The recorder takes a trace of characters received by the
  > terminal. Someone can easily reproduce a bug by replaying the trace
  > both on xterm and nterm. I don't think term has that feature.

See term-start-output-log

Re: nterm a vt100 emulator

[Ivan Kanis]

Dan Nicolaescu <dann@ics.uci.edu> wrote:

>   > The recorder takes a trace of characters received by the
>   > terminal. Someone can easily reproduce a bug by replaying the trace
>   > both on xterm and nterm. I don't think term has that feature.
>
> See term-start-output-log

I stand corrected. However I didn't see a way to replay the trace...

Take care
-- 
Ivan
Kanis http://kanis.fr

A lie gets halfway around the world before the truth has a chance to
get its pants on.
    -- Winston Churchill 

Re: nterm a vt100 emulator

[Dan Nicolaescu]

Ivan Kanis <expire-by-2009-10-26@kanis.fr> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> wrote:
  > 
  > >   > The recorder takes a trace of characters received by the
  > >   > terminal. Someone can easily reproduce a bug by replaying the trace
  > >   > both on xterm and nterm. I don't think term has that feature.
  > >
  > > See term-start-output-log
  > 
  > I stand corrected. However I didn't see a way to replay the trace...

cat TRACE

but it's far from ideal.