Closed chansey97 closed 2 years ago
What if you use command-line Racket:
> racket.exe E:\work-pl\racket\code\racket-mode-tests\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\main.rkt
Do you see the same truncated path in the error message?
Racket Mode already tries pretty hard to avoid "lossy" paths in error messages, for example trying to "undo" things like <pkgs>/path/to/file.rkt
, trying to change relative paths into absolute/complete paths, and so on. There a few tactics like this in error.rkt.
But the paths starting with ...
I think are elided in a way where it's probably impossible to recover the information?
What if you use command-line Racket:
It returned the truncated path in the error message:
C:\Users\Chansey>racket.exe E:\work-pl\racket\code\racket-mode-tests\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\main.rkt
...de-tests\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\test-long-path.rkt:5:3: bar: unbound identifier
in: bar
location...:
...de-tests\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\xxxxxxxxxxxxx\test-long-path.rkt:5:3
But if I run the main.rkt
in the DrRacket, it can correctly open test-long-path.rkt
, although in DrRacket's REPL there is neither complete path nor truncated path, it is just a test-long-path.rkt:5:3
.
But if I run the main.rkt in the DrRacket, it can correctly open test-long-path.rkt, although in DrRacket's REPL there is neither complete path nor truncated path, it is just a test-long-path.rkt:5:3.
That's interesting. I was leaning toward believing it's not possible for Racket Mode to handle this. But if DrR can do it, I accept the challenge to figure out how. :smile:
Well I'm having trouble reproducing this.
On Linux and using Racket built from source around the time of the 8.4 release, I get the full path:
;
; Welcome to Racket v8.3.0.11 [cs].
;
>
; /var/tmp/test/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/other.rkt:3:15: bar: unbound identifier
; in: bar
; Context (plain; to see better errortrace context, re-run with C-u prefix):
; /home/greg/src/elisp/racket-mode/racket/syntax.rkt:66:0
; /home/greg/src/elisp/racket-mode/racket/syntax.rkt:66:0
>
And the path in the REPL is working link, with a click or moving point there and pressing ENTER.
I'll take another look at this when I have a bit more time to fire up a Windows PC with Racket 8.0 BC, like you're using.
I have another Racket (v8.2 cs) installed in my VMWare (also windows 7). I just tried it and it is no problem. This "... path problem" may have been fixed in v8.2 or later. I may have to upgrade Racket to v8.4 bc.
The test results:
I created a issue in racket repo, https://github.com/racket/racket/issues/4183
Interesting that it's unique to BC.
As I just commented there, I doubt this will change for BC.
As to how DrR handles this when Racket Mode doesn't, maybe it is getting the srcloc
from the exn
, i.e. in a "structured" way, and that is not truncated even on BC. Whereas Racket Mode simply prints the error message as-is, and relies on the Emacs front end doing its usual find-next-error regexp matching.
Possibly I could have Racket Mode do the "structured" thing, and try to replace truncated paths in error message strings...? But that might create its own bugs.
So I just pushed a commit d805a3a to a issue-604
topic branch.
I'm not sure whether I should merge it.
Anyway if you're curious please see the commit message:
Handle truncated error message paths on Racket BC; fixes #604
On Racket BC, error messages can show truncated paths when the paths
are too long. The paths are truncated from the start, and begin with a
"..." prefix.
This doesn't work well with Emacs compilation-mode (to visit error
locations) because the path doesn't exist.
So first of all, adjust the compilation-mode regexp to ignore paths
starting with "...".
Furthermore, on BC have the back end always include the first source
location from exn:srclocs-accessor. Normally we omit this for certain
known exceptions, because it's redundant with the path already
displayed in exn-message; showing it twice is just noise. But accept
the noise on BC since the srcloc path may turn out to be the only
non-truncated, useful path.
Note: This of course is a kludge to stick with the approach of using
Emacs compilation-mode and regexp matching. I think that's acceptable
because Racket CS works fine in this regard and it's the future; also
there is value to going with the Emacs approach. Having said all that,
we could throw this all way and do something from scratch, where we
ignore exn-message for location purposes, and always use the srclocs.
This would be closer IIUC to how Dr Racket handles this.
(Note: I'm not necessarily asking you to try this. If you normally install from MELPA, and don't want to muck around with building Racket Mode from a git branch? That's OK -- don't bother! Consider this commit just me "thinking out loud".)
I merged this to the main branch.
I have two .rkt files in my working directory:
The two files' contain:
test-long-path.rkt
main.rkt
Obviously, executing
main.rkt
will report an error, becausebar
intest-long-path.rkt
is unbound.So in
main.rkt
, executingM-x (racket-run)
, Racket REPL buffer will report:That is nice. However, as you see the error message path is not complete:
instead of
So when I click that link my Emacs cannot successfully open the file. Currently
projectile
will open a dialogue and I have to select a file manually.Note that if the path is not too long, for example, if my working directory is
E:\work-pl\racket\code\racket-mode-tests
, then no problem.