Relative file paths in assists / diagnostics about acme-lsp

[rsc]

Agreed. v0.12.0 does this for the output of things like Ldef and Lrefs, but a few more cases remain to be fixed.

[kmx1]

Maybe another point for consideration:
previously Lrefs used absolute paths, which is less readable but works always when you click it (buttom3 / jump / plumb it).
now relative paths work great when using Lrefs as cmd inside acme (middle click).
Lrefs writes to stdout, acme opens window as "(pwd)+Errors" window.

but when using Lrefs from outside acme, the new behaviour of using relative paths breaks clicking/jumping to the file:line.
I am using 2 keyboard shortcuts (via xbindkeys) for Ldef and Lrefs.
for Lrefs i use a wrapper script to display the results in acme again, like this:
Lrefs | plumb -i -d edit -a 'action=showdata filename=/LSP/References'
now those paths are relative to where i started the xbindkeys cmd (cause of os.Getwd() in PrintLocations)

while testing this i saw that the underlying issue is probably more acme-related.
windows with tag/names like "/LSP/Xyz" dont correctly jump/plumb to relative file paths. (even though when executing "pwd" inside of "/LSP/Diagnostics" it points to the correct directory, but trying to jump/click ./cmd/L/main.go does not work)

so i guess one would need to manually handle the button3 click inside the diagnostics window to make it work :-/
(or mess with plumbing rules vs. pwd? ; or is there way to set the wd of an acme window explicitly?)

i tried hardcoding acme-lsp/internal/lsp/acmelsp/diagnostics.go:96 to the base dir of the repo (where i started acme and acme-lsp, same as when executing pwd inside "/LSP/Diagnostics" window) but the button3/right click on diagnostics messages does not jump/plumb correctly when relative paths are displayed.

I added a new flag for Lrefs (-show) to show the results in a dedicated acme window, and implemented a workaround for PrintLocations to use an empty basedir (so it prints absolute paths).
https://github.com/kmx1/acme-lsp (i also removed deprecated uses of ioutil)

[Superpat]

@kmx1 not a real fix, but remember that you can add $winid to your external scripts by using https://pkg.go.dev/9fans.net/acme-lsp/cmd/acmefocused that should make your L uses have the right path.

[kmx1]

i know.
sorry if i repeat myself, maybe i did get something wrong or miss something.
but to make it more clear what i meant. (and give some more context on how to possibly fix the issue and what to consider when fixing it)

its no fix, actually i reverted (or added the option) to use full-qualified paths.
because the issue was (at least for me) that relative paths dont work in some cases (e.g. acme windows like /LSP/Diagnostics)

you can try that by hardcoding your working-dir in acme-lsp/internal/lsp/acmelsp/diagnostics.go:96
if you do that then /LSP/Diagnostics are displayed as relative paths, but clicking on them (button3 / right-click) does not work (it does not jump to the location, which is the whole point)

this would just display relative paths in /LSP/Diagnostics

as you said, rightly so

either by doing some magic in the Win or setting the base path of the L win to the
workspace.

and i also asked

.. i guess one would need to manually handle the button3 click inside the diagnostics window to make it work :-/
or is there way to set the wd of an acme window explicitly?

one would have to set the /LSP/Diagnostics windows "working directory" somehow, just displaying the relative paths does not work.
(thats probably what you meant also? and this would make the use of relative paths possible for diagnostics)

i dont know how exactly acme handles this, but my guess is that its through the tagline?
although executing (button2-click) pwd inside the /LSP/Diagnostics window gives the right directory. (but thats probably from the "global scope" where acme was started)
but for example ctrl+f file-completion does not work inside the diagnostics window, which also indicates that it does not "look" into the wd.

and i discovered/investigated this because: (kind of related, but not the actual issue)
the previous "fix" of using relative paths when showing L refs did break it for me, because clicking (button3) on those references didnt work anymore.
(btw. calling L refs from outside acme (from a script) wouldnt work at all without the use of acmefocused (but it displays paths relative to the location where it was executed))

if you use L refs as intended, so you execute it from inside acme by clicking on it (button2), then clicking on relative paths with button3 does work, because it opens a acme-window [current working dir]/+Errors

thats why i added the option to use absolute paths again, and while i was at it i added the feature to display references in a dedicated window (with absolute paths), which is my usecase anyway. (instead of using the script mentioned in my last comment)

so "normally" calling L refs from inside acme displays relative paths, button3-click works (cause [wd]/+Errors win)
using my new option L refs -show: always uses absolute paths, and displays references in dedicated acme window (so its nicer to use via a keyboard shortcut)