> 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).
Fair enough. I know how to deal with unsaved files. It's more a question of whether the path info is available by reasonable means. I will take the answer as no. > What's wrong with: > > #lang pollen ☺ > > to mean to use a smiley instead of ◊? Nothing in principle. In practice, the incremental cost (= introducing a configuration inconsistency) may not be worth the incremental value (= minor enhancement of DrRacket syntax coloring). > Or if you really find that too > long, how about #lang pallen where someone sets up "pallen" once and > then uses it everywhere? Part of what I'm experimenting with is how to expose configuration options for a #lang without requiring users to climb an additional learning curve (= of making their own sub-#lang). Easy things should be easy. > > 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.
