As far as I can tell, certain features will work better -- or work at all -- if you arrange to have some of your tool's code running "in" or "alongside" the user's live program.
Otherwise, you can still do some useful things, but they may be limited and/or surprising to the user. For example, for completion: - The candidates could be "a static list of whatever namespace-mapped-symbols returns for #lang racket" -- but (a) that's just one #lang, plus (b) it omits the user module's own defined symbols. - Or you could say, "well, I'll separately require the user's .rkt file and get the symbols", but (a) it will get stale as they edit and worse (b) what if the user's file has a top-level side-effecting expression like `(delete-things-on-disk)`, which you've now run unexpectedly. Instead, you'll probably want to do namespace-mapped-symbols on the namespace corresponding to the program the user is actually running with your tool. That's why I asked if your tool is running the user's program and creating a REPL. You don't necessarily need to start with that approach. But I think someday you'll probably end up there? -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
