Closed grepsuzette closed 4 years ago
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.
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.
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 (https://github.com/vshaxe/vshaxe/issues/328#issuecomment-472086272)?
Even --display Foo.hx@position
is basically legacy at this point, since there's now a JSON-RPC based display API.
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)
@jdonaldson has actually done some work on integrating haxe-language-server into vaxe: https://github.com/jdonaldson/vaxe/tree/neovaxe
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.
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!
Glald to hear it's working so well! :) I guess this can be closed then.
Trying to use https://github.com/HaxeFoundation/haxe/pull/5120 and I have a question (asking because I didn't understand the outcome in #7917, and also there is
not muchnothing in the completion doc about-D display-stdin
).Using haxe 4.0.5:
haxe --wait 10000
in one windowlocalhost:10000
from the vim editor,-D display-stdin
and--display MyFile.hx@0
,0x01
, then send to the same socket the file content with a|
char as inmyVar.|
to mark completion point (i.e. it's not using offset), and finally0x00
.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.