Profiler output suggests that forward-match is a bit expensive. Here
is profiler output from the original code, when profiler is wrapped
around tabify-selection:
------------------------------------------------------------------------------------------------------------
loop [34] 0.1%
get-backward-sexp method in ...k/private/racket.rkt:425:2 [28] 99.9%
[37] 50648(61.1%) 0(0.0%) stick-to-next-sexp? method in ...k/private/racket.rkt:425:2 ...
do-forward-match method in ...rk/private/color.rkt:71:2 [50] 99.9%
...
------------------------------------------------------------------------------------------------------------
get-forward-sexp method in ...k/private/racket.rkt:425:2 [38] 17.1%
stick-to-next-sexp? method in ...k/private/racket.rkt:425:2 [37] 82.9%
[50] 61043(73.6%) 53(0.1%) do-forward-match method in ...rk/private/color.rkt:71:2 ...
colorer-driver method in ...rk/private/color.rkt:71:2 [66] 99.8%
match-forward method in paren-tree% [72] 0.1%
------------------------------------------------------------------------------------------------------------
The patch does the prerequisite string matching before calling forward-match.
Reference to dev list: http://lists.racket-lang.org/dev/archive/2012-November/010976.html
original commit: 43b0e2157c5247653da96d24dee833be429c4bfc
Handle close parentheses in a smarter way while in
auto-parens mode and be a little more smart about
inserting brace pairs in general.
In summary:
- Add some "smart-skip" behavior to insert-close-paren,
described in the documentation.
- When auto-parens mode is enabled,
the existing "balance-parens" keybinding invokes
insert-close-paren with a smart-skip argument of
'adjacent
- A new "balance-parens-forward" keybinding invokes
insert-close-paren with a smart-skip argument of
'forward (whether or not auto-parens mode is
enabled)
- Enable basic smart-skip behavior for
strings ("...") and |...| pairs, specifically, typing
a double-quote or bar character when the cursor
immediately precedes one causes the cursor to simply
skip over the existing one
- Tweak auto-insertion of block comment pairs; i.e.
typing hash and a bar results in a properly balanced
#||# pair. Also, when you type a bar character when
the cursor immediately precedes a closing bar and
hash of a comment, then the cursor skips over both
characters (this seems better than having it just
skip over the bar, and then having to introduce a
new keybinding to detect when a hash is typed while
the cursor is between a bar and a hash)
- In strings and line/block comments, auto-parens mode
no longer has any effect (you can still use the M+..
keybindings to force insertion of a particular brace
pair)
- Detect when a character constant is being typed, and
don't insert brace pairs if so; i.e. if the cursor
is immediately after #\ , then typing any open parens,
double quote, or bar, does _not_ result in the
insertion of an open/close pair even in auto-parens
mode
- Add a bunch of tests related to auto-parens, matching
pairs of braces, strings, comments, etc. to
collects/tests/framework/racket.rkt
original commit: 8f3343cd0129001aa9c7ce263f58e8ed4929c15c
Changes the implementation of highlight-range so that it
only recomputes all of the new locations from the positions
when on-reflow is called (otherwise only computing the
relevant ones) and make the on-reflow callback chop itself
up, in case there are lots of highlighted ranges to avoid
tying up the event loop.
Changes searching so that it doesn't neccessarily compute
the entire search results in a single event callback
(but also make it start the computation more aggressively)
Overall, this changes the strategy from one that, for any potentially
long-running callback, just tried to push it off into the future, into
a strategy that tries to avoid long-running callbacks by breaking the
work up into chunks, but starting the first chunk immediately (in a
low-priority callback).
Also, misc other changes to make this work better and generally clean
things up.
original commit: 5197649cb7556abd96282d3a838c4ba4f7c8de8c
Specifically, when a style change happens that ends up
not changing the size of anything, then track that
lack of size change enough to be able to avoid
calling on-reflow.
This is important for the interaction between the
colorer and the search bubbles in DrRacket. That is,
when you make an edit that causes the colorer to have
lots of work, then each chunk of work it does before
yielding control to the event loop would also trigger
a call to on-reflow, which would cause the search bubbles
to recompute their sizes. Overall, the main bad thing
this does is cause lots of allocation and aside from
that it doesn't hurt interactivity. Still, there is a
lot of useless work here, and those extra GCs can be
pretty substantial when you're doing something crazy like
searching for " " in a big file.... (there are 95k spaces
in unit.rkt, in case you were curious)
original commit: 0264d3d5adca4a85f1fad65a89165184f5286459
file dialog show files with ".plt" by default.
Also, clarified the docs for finder:default-extension
closes PR 13104
original commit: 11a5721b59d1400900d67f825470e6ee6f7d6b8a
popup menu
Extends append-editor-operation-menu-items so that when you
pass an editor and a position, it checks to see if that spot
has a non-string% snip and, if so, copies that one position
(or cuts it, depending).
Then, use that extension in DrRacket
closes PR 12791
original commit: 6fff8a3030bfaddd0eb8113c9f67d6b7e70500ff
It was pulling from `scheme/gui/base', instead. The one from `scheme/gui/base'
is now different and still pulls from `scheme/gui/base'.
This could break some programs that accidentally depended on `scheme/gui/base'
exports from `gui-dynamic-require', but it's more likely to fix problems.
original commit: 702df4b07add593618713500e7236b5bd75067b3
The `scheme/base' module had become unreachable from the `mred' module.
While that normally would be a good thing, it lead to troublesome
multiple instantiations of `scheme/base' that caused problems for
attaching further modules to the namespace.
original commit: d90fbaeff469b7accd3cc408e1bbda664a25670b
A page-setup dialog is now available on all platforms, which means
that no dialog will appear when a `pirinter-dc%' is created. Meanwhile,
note that `end-doc' normally shows a (different) dialog.
original commit: 843aa670e96fe34f1b2426ba76f7cc44ceefb867
getter/setters instead of overriding a method
this has the benefit that the delegate does not have to be
rebuilt when switching tabs in drracket; we just leave the
old delegate on the old definitions text, and the swap it
back into the editor-canvas when we swap the text% object
itself back in.
original commit: d0ce0de3988f02c5b260aa663fac95134b877761
coloring in the contour window to make only a single call to
invalidate-bitmap-cache
It was making two before, which could have pretty similar regions,
leading to two repaints instead of just one. When pushing the down
arrow near the bottom of the visible regions of the definitions text
was causing those two calls to take about 30 milliseconds and after
this change the one call seems to be about half that (but there is
lots of variance so I'm only sure that it helped some, not how much)
original commit: 6fc70a04d8b69f41d82c3bcbeeff26254017052d
A long time ago, I tried to improve the interactiveness
of DrRacket when the contour window was open with the
code that is removed in this commit. Looking at it today,
it seems clear that this code was buggy (and, now that
we've had lots of experience with it, it didn't actually
help with interactivity either)
The problem is that the code didn't record enough
information about the change to the editor in the thunk put
into the 'todo' field. It would remember that a particular
range was out of date, but it woudln't remember which
characters were in that range, so when it would go to copy
the characters, it may be getting the wrong characters
(since another edit may have happened since the thunk was
stored in the todo field)
This change also has the side benefit that the time it takes
to change the contour window is now being tracked by the
colorer, which means that it'll give up a bit sooner
coloring less in each go, but hopefully maintaining the
interactivity
original commit: 052ee14afc748929f9195620c183f053d307ac21
- add support for getting a histogram of event timings
- add support for scripting drr to be able to make comparisons
original commit: a9b6f8ea46076d2c6cc75bf0d3f8c8a2c1c4f3c6
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)
original commit: c5330194a9a992a8f34781327ff0975624399660
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>".
original commit: 672910f27b856549ad08d38832b6714edf226c8e
drracket and try to make them happen less often (or, if there will be
multiple ones, try to guarantee that there is an edit sequence)
original commit: 81dc3bae37690e066204051b8b32d7db16ce4a67
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
