[racket-dev] indentation: the rb tree didn't help, but a hack to stick-to-next-sexp might

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Nov 26 14:56:07 EST 2012

I'd write a helper function like this:

(define (has? str) (equal? str (get-text start-pos (+ start-pos
(string-length str)))))

and call it a bunch (inside an 'or', one branch for each of those
strings that are currently in the second argument to member; or well,
even use a for/or, I guess). Or, if you wanted, you could change your
existing code to push the 'or' inside the 'and' and then drop the

I also don't know why calling forward-match is that expensive.
Probably worth following up a little there, I agree.


On Mon, Nov 26, 2012 at 12:45 PM, Danny Yoo <dyoo at hashcollision.org> wrote:
> On Mon, Nov 26, 2012 at 11:31 AM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
>> That kind of thing makes a lot of sense to me.
>> I'd probably write the code a little bit differently, having a
>> function that takes a string and sees if the text starting at
>> start-pos matches that string instead of having to special case the
>> numbers 1, 2, 3, 5, and 7. This will also let you just put the call to
>> forward-match in the second arm of the 'and', so you can avoid the
>> promise.
> Can you elaborate what you mean?  Do you mean to say to do:
>     (get-text pos (min (last-position) (+ pos K)))
> for sufficiently large enough K, and then do the string matching from there?
> Also do you have an intuition as to why forward-match is expensive?  My
> understanding is that it only tokenizes the portion of the buffer that got
> dirty, so there should be so much reuse of the existing tokens that this
> shouldn't be that bad.  I guess I need to stare at the code some more.

Posted on the dev mailing list.