from, each time it starts on a new event boundary (this means that in
the old (5.3) version of the colorer, it also created a new co-routine
on each event boundary! (in other words, most of the reason one would
want co-routines here was bogus))
So, refactor the code to just always do this and eliminate a bunch of
set!'s and private fields in favor of just passing arguments like sane
code does. (We can't eliminate all of that, because we still do need
to be able to abort and thus all calls must be tail calls.)
original commit: 4ead534227fcbf8e90d0cc5e890f0a67fe6b05cb
cannot change its revision number during reading
This restriction was enforced only for editors that have non
string-snip% snips. The restriction was in place because the
implementation strategy was to chain thru the snips in the editor
using (send snip next) and that isn't safe if the revision number
changes.
The lifting of the restriction is implemented by tracking the position
in the editor where the last snip ended and, if the revision number
changes, starting over trying to get a snip from that position. This
has the effect that, if the revision number never changes, the code
should behave the same as it was doing before (so hopefully any new
bugs I've introduced in this commit will only show up if the old
implementation would have raised an error)
Also, exploit the lifting of this restriction in the colorer so it
doesn't to restart the port during to coloring that happens along with
the parsing
original commit: 95841b9303a753c5b85a929dbfe6167b12407343
Apologies for the gratuitious reindent, but I was having
a lot of trouble reading this file; it appears to have
last been worked on in an Emacs that used tabs for indentation
and doesn't use the same tab width as drracket.
original commit: 6c760b086fc87163bf3c7086c16efbe845a9b08b
As it turns out, changing the color (via change-style) can somtimes
split snips, which can change the revision number, which means that
the open port into the editor is no longer valid.
Since this doesn't seem to happen very much when editing in DrRacket,
we just detect this situation and give up on this colorer's port, and
hopefully it actually doesn't happen much (the place it happened that
let me notice this was when inserting an image via a menu in the
drracket test suites)
original commit: 226a7140b5784531103e10338785249a37aac677
refactor it so it doesn't add anything to the continuation ever, and
just check if it has been a while since we started (giving other
events a chance to run, if so). Also, interleave the calls to
change-style with the parsing of the buffer to get a more accurate
count of the time the colorer is taking
original commit: f07c8cf4907e283ab590b3528534b9784cd12c7f
Handling was broken by changes to fix enter and
leave events (in commit a5d7812732)
Merge to v5.3.1
original commit: ba6e383963de1c5e64058d99efceb799171827a9
found instead of just silently not checking the spelling
also, fix a bug in that case that used to cause drracket
to just crash
original commit: 4787361d7f0598751f962b28739a0cc79b3d0194
of the syntax colorer; adjust the spelling code so that it
uses nack events to communicate, in case things get aborted
original commit: 44a0c8a6c1bd744e139ea9b3a719807bee5708e1
Windows provide page metrics in either 1000ths of inches or
100ths of millimeters. I think Racket's calculation was wrong
in the mm case.
original commit: 4f75350bf3b8e45ebe8c92388ffa83855e56c5aa
It's very helpful to have a visual aid when dealing with a graphical
interface toolkit.
This patch adds an overview of the widgets available in the library
consisting of screen shots of the main ones and the snippets used to
produce them.
Each widget image link back to the full documentation.
original commit: 54ab1bfbfabb5e5fd8a8fe758a57da87b7bdb994
choose to print to pdf as well. Also, enable the preference
under linux (ie, make it available to be chosen-- all platforms
still default to printing via the platform-specific mechanism)
original commit: c675cf47f03cd50ff305bc7947c95628da151da5
A recent bug fix involved moving part of an `editor-canvas%' resize
out of atomic mode by queueing a callback (because the resize involves
quesrying the editor for its size, etc.), but then the callback
happens after a canvas is shown, which can cause it to appear with
bogus initial scrollbars. Queue the callback instead as a "refresh"
level callback, which gets a chance to run before a frame is made
visible.
original commit: 11045a0384b2b6f185cd98aec59e27b96b68c5f7
