Closed SevereOverfl0w closed 2 years ago
I need to know what the URLs look like on Windows. I would assume zipfile://C:/...
but you know what happens when you assume...
Fixed in #398. I guess I'll rely on the Windows assumption until proven otherwise.
I think there might still be a few places that changes are needed, e.g. s:Tag references zipfile:, so does s:Find, and s:buffer_absolute.
Can you test the zipfile-url
branch?
Can confirm ctrl+D+[
is back to working after switching to zipfile-url branch. Not sure if there are other ways I should test it out. Thanks for fixing this is in no time!
:Stacktrace
is the number one thing I'd like to see tested. cider-nrepl
busted on my machine and I don't have time to figure out why.
Ok, not sure if I'm testing correctly. I took a dependent library, had a look for a function that could throw exception and triggered it. The :Stacktrace
shows where it's coming from, but the frame line doesn't start with zipfile:
which I suppose should trigger the navigation into the jar.
Try actually navigating to it and see where you end up.
In which I discovered that this mapping " map <Enter> :nohlsearch<Enter>
in my vimrc is preventing me to use the quickfix properly. Commented out. So when I hit enter it shows:
jar:file:/home/ren/.m2/repository/metosin/potpuri/0.5.3/potpuri-0.5.3.jar!/potpuri/core.cljc
Which is where it should jump, but it doesn't, empty screen.
Yep, I screwed it up. I squashed a fix in; try again.
Nice, jumping good now. Anywhere else to test?
Try gf
on a namespace and <C-]>
aka jump to tag on a symbol. They're probably fine but may as well double check.
Yep, both seems to be working! :tada:
In https://github.com/vim/vim/commit/519cc559b08b800edc429688aece7ad6a00d41eb# the zipfile plugin was updated, and now uses
zipfile://
as the file path, rather thanzipfile:
(so the path to /tmp/foo.jar would be zipfile:///tmp/foo.jar).Fireplace generates the older format, which means jump to source is broken.