Possibility of using markers for `racket-test`?

[yilinwei]

First of all this might be a problem of my workflow rather than anything else, but I found that the racket-test command which runs in the REPL has file positions which are absolute rather than marker-based.

I think this is part of the comint-mode rather than something specific to racket-mode itself, but it would be nice if the link was marker based so that insertions and deletions wouldn't affect the link.

[greghendershott]

racket-repl-mode currently uses compilation-mode for error messages and test failures.

From a quick, shallow look at compile.el, it seems: Initially the locations are absolute positions (raw line and column numbers). Once you actually visit an error location, it does create a marker.

Maybe why it waits is because an Emacs marker requires a buffer, and a buffer might not exist yet for the file?

But since people probably visit locations from first to last, and edits/fixes to one location affect the position of later ones, I imagine this just-in-time "markerization" probably doesn't help very much??

Maybe compilation-mode could create markers more eagerly for more locations -- but I imagine this could be tricky to do well, in a way that doesn't affect speed and memory? (I think people use compilation-mode for big projects that compile with potentially hundreds or thousands of warnings/errors/etc.)

Or maybe it's straightforward and someone has already done this in a package or whatever. If you're able to learn anything about this, please let me know! I'd be happy to add it to the docs, and/or look at adapting Racket Mode if necessary to help make that work.

[greghendershott]

I should clarify: Above I'm talking about error messages and test failures -- anything that matches a few regexps for things like filename:line:col -- that are output in the racket-repl-mode buffer. This includes test failures and runtime errors.

If you are using the racket-xp-mode minor mode to enhance the racket-mode major mode for editing source files, then certain syntax errors (resulting from expand-ing the source) will be caught by drracket/check-syntax. These are reported back to racket-xp-mode, which inserts error annotations as Emacs text properties in the racket-mode edit buffer. For these, if you fix one error, and it (say) adds or deletes a line, any subsequent error annotations move along with the subsequent text, like markers. (Of course, if you have it configured to re-check after you make edits (the default), then a new check-syntax will kick off, anyway, so it's kind of moot unless you prefer manually triggering check-syntax.)

I guess the above might make the situation sound more confusing. Sorry.

I suppose I could look at adding some bespoke replacement for compilation-mode error handling, just for Racket test failures. That feels like probably the wrong thing to do -- cost:benefit, division-of-labor, etc. -- but it would enable handling test failure locations "perfectly" (as well as introducing new problems, realistically).

[yilinwei]

Maybe why it waits is because an Emacs marker requires a buffer, and a buffer might not exist yet for the file?

This is definitely true; Emacs requires the buffer to be open since markers hook into the various insert etc... for it to update the marker on updates (there's also a separate issue of buffers <-> files not having a 1-1 correspondence).

edits/fixes to one location affect the position of later ones, I imagine this just-in-time "markerization" probably doesn't help very much

Yes, this is precisely what I was running into.

At any rate, the problem is not particularly urgent - I just knocked something up to run raco which isn't dependent on compilation-mode for my own workflow.

I'll think about it further; but realistically, without any statistics on how people use racket-mode I'd find it hard to justify any time spent further here.