[completion] can --display Foo.hx@0 work together with -D display-stdin?

[grepsuzette]

Trying to use #5120 and I have a question (asking because I didn't understand the outcome in #7917, and also there is not much nothing in the completion doc about -D display-stdin).

Using haxe 4.0.5:

• haxe --wait 10000 in one window
• open a socket to localhost:10000 from the vim editor,
• send the hxml params with -D display-stdin and --display MyFile.hx@0 , 0x01, then send to the same socket the file content with a | char as in myVar.| to mark completion point (i.e. it's not using offset), and finally 0x00.

On the socket, I receive an Error: No completion point was found. Even though I can see one sent (myVar.|)

Are both features (-D display-stdin and --display <file>@0 with a | character to mark the completion point) supposed to work together right now? Otherwise I probably overlooked something.

[Gama11]

I think | isn't really supported anymore regardless of whether or not display-stdin is used. It was always just meant as a debugging feature anyway and would fail to work in places where | would otherwise be valid syntax.

[grepsuzette]

But it's still mentionned in the doc : https://haxe.org/manual/cr-completion-overview.html

The position-argument can be set to 0 if the file in question contains a pipeline |
character at the position of interest. This is very useful for demonstration and
testing as it allows us to ignore the byte-counting process a real IDE would have to do.
The examples in this section are making use of this feature.
Note that this only works in places where | is not valid syntax otherwise,
e.g. after dots (.|) and opening parentheses ((|).

OTOH that would explain my problem ^^.

It's also mentionned here https://haxe.org/manual/cr-completion-top-level.html

Top-level completion displays all identifiers which the Haxe Compiler knows about at a given
compilation position. This is the only completion method for which we need a real position argument > in order to demonstrate its effect:

Native functions in vim seem to count the offset with wide UTF-8 characters differently than in Haxe (the completion happens somewhere else, often somewhere invalid if you use unicode characters in the source code, which I love to do, this also breaks the vaxe plugin when you use wide chars in the code), so I thought of using the |. But if it's out of fashion I will have to find another way. But... I liked the idea, it's too bad if it's gone.

[Gama11]

Btw, have you considered using haxe-language-server with one of the myriad languageclient plugins that exist for vim rather than implementing things from scratch (vshaxe/vshaxe#328 (comment))?

Even --display Foo.hx@position is basically legacy at this point, since there's now a JSON-RPC based display API.

[grepsuzette]

This was going to be a mere patch of Vaxe, so I would not have to process the response. But if it's legacy already, I'm glad you told me.

I was not aware of an haxe-language-server, JSON-RPC based display API. I will start reading the url, even though what is discussed there is alien to me at first glance. Thanks! (is there a manual page, or PR, or release note, some more or less official reference to help me catch up? Even if hopefully I can find one of those plugins I hate to use something blindly)

[Gama11]

@jdonaldson has actually done some work on integrating haxe-language-server into vaxe: https://github.com/jdonaldson/vaxe/tree/neovaxe

[grepsuzette]

Ok what i was missing is that Microsoft have defined a Langage Server Protocol, and that a Haxe implementation is shipped with haxe extension for VSCode... Hence the name haxe-language-server. Information is quite scattered, and since I use vim and not neovim it might add to my pain haha. Will post if I find anything usable amongst the myriads of urls there seems to be.

[grepsuzette]

coc-nvim actually works on stock vim8.
Such a beast. Took me a few hours to read the doc and start trying to tinker with it.
Followed the thread you linked and the config provided by @vushu.
Wow... Okay, this is laughably cool haha!
Now I understand why you said above method was already legacy, the experience simply has nothing to do with previous things I used until now.

Thanks for all the hard work here!

[Gama11]

Glald to hear it's working so well! :) I guess this can be closed then.