guard more of the filesystem manipulations with
handlers and log errors instead of letting them
be raised and show up as internal errors
related to PR 13403
original commit: 94b54db11823b4683234424174aca2836d422204
it only looks left and right at hyphens and only
up and down at pipes, etc. This better handles the
case where you have something like this:
+--------------+
| (<= a-x b-y) |
+--------------+
Before this commit, it would have adjusted the hypens
inside the identifiers
original commit: 6a69da76e2f9e5b2105dee89535d5ace4defed92
adjust the way it changes characters so it
doesn't change them when they are already the right
thing (this means set-modified is not always called
and also improves performance in the case that little
changes in a big diagram)
original commit: 5a9c5f681b11d563275f7672c3af5160bb68113c
also clean up the code a bit (make sure the h? argument to
set-label-visible is really a boolean and make some of the
long lines narrower)
original commit: ccae98777a15c67f04f1ba5d54ad577acb7994dd
This didn't matter much before but now that
paren colors have interesting alpha components,
things look bad when it is ignored!
original commit: f5efc0313435c922914ccd924d876ffe8b740e80
For example, a new DrRacket window (with a file named tmp.rkt in the
and 356 afterwards. This is under mac os x with, I believe, the
default system font sizes. (The file is important because different
languages can have different buttons in the toolbar and the filename's
length itself can affect the minimum size.)
Mostly this change is the addition of a new kind of panel that
lets its children have multiple fixed sizes (as opposed to
just a single minimum size and (optionally arbitrarily large))
It also adjusts the various toolbar buttons to use this new code.
Also, there's a few tweaks to shrink other things that became the
limiting factor in shrinking the width of the DrRacket window.
Currently, at least for #lang racket programs, the toolbar buttons
along the top of the window are the limiting factor (including the
save button). With a bogus language (ie, #lang rackeeet), the bottom
bar is the limiting factor, since that will have only the Save, Run,
and Stop buttons.
related to PR 13281
original commit: 993cd40208b040bfce9db649a59ff7bb9e95de2d
message so they don't take up space when they aren't being shown
(to reduce the minimum width of the window)
original commit: a45f94b58ba2aee49c830ecc6379b23ace0c9b16
When switching tabs while an on-reflow initiated callback
might still be running can lead to bogus information
coming back from position-locations, as the editor loses
its admin.
So, we just give up recomputing the rectangles when the
admin is gone and, for now, expect that there will be
another on-reflow call when the admin comes back that'll
restart the process (not sure that this is guaranteed tho)
original commit: 52d0b7e352a493e127e0d7cd780a34938dddea08
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
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
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
