I don't want to lay claim to suggesting this technique as I am not sure it is a good idea. I mean to be explaining that, not suggesting you use it in my earlier message. :)
In particular, it means that if you put a syntax error (or malicious code) into the pollen config then you will crash DrRacket itself. DrRacket is intended to be open in some ways to allow customization but the idea is that you customize it with code that crashes only when you have an error and, of course, you intend to fix such errors. So evaluating unknown code as part of syntax coloring seems unwise. Anyway, In DrRacket, files are not always saved before they are run so you cannot reliably get a path. In general, the source name of a syntax object or the object-name of a port doesn't have to be anything in particular and the source location of the file is generally only available when you are compiling the file (and you get it via current-load-relative-directory). I believe it is possible to get the path from that object (try (send x get-filename)) but this is, in some sense, a security hole (because you can invoke other methods of that object to do bad things) and it is certainly not something that DrRacket promises will work (altho backwards compatibility is a strong argument here, sigh). What's wrong with: #lang pollen ☺ to mean to use a smiley instead of ◊? Or if you really find that too long, how about #lang pallen where someone sets up "pallen" once and then uses it everywhere? Robby On Sat, Nov 28, 2015 at 2:01 PM, Matthew Butterick <m...@mbtype.com> wrote: >> But now that looked at the pollen docs, I see the issue. It looks like >> you have to be able to run the config submodule of some program to be >> able to figure out how to syntax color it > > I'm making progress with your suggested technique but hitting a dead end > inside DrRacket. > > Here's what I've found: > > I can customize the lexer if I have the custom @ character. > > I can get my custom @ character if I have the source path. > > Thus, I can customize the lexer from within `get-info` if I can get the > source path from within `get-info`. > > `get-info` receives five arguments, the first of which is "the input port > being read." [1] > > Typically you can use `object-name` on an input port to get the path. [2] > (For instance, this works with ports created with `open-input-file`.) > > So, what I'd hope to do here is extract the path using `(object-name > arg-input-port)`. > > HOWEVER, that doesn't work, because the actual result of `(object-name > arg-input-port)` looks like this: > > #(struct:object:...ivate/get-extend.rkt:133:12 ...) > > Which seems to be something related to drracket:unit:definitions-text% (?? > I'm an idiot about all DrRacket internals) > > Is the path hidden somewhere inside this object? Or is it not recoverable > this way? > > > > > [1] > http://docs.racket-lang.org/reference/Reading.html?q=read-language#%28def._%28%28quote._~23~25kernel%29._read-language%29%29 > > [2] > http://docs.racket-lang.org/reference/inspectors.html?q=object-name#%28def._%28%28quote._~23~25kernel%29._object-name%29%29 > > -- > 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. -- 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.
