Created by Colin Watson and last modified
Get this branch:
bzr branch lp:~vcs-imports/putty/master

Branch merges

Related bugs

Related blueprints

Branch information

VCS imports

Import details

Import Status: Reviewed

This branch is an import of the HEAD branch of the Git repository at git://git.tartarus.org/simon/putty.git.

The next import is scheduled to run .

Last successful import was .

Import started on juju-1e3bde-prod-lp-code-import-16 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-14 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-13 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-12 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-17 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-17 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-16 and finished taking 15 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 10 seconds — see the log
Import started on juju-1e3bde-prod-lp-code-import-15 and finished taking 10 seconds — see the log

Recent revisions

6207. By Simon Tatham

win_set_[icon_]title: send a codepage along with the string.

While fixing the previous commit I noticed that window titles don't
actually _work_ properly if you change the terminal character set,
because the text accumulated in the OSC string buffer is sent to the
TermWin as raw bytes, with no indication of what character set it
should interpret them as. You might get lucky if you happened to
choose the right charset (in particular, UTF-8 is a common default),
but if you change the charset half way through a run, then there's
certainly no way the frontend will know to interpret two window titles
sent before and after the change in two different charsets.

So, now win_set_title() and win_set_icon_title() both include a
codepage parameter along with the byte string, and it's up to them to
translate the provided window title from that encoding to whatever the
local window system expects to receive.

On Windows, that's wide-string Unicode, so we can just use the
existing dup_mb_to_wc utility function. But in GTK, it's UTF-8, so I
had to write an extra utility function to encode a wide string as

6206. By Simon Tatham

Charset-aware handling of C1 ST in OSC sequences.

When the terminal is in UTF-8 mode, we accumulate UTF-8 text normally
in the OSC string buffer - but the byte 0x9C is interpreted as the C1
control character String Terminator, which terminates the OSC
sequence. That's not really what you want in UTF-8 mode, because 0x9C
is also a perfectly normal UTF-8 continuation character. For example,
you'd expect this to set the window title to "FÜNF":

  echo -ne '\033]0;FÜNF\007'

but in fact, by the sheer chance that Ü is encoded with an 0x9C byte,
you get a window title consisting of "F" followed by an illegal-
encoding marker, and the OSC sequence is terminated abruptly so that
the trailing 'NF' is printed normally to the terminal and then the BEL
generates a beep.

Now, in UTF-8 mode, we only support the C1 control for ST if it
appears in the form of the proper UTF-8 encoding of U+009C. So that
example now 'works', at least in the sense that the terminal considers
the OSC sequence to terminate where the sender expected it to

Another case where we interpret 0x9C inappropriately as ST is if the
terminal is in a single-byte character set in which that character is
a printing one. In CP437, for example, you can't set a window title
containing a pound sign, because its encoding is 0x9C.

This commit by itself doesn't make those window titles _work_, in the
sense of coming out looking right. They just mean that the OSC
sequence is not terminated at the wrong place. The actual title
rendering will be fixed in the next commit.

6205. By Simon Tatham

Remove some unused variables.

clang warned about these in the recent bidi work.

6204. By Simon Tatham

bidi.c: correct comments.

I accidentally deleted the original author's name in my rewrite, which
was unnecessarily unfriendly given that some of their code is still
here. Also I made a thinko in my explanation of the U+00AD problem.

6203. By Simon Tatham

Test rig for the new bidi algorithm.

This standalone CLI program runs the UCD bidi tests in the form
provided in Unicode 14.0.0. You can run it by just saying

  bidi_test --class BidiTest.txt --char BidiCharacterTest.txt

assuming those two UCD files are in the current directory.

6202. By Simon Tatham

Complete rewrite of the bidi algorithm.

A user reported that PuTTY's existing bidi algorithm will generate
misordered text in cases like this (assuming UTF-8):

  echo -e '12 A \xD7\x90\xD7\x91 B'

The hex codes in the middle are the Hebrew letters aleph and beth.
Appearing in the middle of a line whose primary direction is
left-to-right, those two letters should appear in the opposite order,
but not cause the rest of the line to move around. That is, you expect
the displayed text in this situation to be

  12 A <beth><aleph> B

But in fact, the digits '12' were erroneously reversed, so you would
actually see '21 A <beth><aleph> B'.

I tried to debug the existing bidi algorithm, but it was very hard,
because the Unicode bidi spec has been extensively changed since
Arabeyes contributed that code, and I couldn't even reliably work out
which version of the spec the code was intended to implement. I found
some problems, notably that the resolution phase was running once on
the whole line instead of separately on runs of characters at the same
level, and also that the 'sor' and 'eor' values were being wrongly
computed. But I had no way to test any fix to ensure it hadn't
introduced another bug somewhere else.

Unicode provides a set of conformance tests in the UCD. That was just
what I wanted - but they're too up-to-date to run against the old
algorithm and expect to pass!

So, paradoxically, it seemed to me that the _easiest_ way to fix this
bidi bug would be to bring absolutely everything up to date. But the
revised bidi algorithm is significantly more complicated, so I also
didn't think it would be sensible to try to gradually evolve the
existing code into it. Instead, I've done a complete rewrite of my

The new code implements the full UAX#9 rev 44 algorithm, including in
particular support for the new 'directional isolate' control
characters, and also special handling for matched pairs of brackets in
the text (see rule N0 in the spec). I've managed to get it to pass the
entire UCD conformance test suite, so I'm reasonably confident it's
right, or at the very least a lot closer to right than the old
algorithm was.

So the upshot is: the test case shown at the top of this file now
passes, but also, other detailed bidi handling might have changed,
certainly some cases involving brackets, but perhaps also other things
that were either bugs in the old algorithm or updates to the standard.

6201. By Simon Tatham

bidi.c: update the API.

The input length field is now a size_t rather than an int, on general
principles. The return value is now void (we weren't using the
previous return value at all). And we now require the client to have
previously allocated a BidiContext, which will allow allocated storage
to be reused between runs, saving a lot of churn on malloc.

(However, the current BidiContext doesn't contain anything
interesting. I could have moved the existing mallocs into it, but
there's no point, since I'm about to rewrite the whole thing anyway.)

6200. By Simon Tatham

wcwidth.c: update to Unicode 14.0.0.

I wasn't able to find the 'uniset' program mentioned in the comment
that generated one of the tables, or at least I wasn't confident that
I'd found the right thing of that name. So I rewrote the semantics of
that command line in my own Perl and have included that in the revised
version of the comment.

6199. By Simon Tatham

wcwidth.c: reflow existing lookup table.

With one entry per line, it now takes up more vertical space, but it
will be easier to see changes when I update it for a later Unicode

6198. By Simon Tatham

Make bidi type enums into list macros.

This makes it easier to create the matching array of type names in
bidi_gettype.c, and eliminates the need for an assertion to check the
array matched the enum. And I'm about to need to add more types, so
let's start by making that trivially easy.

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.