Readme for github and other bits

A .gitignore file
A working GUNmakefile with proper cleanup (Does Linux & Windows cross)
The old patch files
A TODO file with some minor idea notes
UTF-8 processing update

*) Removed the locking of terminal in UTF-8 mode.
    DOCS standard return always works IF no_remote_charset is off.
*) The alt_utf flag is removed
*) The saved_utf flag is removed.

*) All ISO-2022 controls (except ESC % @) are properly ignored in utf-8 mode.

*) Added rxvt compatible UTF-8 mode for ISO-2022 and UTF-8 at the same time.

*) CSI Pn SP D used to allow host switching to rxvt mixed mode.

*) Under Debian/Ubuntu my locale is en_GB.utf8, not *UTF-8*.
*) Some UTF-8 locales don't have a utf8 suffix eg: en_AG, en_IN, en_NG

Add a config switch to control the new UTF-8 modes on reset.

Option sets the value of the term->utf field on reset.

The configuration values are
    0 => off
	Terminal uses the configured codepage after a reset.
    1 => on
	Terminal uses UTF-8 after a reset, DOCS RETURN is used to get to
	the configured codepage.
    2 => mixed
	Terminal uses UTF-8 after a reset. But if the character sequence
	isn't legal UTF-8 it will be treated as the configured codepage.

Rather than overriding the line character set, the UTF8 locale override
forces this flag to UTF-8. This means that the 8bit codepage is still
available if the host explicitly requests it (ISO8859-1 if the line
codepage is UTF-8)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Reasoning for UTF-8 change ...

No version of curses understands ISO-2022 (possibly outside Japan)
but some do understand UTF-8. The Japaneese version of ISO-2022 is
more complex.

The utf flag is not controlled by most host software, only specialist
software (and scripts) that understand ISO-2022 and UTF-8 will use
it. Therefor the existance of multi copies of the flag (alt & saved)
is not useful and has caused confusion.

This is because the UTF-8 functionality of most host software is
controlled through the 'locale' functions. These have no built in
facilities for sending initilisation sequences to a terminal to change
it's mode. However, a host script can change the locale and so should
be able to change the terminal to match.

    if [ "`locale charmap 2>/dev/null`" = "UTF-8" ]
    then echo -ne '\033%G'		# DOCS UTF-8
    else echo -ne '\033%@'		# DOCS RETURN
    fi

Most utf-8 software expects normal sequences to have no effect on a
UTF-8 terminal, ncurses for example may still send smacs strings even
when using UTF-8 line drawing characters.

For the future it's likely that the terminal will run mostly in UTF-8
so this mode will become even less useful.

=-=
The automatic locking of the utf flag for UTF-8 fonts is confusing in
that it means there are two distinct versions of PuTTY control sequences
(with or without ISO-2022) without an obvious configuration warning. In
addition for current versions of PuTTY the functionality is provided by
the option to disable remote control of character sets.

=-=
When the 'DOCS return' sequence is used the ISO-2022 engine must be
returned to exactly the state it was in when the original 'DOCS' was
received. (ECMA-035)

=-=
The rxvt compatibility (wishlist/utf8-plus-vt100) means that all the
ISO-2022 sequences can be made to continue to work while in UTF-8
mode. This is only reasonable when you have a hellspawn host that has
an unlabeled mixture of unicode and non-unicode applications and data
but it can still be useful.  (eg: if parts of your filesystem have been
around for nearly 20 years like mine) Even then there are reasonable
arguments that this should be done by translation applications not an
emulator.

This mixed mode also means that the UTF-8 decoder had to be changed;
instead of mostly using an FSM with a single character lookahead buffer
the UTF-8 decoder has been changed to use only a lookahead buffer.
This buffer is also used instead of the tiny FSM for the printer output
and is likely to be a good solution for full ISO-2022.

The unmixed mode is still the default. Note: As the escape sequence to
get into the mixed mode is NOT an ISO-2022 sequence the rules about DOCS
restoring the ISO-2022 state do not apply.
This patch adds ANSI.SYS, SCO Xenix 2.3.2 and a general ANSI emulation.

The SCO Xenix is a well defined but rather old style emulation similar
in many respects to the ANSI.SYS emulation but a bit nicer. The later
SCO Unix variants are far more uncertain as they cover may versions of
SCO Unix where the emulation was changed to maintain or provide minimal
compatibility with other systems.

In the SCO Xenix emulation I have assumed the mapchan(1) facility has
been used to set the default character set to the putty line codepage. So
if your application assumes the mapchan process hasn't been run you will
need to set the line charset to CP437. The ANSI.SYS emulation forces CP437.

echo -e '\e[4040"p'   # Set normal PuTTY (xterm) mode.
echo -e '\e[4041"p'   # Set modern Ansi mode, all available non VT sequences.
echo -e '\e[4042"p'   # Set ANSI.SYS emulation
echo -e '\e[4043"p'   # Set SCO Xenix

echo -e '\e[4030"p'   # Set pure VT52 mode
echo -e '\e[4031"p'   # Set pure VT220+ mode

These and all the compatibility stuff can be turned off using the compile
option DISABLE_COMPAT. Note, CSI 4030"p turns off _nearly_ all the CSI
sequences, the exception being ones that begin "ESC [ 404".
The SCO emulation overrides the configured function key definitions.

The SCO Xenix emulation does not have the reverse or graphic attribute
variables. However, I do have full details if these are needed.

Linux CSI 8 ] for default colours. CSI 8 ; 1 ] to reset.
Added CSI 8 ; 2 ] to reconfigure the default colours and the BLINK
attribute to blink any other attribute.

In ANSI.SYS mode CSI-J homes cursor.

Some cleanups to the emulation switching.
Adding better support for Windows MBCS (codepages)

Adding better support for some 国家标准 character sets. (ie Chinese standard
character sets), Japanese, Korean and Thai.  Including the Shift-JIS variants.

The characters are displayed at the expected widths.

This does NOT need a specific font as long as the unicode system can find the
requsite characters.

Note the change in the defaults; it is now recommended to explicitly
specify the line character set for DBCS systems.

Also added these Windows charsets to the list.

Unlike DBCS fonts this can be made to work for the Unix port as it only
requires Codepage to Unicode character and width tables.
Reconfigure PuTTY colour scheme from Unix host.

This is possibly related to: /wishlist/colour-scheme.html

These colour schemes are not stored in the PuTTY session file but are
instead "dynamically" configured from the host.

This script can send the required control sequences suitable for any
modern version of PuTTY or the Linux console.

It can calculate several standard forms and contains a default PuTTY
and XTerm mappings. In addition it can the colour scheme from a Windows
PuTTY registry dump, a Unix session file or something similar.
DEBUG messages for tracing
Waaay overkill on uuid generation

The method used to generated the stable GUID values for Windows is basically
a variant of the type 3 and type 5 UUID generation methods.

For these you only need one properly generated UUID to make a namespace.

I have left it advertised as a type 4 UUID because it doesn't follow the
exact procedure (or use the correct cryptographical hash) for either of
the standard ones.