a marker which defines everything before it as `permanent'
scrollback and everything after it as `temporary'; only temporary
scrollback lines are returned to the main screen when the window
height is increased. Screen clears mark the lines pushed into the
scrollback as permanent; so lines explicitly cleared off the screen
by ESC[2J are never returned to it by mistake. This patch also fixes
the incorrect state the primary screen is left in when the window is
resized while the alternate screen is active.
[originally from svn r2923]
clears, and also to temporarily push the primary screen contents
into the scrollback while the alternate screen is active and bring
it back afterwards.
[originally from svn r2910]
combining adjacent ones for the same region, and runs them all in do_paint.
I'm not sure it's entirely right, but it works on my Mac in every case I've
tested.
[originally from svn r2763]
these fiddly little changes are no longer bugs I introduced
recently, they're bugs that have been around all along and I've only
just smoked out by altering the ATTR_* definitions.
[originally from svn r2754]
Apparently I used to rely on the fact that the same `erase_char'
used to wipe parts of the screen was also a good value to use for
resetting line attributes. Should now be more robust against future
reorganisations of the ATTR_* bit fields.
[originally from svn r2740]
foreground colours, and ESC[100m through ESC[107m to set bright
background colours. Hence, so do we. Bright-foreground is
distinguishable from bold, and bright-background distinguishable
from blink, when it leaves terminal.c; the front end may then choose
to display them in the same way if it's configured to do so. This
change makes the xterm backend for Turbo Vision (!!!) work properly.
Untested on Mac.
[originally from svn r2734]
yet -- there's no Alt+keypad support, and no way for the front-end to find
out what it should do with the Num Lock light. It's also not fully tested.
Nonetheless, it's at least as good as the previous Mac keyboard handler.
Other platforms probably shouldn't adopt it just yet.
[originally from svn r2728]
both the raw and the cooked mouse button, with the mapping being done in
advance by the front-end. This is useful because it allows the front-end to
use information other than the raw button (e.g. the modifier state) to decide
which cooked button to generate.
.
Front ends other than the Mac one are untested, but they just call
translate_button() themselves and pass the result to term_mouse().
[originally from svn r2721]
areas of the code. Not all back-ends have been tested, but Telnet and SSH
behave reasonably.
Incidentally, almost all of this patch was written through Mac PuTTY,
admittedly over a Telnet connection.
[originally from svn r2615]
just done this the very simple way - bundle all the globals into a
data structure and pass pointers around. One particularly ugly wart
is that wc_to_mb now takes a pointer to this structure as an
argument (optional, may be NULL, and unused in any Unicode layer
that's even marginally less of a mess than the Windows one). I do
need to do this properly at some point, but for now this should just
about be adequate. As usual, the Mac port has not been updated.
[originally from svn r2592]
and term_reconfig() now passes in a new structure which is copied
over the top. This means that the old and new structures can be
compared, and the _current_ as well as default states of auto wrap
mode, DEC origin mode, BCE, blinking text and character classes can
be conveniently reconfigured in mid-session without requiring a
terminal reset.
[originally from svn r2557]
initialise term->paste_len during initialisation, and indeed looking
at the code confirms this. I'm puzzled as to why valgrind didn't
spot this in pterm, though, since it's all in cross-platform code!
[originally from svn r2494]
right-hand half of a CJK wide character; correct handling of cut and
paste when CJK text wraps between lines _irrespective of the parity
of the starting column_; correct handling of wordness values
irrespective of which half of a CJK character the user
double-clicked on; correct handling when any terminal activity
overwrites only one half of a CJK wide character. I think we now
behave marginally better than xterm in this respect (it has a redraw
problem when you overwrite the RH half of a CJK char), so I'm happy.
Also redefined the internal UCSWIDE marker to something in the
surrogate range, while I'm here, so that U+303F is available for use
by actual users.
[originally from svn r2426]
_both_ halves of the character set, rather than flipping the two
halves. My source for this is linux/drivers/char/console.c.
[originally from svn r2394]
ignore when breaking text into runs for display, and implement setting this
on Mac (other ports just use 0xffffffff).
We don't use DeviceLoop for this any more because Apple Technical Q&A
QA1024 says we shouldn't. Unlike their example, we don't depend on the
Display Manager's being present either.
[originally from svn r2264]
we need to update dispcurs as well as disptext.
Add scroll optimisation to scroll(). This makes it rather obvious that scroll
optimisation is breaking with PuTTY's usual policy of lazy updates, since
scrolling is done eagerly. Fixing this so that all the scrolling is saved
up for do_paint would be nice, but non-trivial.
[originally from svn r2252]
This introduces a new front-end function, do_scroll(), which is expected to
scroll a part of the physical display and cause repaint events for any
areas that couldn't be scrolled (e.g. because they were hidden).
scroll_display() is a wrapper around this which also updates disptext to
match.
Currently, scroll_display is only used in response to user scrollback requests
(via term_scroll()), but extending scroll() to use it as well should be
easy.
All of this is conditional on the front end's defining OPTIMISE_SCROLL, since
only the Mac front end currently implements do_scroll().
[originally from svn r2242]
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]
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]
each backend now stores all its internal variables in a big struct,
and each backend function gets a pointer to this struct passed to
it. This still isn't the end of the work - lots of subsidiary things
still use globals, notably all the cipher and compressor modules and
the X11 forwarding authentication stuff. But ssh.c itself has now
been transformed, and that was the really painful bit, so from here
on it all ought to be a sequence of much smaller and simpler pieces
of work.
[originally from svn r2127]
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]
of the alternate-screen and save-cursor control sequences, with
subtly different semantics and entertaining interactions with the
usual ones. No thanks to xterm for doing so in the first place :-(
This checkin should sort it all out.
[originally from svn r2112]
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]
The current pty.c backend is temporarily a loopback device for
terminal emulator testing, the display handling is only just enough
to show that terminal.c is functioning, the keyboard handling is
laughable, and most features are absent. Next step: bring output and
input up to a plausibly working state, and put a real pty on the
back to create a vaguely usable prototype. Oh, and a scrollbar would
be nice too.
In _theory_ the Windows builds should still work fine after this...
[originally from svn r2010]
beginning of a Unix port. It's nowhere near done, and currently it
won't even compile on Unix. But this represents the start of the
process of separating out platform-specific code, and also contains
the mkfiles.pl changes required to support a Unix makefile and a
non-flat source tree.
[originally from svn r1993]
