Specifically, two things:
- make drracket more careful to not crash when aspell
doesn't behave, and
- have a more careful test when clicking the menu item
(it now does a trial run of aspell instead of just
looking for the binary)
closes PR 13242 (I realize there is still a feature
request mentioned in the audit trail of that PR, but
since the main problem is fixed, I'll consider that
to just be something separate)
I started from tabs that are not on the beginning of lines, and in
several places I did further cleanings.
If you're worried about knowing who wrote some code, for example, if you
get to this commit in "git blame", then note that you can use the "-w"
flag in many git commands to ignore whitespaces. For example, to see
per-line authors, use "git blame -w <file>". Another example: to see
the (*much* smaller) non-whitespace changes in this (or any other)
commit, use "git log -p -w -1 <sha1>".
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.)
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
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)
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
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)
line-numbers mixin
Specifically, when both are turned on, the #lang line now shows
the line number and shifts the "#lang ..." over to the same spot
where it is drawn when the first line is natually visible
Also, rackety
pixel of space in between lines in DrRacket.
This change is based on Matthew's experience having a look
at the font setup on the three platforms.
He writes:
> * Mac OS X: the convention seems to be to add space between lines.
> TextEdit, for example, looks like DrRacket: the maze has spaces.
>
> (I can't find a font that makes the maze look right, actually, even
> if I adjust the line spacing.)
>
> * Windows: the convention seems to be that space is built into the
> font. DrRacket (and SirMail) draw lines more sparsely than Notepad.
>
> Perhaps consistent with the differing conventions, the height of
> "Courier New" at 11-pixel size is 14 on Windows, 13 on Mac OS X.
>
> * Unix: the convention seems to be to add space. DrRacket looks like
> the default Terminal and Text Editor programs on Ubuntu.
>
> The maze nevertheless looks right everywhere, because the glyphs
> extend an extra pixel above the declared bounding box!
Before this commit, opening collects/drracket/private/unit.rkt required
about 17.5 megabytes of memory and after this commit, it is down to
about 15 megabytes.
The precise measurement I did was to create a frame and a scheme:text%
object in it, record the result of current-memory-use, open the file,
and record current-memory-use again.
For comparison, using a text:standard-style-list% object instead of
the scheme:text% requires only about 4.1 megabytes. One difference
being that there are about 3x more snips (10,204 vs 33,901 (after the
commit)), since we have one snip for each region that has a different
color in the scheme:text version, and the text:standard-style-list has
no colors and thus about two per line (there are 5006 lines in the
file).
