When an eventspace is created, its thread implicitly calls
`yield'. It now effectively loops with `yield' and while
catching continuation aborts.
Closes PR 12566
Use the system-supplied region to intersect with the
window region, so that drawng the border doesn't replace
the window content.
See also Kieron Hardy's post on the users' list, 2/7/12.
exceptions instead of exn:fail exceptions for errors having to do
with the actual attempt to change/retrieve the creator and type
(but leaving alone the type errors)
closes PR 12400
Somewhere along the way --- probably in porting the editor
classes to Racket --- the caps-lock specification in a keymap
string was treated the same as other modifiers, but it is
supposed to be neutral when the key string starts with ":".
Closes PR 5486, 10347, 10993, 12184
More generally, fix horizontal refresh when an editor has left
padding. Otherwise, deleting a character in DrRacket with line
numbers shown seems sluggish, because the update waits for a
refresh event.
After all the previous attempts, the problem seems almost trivial:
although Apple documents `NSAnyEventMask' as the constant #xFFFFFFFF,
it's actually NSUIntegerMax (and the difference matters in 64-bit
mode).
Merge to 5.2.
This fix uses the same`run'-vs-`finishLaunch' technique as before,
but patches up the modal-dialog problem by calling `run' again
with a callback to start a modal loop.
Merge to 5.2.
Calling NSApplication's `run' works better than calling `finishLaunching'
directly, particularly in 64-bit Lion for some reason.
Relevant to PR 12102
Relevant to PR 12257
Especially for gtk, where a client-resize notification was
getting mixed up with a frame-configure notification. On all
platforms, `on-size' and `on-move' for a frame% were queued
at too high a priority.
GRacket registers witht a global table to indicate that
no transform is needed. (This change was intended to address
a 64-bit problem on Lion. It didn't help, but this seems
better than ignoring an error.)
Since the number of monitors can change at any time, reliable
use of these functions requires handling failure in some way.
Handling #f results is easier (and less likely to mask other
problems) than catching exceptions.
