Incorrectly prepends module name for opened modules

[whitequark]

sublime-ocp-index shouldn't prepend module name by itself if the user didn't enter it.

Steps to reproduce:

1. Open a new OCaml file
2. Type read_flo<Enter>
3. sublime-ocp-index substitutes it to Pervasives.read_float

Expected behavior: substitution to read_float

/cc @TheSpyder

[TheSpyder]

I'm a committer now so you don't need to CC me ;)

This is basically the reverse of #7. I've noticed it; sometimes we "use complete everything" incorrectly. I wonder if it's when completion is on a function inside a module.

I wish sublime had better documentation for this :)

[whitequark]

by the way, I just updated ocp-index and woohoo completion for all packages! it's awesome.

[whitequark]

I think to fix this issue we just need to strip the module prefix for all modules opened in the current file. (Somehow)

[TheSpyder]

So you never used the option I added before ocp-index was fixed? ;)

We may be able to just strip the module prefix depending on the number of underscores in the match, or the presence of a dot in the search string... it sounds horrific.

I haven't really come up with good examples of "works" and "doesn't work", which would be a good place to start.

[AltGr]

Note that the latest ocp-index stores both the short and full path, which is exactly what you would need here ; the command-line options are somewhat limited there at the moment though, but LibIndex.Format.path ~short:true returns what I think you want.

We have a new ocp-index print that allows to specify a custom format -- I need to add a format-string for the short-path though, seems I overlooked it. I'll also add a format string option to the complete command, so that you get all the flexibility. Hopefully this will make integration much easier.

Regretably, at the moment the functionality is present but it seems the only way to access it is through the --sexp option (which could be removed when I plug the formats in, because it'll become equivalent to --format '("%n" (:path . "%p") (:type . "%t") (:kind . "%k"))' -- assuming %n is the short-path, it's just the name at the moment)

I'm very glad you find ocp-index useful. Hope the above makes sense and will eventually solve your integration issues ?

On an unrelated matter, I can't live anymore without the locate-uses function I plugged in emacs, which simply opens a grep buffer with the results of ocp-grep $(ocp-index print <ident-under-point> "%p"). You may want to bind that too :)

[TheSpyder]

Ooh locate-uses uses sounds interesting. Easy to display in sublime, too. I'm not sure how it fits into an "autocomplete" plugin though ;)

After that, I'd only miss one other feature of IDEs: open the definition of the function at the cursor.

[whitequark]

@TheSpyder Try Shift+Ctrl+R in Sublime 3. There's probably some shorter way to invoke it, too.

@AltGr Custom formats sound marvelous! I don't quite have time to work on sublime-ocp-index right now, but I'll keep it in mind. Perhaps you could get the CLI options in ocp-index meanwhile?

[AltGr]

Just done it, as it was basically just plugging some missing wires. It's on trunk :)

After that, I'd only miss one other feature of IDEs: open the definition of the function at the cursor.

ocp-index locate !

[AltGr]

Format for the "qualified ident" (read_float, List.map unless List is opened and you just wrote map) is "%q"

[TheSpyder]

@whitequark that seems to be just listing all the symbols in a project. I want to put my cursor on a function name, hit shift+enter (In the same context we now have alt+a for type inspection), and see that function. For bonus points, be able to do it on standard library functions (unlikely, but you never know).

Although I've just discovered cmd+alt+down (probably ctrl+alt+down for you) which runs it on the symbol under the cursor. This comes close, but is still just plain text searching.

ocp-index locate !

So, when are we renaming this to the "Sublime OCP IDE" plugin? I no longer think I need to spend hours figuring out how to maintain a background process like vim/emacs :)

I should have some time to work on these things over the weekend... maybe.

[whitequark]

@TheSpyder any chance you could have some time this weekend? This bug is a bit annoying :)

[TheSpyder]

Yeah, I should be able to make time. Easter is a long weekend in Australia :)

On Fri, Apr 18, 2014 at 10:01 PM, Peter Zotov [email protected]
wrote:

