M-x ocp-index-jump-to-definition
UnixJunkie opened this issue · 12 comments
I believe this feature is broken.
ocp-index 1.2.2
ocaml-4.12.0.
emacs 26.3
I was thinking I already reported this bug, but I can't find it back, so maybe I did not report it...
Even if the definition is in the same buffer, I get 'No definition found'.
Thanks for reporting.
First thing is to check that artifacts (.cmt) have been generated since that's where ocp-index gets its location information from.
Then, this feature has been broken for a while with "scoped" libraries using module aliases, which are the default in dune and became the de facto standard: when you attempt to lookup Foo.bar you actually want Libname.Foo.bar, but ocp-index has no easy way to know that.
But good news ! I recently decided to tackle this problem and implemented solutions, although they've not been released yet.
- The last 2 patches on master implement reading of
.merlinfiles, to get info about the modules that should be open that is not available from the pure OCaml artifacts - While I was writing this I released that
.merlinfiles were actually getting deprecated and no longer generated bydune, in favor of a binary protocol... Following the "minimal dependencies, as simple as possible, best-effort" policy ofocp-index, I resorted to PR #150 which actually scrapsdunefiles directly for the information.
Unfortunately I was taken by something else before this got released, but I welcome you to test it (opam pin git+https://github.com/OCamlPro/ocp-index.git#dunefiles) ; in particular I wanted to test with libraries that have an explicit public interface.
Note that you can test directly from the command-line with ocp-index print Foo.bar %l [--context=srcfile.ml]
Please tell me of any issue you encounter, and I'll make sure to release ASAP if you're happy with this version :)
Switching the .merlin files to go to a binary format is a violation of unix programming principles...
What will people do when they don't have the programs (or even have no clue about what program should read this) to decode this binary format?
Sure, I'll test the master.
I tried your dunefiles branch.
Across two files in the same project, ocp-index-jump kind of work (though the cursor
is not jumping into the other buffer, I am pretty sure it was in the past; the buffer was just opened
at the right place).
For a search in the same buffer, I still get 'No definition found'.
As a workaround, I am forced to use merlin-locate from now on.
The project has *.cmt files:
./_build/install/default/lib/orf/orf.cmt
./_build/install/default/lib/orf/orf__RFC.cmt
./_build/install/default/lib/orf/orf__RFR.cmt
./_build/install/default/lib/orf/.private/orf__Utls.cmt
./_build/default/src/.orf.objs/byte/orf__Utls.cmt
./_build/default/src/.orf.objs/byte/orf.cmt
./_build/default/src/.orf.objs/byte/orf__RFC.cmt
./_build/default/src/.orf.objs/byte/orf__RFR.cmt
Switching the .merlin files to go to a binary format is a violation of unix programming principles...
Well that leaves a reason for ocp-index being there ;) — but yes it's making it hard to keep things simple, even just knowing what the paths to idents defined in the current file are required me to write a sexp parser...
To be honest though I don't think they are deprecated from the Merlin side, it's just that dune won't generate them anymore.
the cursor is not jumping into the other buffer, I am pretty sure it was in the past
That part seems like an elisp issue, I'll check but I am already using the same emacs version.
(ocp-index-jump-to-definition-at-point) (C-c C-;) is expected to open the location in the current "window" and jump the cursor right there
(ocp-index-jump-to-definition-at-point-other-window) (C-c ;) is expected to just open the location in another "window". It doesn't put the focus to that window though, I don't think that changed ?
For a search in the same buffer, I still get 'No definition found'.
Ah, I identified that one, should have a fix shortly.
In the past, I was just using ocp-index-jump-to-definition.
I don't know the *-at-point and *-at-point-other-window variants.
From your description (thanks for your responsiveness by the way), I understand
that the previous ocp-index-jump-to-definition was having the behavior
of ocp-index-jump-to-definition-at-point.
But now, it has the behavior of ocp-index-jump-to-definition-at-point-other-window.
These should all be fixed on the dunefiles branch, if you don't mind testing again.
Thanks for reporting!
Yes, I think it is repaired and works as before.
Please notify me when there is a new release.
Thanks a lot for maintaining all those cool tools: ocp-indent, ocp-index, ocp-browser.
Without them, my OCaml programming productivity would be way lower.