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
(cherry picked from commit d362bda6d3)
This fix uses the same`run'-vs-`finishLaunch' technique as before,
but patches up the modal-dialog problem by calling `run' again
with a callback to start a modal loop.
Merge to 5.2.
(cherry picked from commit f6e5468dbb)
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
Calling NSApplication's `run' works better than calling `finishLaunching'
directly, particularly in 64-bit Lion for some reason.
Relevant to PR 12102
Relevant to PR 12257
with drdr
also change two of the failing tests so they pass, but incorrectly and
add a note there to that effect so if someone does fix that eventually
they won't be confused (I hope)