Okay, not sure how that help, but my messages have probably been too opaque.
I just chatted with Eli on the phone about this and I see two things that DrRacket could provide a) DrRacket could defer to the the language-info stuff for the default settings in the language dialog instead of using the same defaults for every language. That seems pretty straightforward (modulo some possibly tricky UI questions wrt to what happens when you actually set things in the dialog and are editing the #lang line and go back and forth). b) We could invent some kind of API whereby a langauge cna offer information about programs that run (or that don't run) and DrRacket could watch for that information and display it. Some kind of API that would subsume the things that errortrace, the syntax coloring, and other tools currently provide. The latter seems more ambitious but perhaps also more useful as it might be useable by, say, Guillaume with his ideas for colored error messages. Robby On Wed, Sep 14, 2011 at 1:31 PM, Shriram Krishnamurthi <s...@cs.brown.edu> wrote: > A different line of reasoning is this. DrRacket gives the impression > that coverage is a property of the language selected for a buffer. > That's why if I have two tabs, one in *SL and another in #lang racket, > one has coverage and other does not, without my having to ever touch > the Details panel. And this would presumably true when *SL is done as > a #lang instead (which I've repeatedly heard it eventually should be). > > Shriram > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev