Punctuation fix.


git-svn-id: svn://svn.tartarus.org/sgt@9274 cda61777-01e9-0310-a592-d414129be87e
Expand on this bug entry, since I've just been bitten by another
special case of it.


git-svn-id: svn://svn.tartarus.org/sgt@9275 cda61777-01e9-0310-a592-d414129be87e
Fix assertion failure in wprefs() when the list is zero-length. Breaks
any session-save operation in PuTTYtel due to the empty GSS list.


git-svn-id: svn://svn.tartarus.org/sgt@9276 cda61777-01e9-0310-a592-d414129be87e
Merge r9276 (the PuTTYtel session-saving assertion failure fix).


git-svn-id: svn://svn.tartarus.org/sgt@9277 cda61777-01e9-0310-a592-d414129be87e
In term_init(), copy stuff out of the conf _before_ calling
power_on(), since the latter calls term_schedule_cblink which expects
term->blink_cur to have been initialised.


git-svn-id: svn://svn.tartarus.org/sgt@9278 cda61777-01e9-0310-a592-d414129be87e
Revamp of EOF handling in all network connections, pipes and other
data channels. Should comprehensively fix 'half-closed', in principle,
though it's a big and complicated change and so there's a good chance
I've made at least one mistake somewhere.

All connections should now be rigorous about propagating end-of-file
(or end-of-data-stream, or socket shutdown, or whatever) independently
in both directions, except in frontends with no mechanism for sending
explicit EOF (e.g. interactive terminal windows) or backends which are
basically always used for interactive sessions so it's unlikely that
an application would be depending on independent EOF (telnet, rlogin).

EOF should now never accidentally be sent while there's still buffered
data to go out before it. (May help fix 'portfwd-corrupt', and also I
noticed recently that the ssh main session channel can accidentally
have MSG_EOF sent before the output bufchain is clear, leading to
embarrassment when it subsequently does send the output).


git-svn-id: svn://svn.tartarus.org/sgt@9279 cda61777-01e9-0310-a592-d414129be87e
Nearly forgot noting this down in the 'half-closed' bug entry: don't
send CHANNEL_CLOSE until we have acks for all our winadj requests.
Should work around https://bugzilla.mindrot.org/show_bug.cgi?id=1818 .


git-svn-id: svn://svn.tartarus.org/sgt@9280 cda61777-01e9-0310-a592-d414129be87e
Mark 'half-closed' as fixed (perhaps a little optimistically, but
that's always been our policy with complicated bug fixes - we can
always open it again if it turns out not to be quite fixed after all),
and add a note on the subject to portfwd-corrupt.


git-svn-id: svn://svn.tartarus.org/sgt@9281 cda61777-01e9-0310-a592-d414129be87e
Changed my mind about the EOF policy in SSH mode: I think the SSH
backend should unilaterally assume outgoing EOF when it sees incoming
EOF, if and only if the main session channel is talking to a pty.
(Because ptys don't have a strong concept of EOF in the first place,
that seems like a sensible place to draw the line.) This fixes a bug
introduced by today's revamp in which if you used Unix Plink to run a
console session it would hang after you hit ^D - because the server
had sent EOF, but it was waiting for a client-side EOF too.


git-svn-id: svn://svn.tartarus.org/sgt@9282 cda61777-01e9-0310-a592-d414129be87e
Another tweak to EOF policy: invent an outgoing EOF on receipt of an
incoming CHANNEL_CLOSE, if it's the main session channel. The idea is
that invocations such as 'plink -T hostname sh' (running a shell
without a remote pty) can be exited by typing 'exit' to the remote
shell, without plink blocking forever waiting for outgoing EOF.

I think it would be better to do the same for all other channel types
too, but that would need an extra API call which I haven't
implemented yet.


git-svn-id: svn://svn.tartarus.org/sgt@9283 cda61777-01e9-0310-a592-d414129be87e
No, I take that back: we _do_ have a mechanism for suppressing reads
from forwarding data sources which will be good enough to last until
we close the socket, in the form of the override_throttle() functions.
So this finishes up the work in r9283, by manufacturing outgoing EOF
in response to incoming CLOSE on all channel types.


git-svn-id: svn://svn.tartarus.org/sgt@9284 cda61777-01e9-0310-a592-d414129be87e
Fix spurious newline in <pre> block.


git-svn-id: svn://svn.tartarus.org/sgt@9285 cda61777-01e9-0310-a592-d414129be87e
More formatting fixes.


git-svn-id: svn://svn.tartarus.org/sgt@9286 cda61777-01e9-0310-a592-d414129be87e
Another formatting fix!


git-svn-id: svn://svn.tartarus.org/sgt@9287 cda61777-01e9-0310-a592-d414129be87e
Create empty.h (used to force rebuilds of version.o by the automake
makefile) as a side effect of running mkfiles.pl.

The automake docs observe that the BUILT_SOURCES list is only
automatically built by plain 'make' or 'make all' or a couple of other
targets, so the sequence './configure && make plink' from a freshly
unpacked tar file would previously fail for lack of empty.h.

If empty.h had important _content_ that needed to be built at compile
time, of course, I wouldn't be able to fix it like this; but since the
only important thing is the timestamp, I can just make sure it already
exists at the time of first build.


git-svn-id: svn://svn.tartarus.org/sgt@9288 cda61777-01e9-0310-a592-d414129be87e
Stop using GDK's wrapper on the X11 font functions (GdkFont). All X11
font operations are now done directly using Xlib calls, and the only
interaction with GDK within the x11font mechanism is to get the X ids
for drawables, GCs and the X display itself.

This should remove an obstacle to porting to GTK3, and also makes the
XFontStruct for loaded fonts more readily available, which I hope will
come in handy for another plan I have in mind.


git-svn-id: svn://svn.tartarus.org/sgt@9289 cda61777-01e9-0310-a592-d414129be87e
Remove empty.h from CLEANFILES, so that after mkfiles.pl has
constructed it it won't be deleted again by 'make clean'. The effect
is that not only does this work (as r9288 arranged),

  ./configure; make plink

but these work too:

  ./configure; make; make clean; make plink
  ./configure; make; make distclean; ./configure; make plink


git-svn-id: svn://svn.tartarus.org/sgt@9290 cda61777-01e9-0310-a592-d414129be87e
Add some missing consts in character set handling.


git-svn-id: svn://svn.tartarus.org/sgt@9291 cda61777-01e9-0310-a592-d414129be87e
Change the unifont API so that text is passed right down to the
individual font implementation as wchar_t, rather than having to be
converted by the client into the appropriate MBCS/SBCS.

This also means I can remove 'real_charset' from the public-facing
contents of the unifont structure.


git-svn-id: svn://svn.tartarus.org/sgt@9292 cda61777-01e9-0310-a592-d414129be87e
Support font fallback even when an X11 server-side font is selected,
by introducing a wrapper around an individual unifont which falls back
to Pango (which already has built-in fallback) in the case where the
selected font doesn't support the glyph in question.

The wrapper itself is a (vestigial) subclass of unifont, to minimise
disturbance at the call sites.


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