> On May 30, 2016, at 11:51, Robby Findler <[email protected]> wrote:
>
> If not, can you unpack the example a little bit more below? I don't
> get what you're saying. That, it seems like it should be okay when the
> editor contains:
>
> foobar
>
> and then when the user inserts a slash to produce this:
>
> foo/bar
>
> then that should continue to be okay, as the thing that calls your
> lexer will ask it to start over again at the "f" which should work, as
> long as it returns the entire "foo/bar" as a single lexeme. No?
That assessment is accurate, yes, but it doesn’t cover the common
use-case, which is typing “foo/bar” directly, not typing “foobar” then
inserting a slash within the lexeme. I type this:
foo
^
where the caret represents the cursor. The colorer runs and lexes a
single symbol. Next, I type a single slash:
foo/
^
Now the colorer attempts to lex the slash alone as a new token without
attempting to re-lex “foo”. Since a forward slash is not valid at the
beginning of an identifier, it is colored as an error.
Basically, when I type a forward slash, I want the preceding token to be
re-lexed. I don’t need anything more than that... just a single
character of lookahead is necessary, effectively.
(As an aside: is there any way to get the 'color-lexer property to
affect the interactions panel? It only seems to affect the definitions
panel.)
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
