This gets rid of all those annoying 'win', 'ux' and 'gtk' prefixes
which made filenames annoying to type and to tab-complete. Also, as
with my other recent renaming sprees, I've taken the opportunity to
expand and clarify some of the names so that they're not such cryptic
abbreviations.
mid-session if we are not using SSHv1. I've done this by introducing
a generic `cfg_info' function which every back end can use to
communicate an int's worth of data to setup_config_box; in SSH
that's the protocol version in use, and in everything else it's
currently zero.
[originally from svn r5040]
[r5031 == d77102a8d5]
comment when I unblock it in pty.c to reflect reality. Also I've
moved block_signal() out of pterm.c into signal.c, so I can
conveniently use it for unblocking SIGCHLD rather than having to
reinvent it in pty.c.
[originally from svn r5006]
blink when the window doesn't have focus, we don't schedule blink
timers at that point either.
Infrastructure change: term->has_focus should now not be written
directly from outside terminal.c. Instead, use the function
term_set_focus, which will sort out the blink timers as well.
[originally from svn r4911]
which pretty much any module can call to request a call-back in the
future. So terminal.c can do its own handling of blinking, visual
bells and deferred screen updates, without having to rely on
term_update() being called 50 times a second (fixes: pterm-timer);
and ssh.c and telnet.c both invoke a new module pinger.c which takes
care of sending keepalives, so they get sent uniformly in all front
ends (fixes: plink-keepalives, unix-keepalives).
[originally from svn r4906]
[this svn revision also touched putty-wishlist]
of the SSH servers I conveniently have access to (Debian stable OpenSSH --
3.4p1 -- and lshd) seem to take a blind bit of notice, but the channel
requests look fine to me in the packet log.
I've included all the signals explicitly defined by
draft-ietf-secsh-connect-19, but I've put the more obscure ones in a submenu
of the specials menu; there's therefore been some minor upheaval to support
such submenus.
[originally from svn r4652]
the same window (Windows version only).
Policy change: it's now the backend's responsibility to call
update_specials_menu() at the start of a session (or whenever it feels ready),
if it has any special commands. Otherwise the menu won't be displayed.
[originally from svn r4649]
http://www.cl.cam.ac.uk/~mgk25/unicode.html#activate
feels strongly that it should be easy to make _all_ your
applications work in UTF-8 mode, without having to remember a switch
for each one. Every application should simply note a UTF-8 locale
setting and switch into UTF-8 mode automatically.
Therefore, for the Unix port only, there's now a checkbox, enabled
by default, which causes the drop-down Translation box to be
overridden if the locale indicates UTF-8. Anyone who doesn't like
this, or doesn't like MGK, is welcome to turn it straight back off.
I'm not _completely_ convinced by MGK's argument myself; for
xterm/pterm to do _useful_ UTF-8 you also need to specify a decently
Unicode-capable font, and there's no way _that_ can be automagically
done on noticing a locale setting. But it's a de facto standard
(i.e. xterm does it :-) so I might as well at least be _able_ to
support it.
[originally from svn r4648]
array of each `termline' structure now contains optional additional
entries after the normal number of columns, which are used to chain
a linked list of combining characters off any primary termchar that
needs it. This means we support arbitrarily many combining
characters per cell (unlike xterm's hard limit of 2).
Cut and paste works correctly (selecting a character cell containing
multiple code points causes all those code points to be cut and
pasted). Display works by simply overlaying all the relevant
characters on top of one another; this is good enough for Unix
(xterm does the same thing), and mostly seems OK for Windows except
that the Windows Unicode fonts have a nasty habit of not containing
most of the combining characters and thus overlaying an
unknown-code-point box on your perfectly good base glyph.
I had no idea how to add support in the Mac do_text(), so I've
simply stuck in an assertion that will trigger the first time a
combining character is displayed, and hopefully this will bite
someone with the clue to fix it.
[originally from svn r4622]
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]
No very good reason, but I've occasionally wanted to frob it to see if it
makes any difference to problems I'm having, and it was easy.
Tested that it does actually cause keepalives on Windows (with tcpdump);
should also work on Unix. Not implemented on Mac (does nothing), but then
neither is TCP_NODELAY.
Quite a big checkin, much of which is adding `keepalive' alongside `nodelay'
in network function calls.
[originally from svn r4309]
by disabling bold-font-name guessing (if their bold fonts are ugly).
I've turned the UI inside out, but the meat is pretty much the same.
[originally from svn r3410]
selections, meaning that (a) a pterm can leave copied text in the
cut buffer after it terminates so that applications can pick it up
even though it isn't still around to deliver the selection in
person, and (b) pterm can pick up things left in this way by other
apps.
Downside is that all of this only happens in ISO8859-1, because X is
weird like that.
[originally from svn r3409]
and implement the required subset of ISO-2022 in libcharset, but it
turns out that Xlib provides conversion functions between UTF-8 and
compound text, which are just about ideal for us. So now we can
paste multilingual stuff both to and from emacs21. Rock on.
[originally from svn r3193]
actually _understand_ compound text yet - anything with
non-ASCII-or-8859-1 characters will fail miserably - but it will at
least successfully receive plain text if the pasting application
doesn't see fit to give it out in any other format.
[originally from svn r3192]
not redrawn when the window background colour is reconfigured mid-
session. In addition, the Official Window Background is not reset,
meaning that opaque resizes etc will flicker in the old background
colour. This checkin should fix both.
[originally from svn r3190]
from the ones given; so it'll ask for a font twice as wide as your
base one if you don't specify a wide font, it'll ask for a bolded
version of your base font if you don't specify a bold font, and
similarly for a wide/bold font. Should solve Debian bug #187389; at
least it works for me.
[originally from svn r3175]
ptrs and ints of different size and -Werror makes this serious).
The GTK bits are done by Colin's patch to use GINT_TO_POINTER
(thanks); the uxnet bits are done by cleaning up the rest of the
code. In particular, network.h now typedefs `OSSocket' to be a type
capable of holding whatever the OS's socket data type is that
underlies our socket abstraction. Individual platforms can make this
typedef themselves if they define OSSOCKET_DEFINED to prevent
network.h redoing it; so the Unix OSSocket is now int. Default is
still void *, so other platforms should be unaffected.
[originally from svn r3171]
Euro-supporting font with a Euro-enabled X key map will now actually
generate a Euro character rather than shrugging and doing nothing.
[originally from svn r3151]
had to move another of its values out into wincfg.c - paradoxically,
this was the `font has X encoding' option! (Because the Unix font
handling code expects to be able to tell for _itself_ whether it has
a font with X-encoded line drawing glyphs.)
[originally from svn r3145]
gtk_window_set_title() overwrote both titles at once. Icon title is
now working properly under X, and since X was the reason for the
whole icon/window title separation _anyway_ they default to being
separate.
[originally from svn r3144]
time. This gives rise to a whole bunch of spare warnings, one or two
of which might have been actual bugs; now all resolved.
[originally from svn r3134]
remember changes in COE so it knows whether to print a message, and
(b) once the session has already ended, Warn On Close should shut up.
[originally from svn r3102]
of PuTTY (terminal, backend, logctx etc) take a `void *' handle
passed to them from the frontend, and used as a context for all
their callbacks. Most of these point at the frontend structure
itself (on platforms where this is meaningful), except that the
handle passed to the backend has always pointed at the terminal
because from_backend() was implemented in terminal.c. This has
finally bitten Unix PuTTY, because both backend and logctx have
been passing their respective and very different frontend handles to
logevent(), so I've fixed it.
from_backend() is now a function supplied by the _frontend_ itself,
in all cases, and the frontend handle passed to backends must be the
same as that passed to everything else. What was from_backend() in
terminal.c is now called term_data(), and the typical implementation
of from_backend() in a GUI frontend will just extract the terminal
handle from the frontend structure and delegate to that.
This appears to work on Unix and Windows, but has most likely broken
the Mac build.
[originally from svn r3100]
