Fill in the whole box drawing section (U+2500 - U+257F).


git-svn-id: svn://svn.tartarus.org/sgt@9298 cda61777-01e9-0310-a592-d414129be87e
Fill in the block elements section (U+2580 - U+259F).


git-svn-id: svn://svn.tartarus.org/sgt@9299 cda61777-01e9-0310-a592-d414129be87e
Filled in some more characters, including in particular the
superscript/subscript block (U+2070 - U+209F) and enough isolated
characters to catch the whole of CP437.


git-svn-id: svn://svn.tartarus.org/sgt@9300 cda61777-01e9-0310-a592-d414129be87e
Invent a method of signalling EOF to translation modules, so they can
append a last parting comment to the translated data.


git-svn-id: svn://svn.tartarus.org/sgt@9301 cda61777-01e9-0310-a592-d414129be87e
Use the new EV_EOF mechanism to implement an '-e' option to csfilter,
which makes it output escape sequences at the start and end of the
output to configure the terminal into an appropriate mode. Currently
the only outer charset supported by this feature is UTF-8, for which
it sends ESC % G and ESC % @ to start and stop UTF-8 mode in a
terminal defaulting to something else. So now I can temporarily put
one of my ordinary pterms (which default to ISO 8859-1) into some
other charset simply by saying 'csfilter -e whatever'.


git-svn-id: svn://svn.tartarus.org/sgt@9302 cda61777-01e9-0310-a592-d414129be87e
Cope with XFontStructs having a NULL per_char array, which happened to
me this morning under strange circumstances.


git-svn-id: svn://svn.tartarus.org/sgt@9303 cda61777-01e9-0310-a592-d414129be87e
Patch from Chris Boyle to fix Signpost's labelling when you have more
than 26 separate linked chains of unnumbered squares: we now wrap from
'z' to an Excel-like 'aa', 'ab', ..., instead of falling off z into
punctuation and control characters.


git-svn-id: svn://svn.tartarus.org/sgt@9304 cda61777-01e9-0310-a592-d414129be87e
When we run out of background colours for chains and wrap back to the
beginning, we should wrap back to COL_B0+1 rather than COL_B0 itself,
so as not to reuse white. White should be special, and always indicate
a properly numbered square.


git-svn-id: svn://svn.tartarus.org/sgt@9305 cda61777-01e9-0310-a592-d414129be87e
Remove the 'cheated' flag in Range's game_ui, which was stickily
remembering whether the player had ever used the hint or solve
functions, even if they then pressed undo (and even if they saved and
restored).

As far as Solve+Undo is concerned, this just brings Range into line
with common practice in the rest of my puzzles. On the other hand,
Range is the first time there's been a 'hint' function to consider in
this question, so here's a policy decision: the victory flash is not a
congratulation for a puzzle solved unaided, it's a confirmation that
you really have reached a correct solution and haven't made any
mistakes. So the only reason to omit the victory flash is if you've
used the Solve operation to go straight to a guaranteed-correct
solution _in a single move_; if you're using the hint button, there's
still scope for you to make mistakes in all your non-hint moves, so
the victory flash is still a useful indicator that you didn't.


git-svn-id: svn://svn.tartarus.org/sgt@9306 cda61777-01e9-0310-a592-d414129be87e
Uncommitted code from ages ago: add doubleflat to the simple font
output, and don't use control-character codes in that font for fear of
confusing things.


git-svn-id: svn://svn.tartarus.org/sgt@9307 cda61777-01e9-0310-a592-d414129be87e
Add a missing initialisation to NULL.


git-svn-id: svn://svn.tartarus.org/sgt@9308 cda61777-01e9-0310-a592-d414129be87e
We shouldn't fork off a utmp helper subprocess when we aren't setuid,
because (a) under that circumstance we won't be writing to utmp
anyway, and (b) if we aren't setuid, then we won't have created the
pty at the point we fork, so even if our subprocess _could_ have
written to utmp it wouldn't have done it right!

Spotted by valgrind (triggering on the access beyond the end of the
ttyname string in setup_utmp, clueing me in to it having been empty).


git-svn-id: svn://svn.tartarus.org/sgt@9309 cda61777-01e9-0310-a592-d414129be87e
Updates to my installation strategy of replacing LILYPOND_DATADIR, to
make it work with Lilypond 2.14+. I haven't had to mess about with the
actual font, but the structure of the files being dropped in needed to
change in several ways:
 - lilypond now accesses 'aybabtu' under the name 'emmentaler-brace'
 - lilypond expects its alphabetic fonts to contain font names the
   same as their filenames, so I can no longer make emmentaler-20.otf
   a symlink to gonville-20.otf
 - lilypond keeps non-music fonts in its fonts directory, so I have to
   arrange not to blow those away in lilysetup
 - while I'm here, I've renamed the 'feta-alphabet' subfont name to
   'gonvillealpha', on general grounds of tidiness.


git-svn-id: svn://svn.tartarus.org/sgt@9310 cda61777-01e9-0310-a592-d414129be87e
Support Python 2.6, which deprecated os.popen2 in favour of the
'subprocess' module.


git-svn-id: svn://svn.tartarus.org/sgt@9311 cda61777-01e9-0310-a592-d414129be87e
Output feta-alphabet%d.pfb as well as .pfa, since it turns out that
Lilypond 2.12 will use the pfb if it's present, ignoring the pfa, and
therefore will drop back to getting its time signature digits from
Feta. (Side effect of lilysetup no longer clearing out as thoroughly
as of r9310.)


git-svn-id: svn://svn.tartarus.org/sgt@9312 cda61777-01e9-0310-a592-d414129be87e
Add dynamics to the demo file, on the grounds that they seem to be one
of the first things that accidentally fall back to Feta if Lilypond is
misconfigured.


git-svn-id: svn://svn.tartarus.org/sgt@9313 cda61777-01e9-0310-a592-d414129be87e
Change the semantics of 'FontSpec' so that it's a dynamically
allocated type.

The main reason for this is to stop it from taking up a fixed large
amount of space in every 'struct value' subunion in conf.c, although
that makes little difference so far because Filename is still doing
the same thing (and is therefore next on my list). However, the
removal of its arbitrary length limit is not to be sneezed at.


git-svn-id: svn://svn.tartarus.org/sgt@9314 cda61777-01e9-0310-a592-d414129be87e
Fix copy-and-paste error in command-line font selection in r9314.


git-svn-id: svn://svn.tartarus.org/sgt@9315 cda61777-01e9-0310-a592-d414129be87e
Turn 'Filename' into a dynamically allocated type with no arbitrary
length limit, just as I did to FontSpec yesterday.


git-svn-id: svn://svn.tartarus.org/sgt@9316 cda61777-01e9-0310-a592-d414129be87e
While I'm crusading against arbitrary limits, here's a redesign of
prompt_t to arrange that the buffer in which each prompt is stored can
be reallocated larger during the input process.


git-svn-id: svn://svn.tartarus.org/sgt@9317 cda61777-01e9-0310-a592-d414129be87e