One problem with commit 299063d7c1
is that the new method for computing the lime green arrows no
longer has the information necessary to distinguish different
identifiers that come from the same require.
This means that, before this commit, mousing over an imported
identifier can be a real interactivity killer. So, instead of
adding more information to distinguish those ids, lets just
try not draw the lime green bubbles for imported identifiers
and see how that feels
that have overlapping ranges in the editor; also got rid of the
id-set stuff
Getting rid of the id-set information that was computed means that now
the mouse-over green bubbles, the "jump to next binding occurrence"/
"jump to bound occurrence" keybindings/menu items, and the renaming
are all being computed from the arrows information as needed, instead
of building up sets as check syntax collects information. This may
change the way Check Syntax behaves in some cases; so far the only
example I've found has been strange and are arguably for the
better. Specifically, this program
(define-syntax-rule (m x) (λ (x) x)) (m z)
no longer draws a green bubble when you mouse over the "z", since
there are no arrows (the only arrow that might have been drawn is
discarded since its start and end points are the same place).
This speeds up the "analyze the expanded code" phase of check syntax,
making it approximately 1.6x faster than before (going from about 31
seconds to about 19 seconds for this phase for the
drracket/private/unit.rkt file (on my machine)). Also, the replay
phase is probably a bit faster now, tho, too: there were 1.07x fewer
elements to process in the trace that comes back from online check
syntax now for that same file (33063 to 30842)
Note that this is only that one phase: this doesn't count the time to
actually expand the program (the dark blue bubble phase) nor the time
to send the results between places, nor the time to replay the
collected information (the light purple bubble phase).
Allow macro writers to put an 'original-for-check-syntax
property on identifiers and, if it is there, don't
insist on syntax-original? holding, just draw arrows anyway
That is, when right-clicking on an imported identifier, if the
file that has that identifier's definition is open and online
check syntax has completed, then offer a "jump to definition" menu
item that just jumps there with the already computed informtion.
If the file isn't open or online check syntax hasn't completed,
instead offer just to go to the file, without jumping to the definition
also
- things should generally work slightly better with submodules
- jumping to identifiers should do a better job with scrolling,
specifically it should scroll so the jumped-to identifier is
about 20% from the top of the window (unless it was already visible,
in which case no scrolling should occur)
- lets other events be handled based on how long it has been
replaying the current trace (instead of based on the number of
pieces in the trace that have been seen)
- breaks up the syncheck:add-rename-menu pieces of the trace to
be more granular (to make the previous point work better)
This should make DrRacket more responsive when the trace is being
replayed
raw-module-path inside of a phaseless-spec (see
the #%require docs for the description of these).
Also, Rackety
in conjunction with commit 9047427 (and an earlier
commit in those files/dirs), this commit:
closes PR 7815
closes PR 10455
closes PR 10788
(the way things currently stand, check syntax needs more information
from the fully expanded form, but at least now it has a better chance
to actually use that information, if it were there ...)
related to PR 7815
related to PR 10455
related to PR 10788
to syntax-original? identifiers
It used to pay attention to non-original identifiers if they
were in the disappeared-use or disappeared-binding
properties, but now that the 'syntax' macro is fixed
(commit f28e8a0) it can ignore all non-original identifiers
corner of the definitions window, based on the information that check
syntax computes
This commit contains two separate changes to make this work:
- adding a new renderer, based on the text renderer, that
pulls out the contents of the blue boxes and saves them
in the doc/ directories (specifically in the files named
contract-blueboxes.rktd)
- extend check syntax to use and display the information
build by the new renderer
Specifically, move the syntax-original? checks to the point
where objects are inserted into the tables (it seemed to mostly
be happening there already, but now remove the checks on the
references)
Specifically:
- make predicate symbols and variables be original (and,
in the former case, have srclocs)
- remove the originality in the quoted syntax constants
that the expansion introduces
I think there is probably something better that should be done
with those introduced syntax constants, possibly relacing
them with #f, or possibly replacing them with source location
lists, but I'm not sure how they are used, so I've just left
them in there.
(Also, very minor Rackety in check syntax)
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
being edited in DrRacket (via places)
Added an API to let tools have access to that
information (and compute more stuff)
Used that to make an online version of Check Syntax
which led to a separately callable Check Syntax API.
Specifically, it finds all variables that match the one being
renamed in the fully expanded program, as well as all variables
that have the same source locations of any of those (etc).
