On 09/12/15 21:21, Robby Findler wrote:
> Some of the mixins in the framework may also be interesting to you.
I just realized that there is also a library called "framework", and
that "the framework" wasn't just referring to racket/gui. Excellent!
Thanks again!
/David
--
You received this mess
I'll give it a shot with this approach then. Thanks!
/David
On 09/12/15 21:21, Robby Findler wrote:
> You'd need to wire up your table with the after-insert and
> after-delete methods, invalidating the appropriate parts. The behavior
> you seem to want below is simple calls into the data/enumerat
You'd need to wire up your table with the after-insert and
after-delete methods, invalidating the appropriate parts. The behavior
you seem to want below is simple calls into the data/enumerate library
and more interesting invalidation is possible if you wish it.
And you want to look at text%, not
Sorry: data/enumerate => data/interval-map.
On Wed, Dec 9, 2015 at 2:21 PM, Robby Findler
wrote:
> You'd need to wire up your table with the after-insert and
> after-delete methods, invalidating the appropriate parts. The behavior
> you seem to want below is simple calls into the data/enumerate l
Thanks for a fast answer, and for the recommendation!
Right, it's all from the compiler. When the user opens a file, it is
normal text; type checking turns it into an angry fruit salad of
semantic information.
Is there a way to automatically keep these things updated as the user
edits the text? I
My experience with this kind of thing suggests that keeping separate
tables on the side that map ranges in the editor to whatever
information you want is simpler and better. (Eg, check syntax.) Check
out data/interval-map.
You don't want to save this information when the user saves, right?
That is
6 matches
Mail list logo
