The active terminal screen is no longer an array of `unsigned long'
encoding 16-bit Unicode plus 16 attribute bits. Now it's an array of
`termchar' structures, which currently have 32-bit Unicode and 32
attribute bits but which will probably expand further in future.
To prevent bloat of the memory footprint, I've introduced a mostly
RLE-like compression scheme for storing scrollback: each line is
compressed into a compact (but hard to modify) form when it moves
into the term->scrollback tree, and is temporarily decompressed when
the user wants to scroll back over it. My initial tests suggest that
this compression averages about 1/4 of the previous (32 bits per
character cell) data size in typical output, which means this is an
improvement even without counting the new ability to extend the
information stored in each character cell.
Another beneficial side effect is that the insane format in which
Unicode was passed to front ends through do_text() has now been
rendered sane.
Testing is incomplete; this _may_ still have instabilities. Windows
and Unix front ends both seem to work as far as I've looked, but I
haven't yet looked very hard. The Mac front end I've edited (it
seemed obvious how to change it) but I can't compile or test it.
As an immediate functional effect, the terminal emulator now
supports full 32-bit Unicode to whatever extent the host platform
allows it to. For example, if you output a 4-or-more-byte UTF-8
character in Unix pterm, it will not display it properly, but it
will correctly paste it back out in a UTF8_STRING selection. Windows
is more restricted, sadly.
[originally from svn r4609]
attempt to load WS2 and then fall back to WS1 if that fails. This
should allow us to use WS2-specific functionality to find out the
local system's list of IP addresses, thus fixing winnet-if2lo, while
degrading gracefully back to the previous behaviour if that
functionality is unavailable. (I haven't yet actually done this; I've
just laid the groundwork.)
This checkin _may_ cause instability; it seemed fine to me on
initial testing, but it's a bit of an upheaval and I wouldn't like
to make bets on it just yet.
[originally from svn r3502]
8859-4 to 8859-13 as suggested by Vaidrius Petrauskas, on the grounds that
he has a .lt address and sounds like he knows what he's talking about.
[originally from svn r3485]
former by simply removing it; the latter by adding an enumeration
function to libcharset.) This has had slight `const' repercussions
on cp_name() and cp_enumerate() which might break the Mac build.
[originally from svn r3064]
malloc functions, which automatically cast to the same type they're
allocating the size of. Should prevent any future errors involving
mallocing the size of the wrong structure type, and will also make
life easier if we ever need to turn the PuTTY core code from real C
into C++-friendly C. I haven't touched the Mac frontend in this
checkin because I couldn't compile or test it.
[originally from svn r3014]
holdout static I hadn't noticed; unicode.c had one too; and a large
number of statics that were perfectly OK due to being constants have
been made `const', with assorted `const' repercussions all over the
place. I now declare `remove-statics' to be fixed.
[originally from svn r2594]
just done this the very simple way - bundle all the globals into a
data structure and pass pointers around. One particularly ugly wart
is that wc_to_mb now takes a pointer to this structure as an
argument (optional, may be NULL, and unused in any Unicode layer
that's even marginally less of a mess than the Windows one). I do
need to do this properly at some point, but for now this should just
about be adequate. As usual, the Mac port has not been updated.
[originally from svn r2592]
relevant bits of it passed in to init_ucs(). (Actually I pass in all
of it in the Windows version, since it's a bit hairy in there.)
[originally from svn r2565]
code point 3/13 as HORIZONTAL BAR, which agrees with unicode.org's mapping
table. Change ours to match (it used to have EM DASH, courtesy of RDB).
This brings all our 8859-to-Unicode tables into line with unicode.org.
[originally from svn r2224]
lpage_send out into the line discipline, making them _clients_ of
the Unicode layer rather than part of it. This means they can access
ldisc->term, which in turn means I've been able to remove the
temporary global variable `term'. We're slowly getting there.
[originally from svn r2143]
all the global and function-static variables out of terminal.c into
a dynamically allocated data structure. Note that this does not yet
confer the ability to run more than one of them in the same process,
because other things (the line discipline, the back end) are still
global, and also in particular the address of the dynamically
allocated terminal-data structure is held in a global variable
`term'. But what I've got here represents a reasonable stopping
point at which to check things in. In _theory_ this should all still
work happily, on both Unix and Windows. In practice, who knows?
[originally from svn r2115]
The current pty.c backend is temporarily a loopback device for
terminal emulator testing, the display handling is only just enough
to show that terminal.c is functioning, the keyboard handling is
laughable, and most features are absent. Next step: bring output and
input up to a plausibly working state, and put a real pty on the
back to create a vaguely usable prototype. Oh, and a scrollbar would
be nice too.
In _theory_ the Windows builds should still work fine after this...
[originally from svn r2010]
beginning of a Unix port. It's nowhere near done, and currently it
won't even compile on Unix. But this represents the start of the
process of separating out platform-specific code, and also contains
the mkfiles.pl changes required to support a Unix makefile and a
non-flat source tree.
[originally from svn r1993]
you enable it text will paste into Word et al in the same font as
PuTTY itself is displaying in. In particular, this will be a fixed-
pitch font, so tables and `ls' and the like will naturally line up.
[originally from svn r1373]
so we specify them explicitly to avoid this problem. Also in
particular get_unitab() no longer depends on querying Windows
codepage 28591 (ISO8859-1), so UTF-8 mode should stop failing on
such systems.
[originally from svn r1336]
kicked out by the Unicode patch. It's not very good - only works
sanely on US keyboards - but it's no worse than it was in 0.51.
After 0.52 maybe I should fix it properly.
[originally from svn r1273]
fiddle with the widths of characters in DBCS screen fonts, and (the
big one) one to enable a mode in which resizing the window locks the
terminal size and lets the font change, instead of vice versa. That
should shut up a few feature requests!
[originally from svn r1269]
range of Unicode characters. Not entirely sure I understand this one
but I trust that RDB knows what he's talking about with Unicode.
[originally from svn r1246]
numeric code page, and also reinstate the direct-to-font zero
translation mode (but now under an actual _name_ rather than blank).
Also add CP437 to the list since at least one expatriate DOS user
wanted it; also select a sensible ISO or KOI codepage based on the
system locale.
[originally from svn r1230]
box. Also default to ISO8859-1 so that CSI works in the default
mode; this is ridiculously Western-centric but I can't honestly
think of a better option.
[originally from svn r1183]
possible and we have a single unified means of trying to display any
Unicode code point. Instead of the various ad-hoc translation modes
we had before, we now have a single `codepage' option which allows
us to treat the incoming (and outgoing) text as any given character
set, and locally we map that to Unicode and back.
[originally from svn r1110]
