- SVG icon sources
- Playback-style icons, logos, stop signs, magnifying glasses, etc., in diffuse and shiny styles
- Program to pre-render SVG files (icons/private/svg/render-png.rkt)
- Pre-rendered icons (PNGs in power-of-2 sizes)
- Made `icons' a module, with functions to conveniently load icons and convert to/from picts
- Scribble docs for `icons'
- Used new icons in DrRacket toolbar
This fixes a bunch of little things, including switch tabs between
windows with different states (closing PR 12341) and switching to
a non-module language.
- Delays drawing arrows until mouse hovers for a very short time
- Delays drawing arrows when scrolling
- Tooltips appear in the correct pane when the editor is split
- Fixes infinite event queue with scrolling a split editor while a tooltip is displayed
for syntax errors (i.e., exn:fail:syntax? exceptions)
Overall, it seems important to (in most cases) not show the stack that
leads to the point where raise-syntax-error is called, so as not to
confuse users who might think that that stack is useful information
in understanding how to fix the syntax error.
I've resisted this technique for avoiding those stacks for a long
time, mostly because common syntax errors in the standard settings
don't usually get the stacktrace button because they usually have
empty stacks (partly thanks to the with-stack-checkpoint dance).
But now that the underlying racket-generated stack is shown too, and
not just the errortrace-generated stack, it is harder to make those go
away. More precisely, DrRacket used to be able to rely on the fact
that files that were compiled to .zo files would not have the
instrumentation in them and thus stackframes from that code would not
show up in the stacktrace. No longer.
So, it seems time to try this alternative.
In particular, instead of trying to collect all of the arrows and do some kind
of a smart transitive closure (that tries to avoid adding links that would "skip"
expressions but doesn't always manage it), the new code tries instead to build
the right links directly while traversing the fully expanded expression
This also seems to have been a minor performance improvement. When running the
information collection phase of check syntax (ie, not counting the time for
expansion) on a 1.8 GHz core i7, for collects/framework/private/text.rkt,
the times went from:
cpu time: 7347 real time: 7413 gc time: 211
cpu time: 7328 real time: 7393 gc time: 239
cpu time: 7356 real time: 7418 gc time: 240
to:
cpu time: 7562 real time: 7632 gc time: 265
cpu time: 7555 real time: 7618 gc time: 269
cpu time: 7552 real time: 7617 gc time: 262
closes PR 11835
do not include in 5.2
Specifically, in the case that we're inheriting a language setting
from some earlier preference or something and the language we're
inheriting is one that saves prefixes, and the current file being
opened does not match any of the possible prefixes, then revert
to the not-a-language language, instead of using the value from
the preference
Also: finish the removal of the EoPL language level from the
DrRacket langauge dialog, and clean up the 'get guidance' dialog
Please cherrypick this commit to the 5.2 release branch
I believe that this can go wrong in the case that you edit a buffer and switch tabs
before drracket fully finishes responding to the edited buffer (due to a queue-callback
that postpones some of the response to editing the buffer) for online expansion.
At least, this is how I guess that the error below happened:
send: target is not an object: #f for method: get-view
=== context ===
/Users/robby/git/exp/plt/collects/racket/private/class-internal.rkt:4602:0: obj-error
/Users/robby/git/exp/plt/collects/drracket/private/module-language.rkt:1485:6: get-box method in .../module-language.rkt:1151:4
/Users/robby/git/exp/plt/collects/drracket/private/module-language.rkt:1397:6: invalidate-online-error-ranges method in .../module-language.rkt:1151:4
/Users/robby/git/exp/plt/collects/drracket/private/module-language.rkt:1387:6: clear-old-error method in .../module-language.rkt:1151:4
/Users/robby/git/exp/plt/collects/drracket/private/module-language.rkt:1177:6: buffer-modified method in .../module-language.rkt:1151:4
/Users/robby/git/exp/plt/collects/mred/private/wx/common/timer.rkt:34:38
/Users/robby/git/exp/plt/collects/mred/private/wx/common/queue.rkt:432:6
/Users/robby/git/exp/plt/collects/mred/private/wx/common/queue.rkt:472:32
/Users/robby/git/exp/plt/collects/mred/private/wx/common/queue.rkt:618:3
esc;c:x send-toplevel-form-to-repl
m:c:x send-toplevel-form-to-repl
c:c;c:e send-toplevel-form-to-repl
c:c;c:r send-selection-to-repl
c:c;m:e send-toplevel-form-to-repl-and-go
c:c;m:r send-selection-to-repl-and-go
c:c;c:z move-to-interactions
Took the inspiration for the list from the keybindings
available in Scheme mode in Emacs.
Closes PR 12211 (and probably others)
This is a backwards incompatible change; there is a more complex change
that just stubs this stuff out that may be better that we may need
isntead of this commit.
specifically, when drracket kills the thread that is expanding/transforming
the program, first print out its stack trace. that way, if it is stuck
somewhere, maybe we'll get a clue as to where
this also gets rid of the module-level imports as annotations in the bar
along the buttom of a drracket window, which eliminates the use of the
'drracket:check-syntax:mouse-over status line and thus:
closes PR 12186
this means that various things that try to color and otherwise show info by
changing the way the editor looks no longer need to worry about whether it
is locked and delay things in some complicated way. also, this means that
users can edit while drracket is running the program which is hopefully
less confusing.