@TheSpyder any chance you could have some time this weekend? This bug is a bit annoying :)

Reply to this email directly or view it on GitHub:
#8 (comment)

[TheSpyder]

@AltGr I'm playing with ocp-index locate and the first thing I tried it on was the entry point to a menhir generated parser... it pointed me at the generated .ml file instead of the .mly, which doesn't exist in my source folder - only in the build output. I can understand why, but it was surprising :)

Sublime has an "open file" command flag that knows how to parse the file:row:col format, so it all works brilliantly.

@whitequark any preference for what keyboard shortcut to use for open definition? Sublime's default is f12 or cmd+option+down.

I haven't had a chance to look at qualified indent yet.

[whitequark]

@TheSpyder How about overriding Sublime's default and falling back to it for non-OCaml projects?

Or then F9 (Sort Lines) sounds quite useless for source code.

[TheSpyder]

That's exactly what I'm working on ;)

It was a bit tricky because goto_definition is a window command, and there isn't a way to say "abandon default command execution", but I've got something that works (although ocp-index only seems to return results in my test code, not my source code, but that's a separate issue).

I'll make a branch and push up what I have so far.

[AltGr]

@TheSpyder ocp-index returns the file positions it can find in ocaml object files... I am a bit surprised that menhir would'nt add #line directives that would then make the compiler correctly report the mly locations though.

Otherwise, that's great to hear !

ocp-index heuristic for finding the project root is a bit tricky but intended to 'just work', so don't hesitate to report cases where it doesn't.

[TheSpyder]

It looks like menhir does that when I run it myself, but not when run via ocamlbuild which specifies ocamlc manually. I wonder if that's a bug in menhir or ocamlbuild :)

I'll log an issue on the ocp-index repo when I narrow down more detail about where locate works and where it doesn't.

[AltGr]

OCP_DEBUG=1 will tell you more about the files which are read

[TheSpyder]

ah, of course... I used that a lot writing the type inspection. How could I forget!

It's happening because my last build failed and there was no cmt file for the module I was inspecting. /headdesk

[TheSpyder]

OK, so now that my project is in a good state, it's the use of menhir --infer (which ocamlbuild forces on) that disables menhir line numbers. Might have to report that one to menhir (it could be by design though).

And hey, it looks like a recent change to ocp-index negated the need for the --build option I was using (via the sublime_ocp_index_build_dir setting I added). With it locate returns the .ml file in my build folder, instead of the source folder, but without it ocp-index is working fine (it didn't used to).

[TheSpyder]

@AltGr your "locate uses" command using ocp-grep looks easy to run, but I'll need to look up how to display a list of files in Sublime (I think it's pretty easy, I've seen other plugins do it).

In the meantime, can you add a way to tell it that my ocamlbuild output folder is not _build? I get duplicate results from my build folder that magically vanish when I rename the folder to _build ;)

Getting back onto the point of this issue, completion, I can't seem to pass a format string to the complete command in 1.0.2. Has that not been released yet?

[AltGr]

Ah, you mean in ocp-grep ? Indeed I should add a --exclude option, for now just a few hardcoded names are excluded (like _build or .git).

The latest features in ocp-index haven't been released yet, i'll do that as soon as I get time !

[TheSpyder]

Fair enough. No rush, just checking :)

[TheSpyder]

So you're just going with breaking #7 again?

I guess that's a less common and this will do until ocp-index is updated :)

[whitequark]

@TheSpyder Hmm, odd. Block.b (shows capability_of_bytes) Enter Block.capability_of_bytes.

Does that mean I also accidentally fixed #7?

[TheSpyder]

I haven't been keeping up with the changes you've made in the last couple of days :)

Right now I'm just getting ocp-index errors because the current release doesn't have a --format option on completion :)

[whitequark]

@TheSpyder Oh, it appears that while I've been solving my problems with compiling on trunk, I've also sidestepped the unreleased --format issue...