same behaviour as before (tested a little bit), but should be easier to
expand.
(This is the easy bit -- work still needs to be done to fix
ssh2-keyderive-nonbug, vshell-no-bug-compat, etc -- but should be easier
now.)
[originally from svn r2293]
HTTP proxy -- fixed. (Also added a "len -= eol" to HTTP header munching,
although it has no practical effect.) HTTP proxying now works again, hurrah.
[originally from svn r2292]
console was ending up in one or other of debug.log or putty_mem.log. I
don't really understand why, but I've put some extra paranoia and caching
in debug(()) and that seems to have fixed it (tm). Perhaps I can get back
to debugging...
[originally from svn r2291]
* It paints over the top-left corner of the terminal window. A little
floating window would be rather nicer and not much harder to do.
* It uses the low-memory global, DragHook, which is unavailable in Carbon
and broken in some versions of Mac OS 8 (8.5?). I suspect this is
unavoidable, though.
[originally from svn r2287]
parts that haven't been painted yet still get an update event in their new
location. This code seems far too complicated, and I suspect there's a
better way. Still, scrolling continuously with the window partially
off-screen now works.
[originally from svn r2284]
* splitline gets support for changing the continuation character.
* deps returns a data structure for the output routine to format as
appropriate.
* There's a new program type, [M], for Macintosh.
* There's a new backend to output mac/Makefile.mpw.
[originally from svn r2272]
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]
SetFractEnable unconditionally flushes the Font Manager's width cache,
and the default is fine for us anyway. This more or less doubles
redraw speed, which is nice, but still not really fast enough.
[originally from svn r2263]
the benefit of X font names which are rather more verbose than
Windows. One day I want to replace all these fixed-size buffers with
sensible dynamically allocated stuff, but not today.
[originally from svn r2260]
* No more mucking about with transfer modes. We always set up the foreground
and background sensibly, EraseRect the whole lot and use srcOr. Apple
Tech Note QD505 suggests that this should be faster than srcCopy.
* Always use the Palette Manager if we've got Color QuickDraw, even in 1bpp
modes.
* Apply the cursor colours _after_ all the other stuff, rather than trying to
get them through everything else intact.
Unfortunately, this doesn't make much difference to the speed.
[originally from svn r2259]
background colour and pen mode have some silly effects on ScrollRect, so
set them back to their defaults before calling it.
[originally from svn r2254]
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]
application), rather from the entire chain. This prevents us displaying the
System version if PuTTY doesn't have one. Also cope with not finding any
'vers' resource.
[originally from svn r2247]
(rather than straight to the backend), and then prod the terminal. I think
this is closer to the correct set of things to do.
[originally from svn r2245]
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]