font whose encoding comes up as CS_NONE - but this is also true for
iso10646-1 fonts, since libcharset doesn't support wide-character
encodings! Hence UTF-8 cut and paste was enabled in ordinary modes,
but disabled in UTF-8 mode, which was a bit embarrassing. Now we
have a dedicated flag variable indicating direct-to-font mode.
[originally from svn r2425]
know what that encoding actually is, we can do our best to support
additional charsets (VT100 linedrawing, SCO ACS, UTF-8 mode) using
the available characters; if we don't, we fall back to a mode where
we disable all Unicode cut-and-paste and assume any Unicode
character is undisplayable.
[originally from svn r2413]
does UTF-8 copy and paste (falling back to normal strings if
necessary), it understands X font encodings and translates things
accordingly so that if you have a Unicode font you can ask for
virtually any single-byte encoding and get it (Mac-Roman pterm,
anyone?), and so on. There's work left to be done (wide fonts for
CJK spring to mind), but I reckon this is a pretty good start.
[originally from svn r2395]
SockAddr, which just contains an unresolved hostname and is created
by a stub function in *net.c. It's an error to pass this to most of
the real-meat functions in *net.c; these fake addresses should have
been dealt with by the time they get down that far. proxy.c now
contains name_lookup(), a wrapper on sk_namelookup() which decides
whether or not to do real DNS, and the individual proxy
implementations each deal sensibly with being handed an unresolved
address and avoid ever passing one down to *net.c.
[originally from svn r2353]
well, though it's a lot less useful since you still can't bind to
low-numbered ports of odd loopback IPs. Should work in principle for
SSH2 remote forwardings as well as local ones, but OpenSSH seems
unwilling to cooperate.
[originally from svn r2344]
not -1 (it turns out _most_ X fonts prefer the former, though
irritatingly my favourite real X font used to prefer the latter
which was why I made the X version of my Font Of Choice do so too),
and also clip to the boundaries of the rectangle we should be
drawing text in. This still doesn't completely prevent display
corruption in the case where text drawn in one sweep is partially
overwritten in a future one, but gnome-terminal has this problem
too, and now we've got the right default SB offset _and_ offer the
opportunity to reconfigure it I think this is pretty good for now.
[originally from svn r2184]
doesn't hang when you hit ^C, which is nice. I think a better
solution would involve nonblocking sockets; as it stands it's a
little dependent on what may be quirks of the Linux socket layer.
[originally from svn r2175]
doesn't yet use the SSH agent, no way to specify arbitrary config
options, no manpage yet, couple of other fiddly things need doing,
but it makes SSH connections and doesn't fall over horribly so I say
it's a good start. Now to run it under valgrind...
[originally from svn r2165]
this init sequence - it surely can't be right that `pterm --help'
with no DISPLAY complains at the lack of DISPLAY rather than giving
a help message!
[originally from svn r2164]
source files in which it's no longer required (it was previously
required in anything that included <putty.h>, but not any more).
Also moved a couple of stray bits of exposed WinSock back into
winnet.c (getservbyname from ssh.c and AF_INET from proxy.c).
[originally from svn r2160]
mode==BELL_VISUAL, otherwise taskbar flashing won't happen on visual
bells. It's up to the frontend routine to spot BELL_VISUAL and avoid
making any noise.
[originally from svn r2155]
into line with most other xtermalikes. On Unix, the exit code of a
shell is the last exit code of one of its child processes, even if
it's an interactive shell - so some pterms will close and some will
not for no particularly good reason. Power-detaching a screen
session is especially bad for this.
COE_NORMAL is still useful for specialist purposes (running a single
command in its own pterm), but I don't think it's a sane default,
unfortunately.
[originally from svn r2154]
a pterm came up while Alt was down, then releasing it would cause a
^@ to be generated. Also, though, I've decided that Alt plus a
single numberpad key should not generate a low-numbered control
code, because that's too easy to do by mistake and the codes are too
powerful. Anyone who really _wants_ to create a ^C or ^D from the
numberpad can do Alt-03 or Alt-04 easily enough; two-digit codes and
more such as Alt-65 are unaffected.
[originally from svn r2153]
absent, and also (I think) all the frontend request functions (such
as request_resize) take a context pointer, so that multiple windows
can be handled sensibly. I wouldn't swear to this, but I _think_
that only leaves the Unicode stuff as the last stubborn holdout.
[originally from svn r2147]
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]
As a result I've now been able to turn the global variables `back'
and `backhandle' into module-level statics in the individual front
ends. Now _that's_ progress!
[originally from svn r2142]
now compiles and runs again after the major destabilisation.
Unfortunately it wasn't feasible to actually encapsulate all of the
pty backend's data, since the utmp helper and the need to fork and
drop privileges before doing anything else at all rather confuses
matters. So the data handle passed around to the pty backend is a
null pointer, and the pty backend is just as global-ridden as it
always has been. Shame, but such is life.
[originally from svn r2128]
only on clean exit, which is a departure from most xterm-alikes but
Ian reckons people will love me for it. If this turns out to be
wrong, we can always change the default for Unix.
[originally from svn r2120]
terminal.c was apparently relying on implicit initialisation to
zero, and also I've removed the backends' dependency on terminal.h
by having terminal sizes explicitly passed in to back->size().
[originally from svn r2117]
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]
