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]
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 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]
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]
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]
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]
it's automatically deactivated by any keypress, so that command-line
beeps from (e.g.) filename completion don't suddenly stop occurring,
but it still provides a rapid response to an accidental spewing of a
binary to your terminal.
[originally from svn r2107]
set[ug]id. All privs-requiring pty operations are done at the very
start of the run, then privs are dropped before initialising GTK.
Utmp is handled by forking a still-privileged subprocess at this
point, and later asking it (through a pipe) to stamp utmp. The
subprocess cleans up utmp on exit, which has the additional
advantage that if the main pterm process suffers some sort of
unexpected termination (up to and including SIGKILL) the subprocess
can still mop up utmp.
[originally from svn r2082]
send a button 4 press for an upward wheel movement and a button 5
press for a downward one). Untested since my own trackball's button
4 does nothing obvious. Someone with a mouse wheel should give this
a workout.
[originally from svn r2069]
rather than the gtk_window_set_policy approach; the GNOME people say
that the former is the Right Thing in spite of the latter looking
obviously plausible.
[originally from svn r2066]
want a new option to configure it to be on the LHS though. And some
lunatic is bound to ask for an xterm-style scrollbar too... :-)
[originally from svn r2062]
including server-controlled resizing. Irritatingly I've had to use a
deprecated option to gtk_window_set_policy() to make this work,
resulting in me raising GNOME bug #95818 to ask for it to be un-
deprecated again...
[originally from svn r2061]
