I have this program, where I produce a syntax object with source location information. I’d like to click the syntax object in the repl and go to the (already open) file in question. For some reason racket-mode presents me with a file dialog instead of jumping to the file buffer. Any ideas?

Save this as “ref-exp.rkt”. Run it. Click on the syntax object printed in the repl.

#lang racket (require racket/runtime-path) (define (read-string str #:source-name [source-name #f]) (define in (open-input-string str)) (port-count-lines! in) (read-syntax source-name in)) (define-runtime-path this-file "ref-exp.rkt") (read-string "foo" #:source-name this-file)

This prints #<syntax:/var/tmp/ref-exp.rkt:1:0 foo>. You’d expect RETURN to work — at least with point over the /var/tmp/ref-exp.rkt:1:0 portion.

racket-repl-mode uses the standard “next-error” mechanism for this — it sets a buffer-local value for compilation-error-regexp-alist.

Probably racket--compilation-error-regexp-alist needs to be adjusted somehow: https://github.com/greghendershott/racket-mode/blob/master/racket-repl.el#L1030-L1059

I haven’t looked at that in some years so not sure the best way to adjust. Adjust some existing regexp, or, add a new regexp for things that print like racket--compilation-error-regexp-alist?

(Regular expressions for filenames are tricky; what if the filename has perfectly legal characters like a space or a : or even a < or >? IIRC that was the justification (?) for some special cases, here, as opposed to one simple regexp using an arbitrary subset of permitted filename chars. But there’s likely a better idea how to handle all this.)

This pattern matches paths. (list (rx "#<path:" (group-n 1 (+? (not (any ?\>)))) ?\>) #'racket--adjust-group-1 nil nil 0) Maybe (list (rx "#<syntax:" (group-n 1 (+? (not (any ?\>)))) ?\>) #'racket--adjust-group-1 nil nil 0) would work?

I think it needs to stop at the space — e.g. in #<syntax:/var/tmp/ref-exp.rkt:1:0 foo> you’d want /var/tmp/ref-exp.rkt:1:0 not /var/tmp/ref-exp.rkt:1:0 foo.

And if that means it won’t work with filenames having spaces, like my file.rkt, then tough beans?

By “tough beans” I mean it’s acceptable that doesn’t work.

But yes I think it would need to be an additional regexp like the one for path.

Just slightly different than what you proposed.

(Again, there’s probably some smarter, whole other approach. But in terms of extending what’s there now, I think that would be it.)

I’ll make that change. (It’s so small, the overhead of you making a PR etc. is probably not worth it, even if you wanted to.)