Milestone 1

[Prince781]

Implemented member access completion (edit) and basically everything else from Milestone 1. This requires some changes in valac to work properly, which I have yet to complete.

[benwaffle]

I haven't read the code in depth, but some general thoughts

1. can we get the necessary valac changes into master? is it already there? (there was one commit that allowed the compiler to continue despite failures)
2. Let's not keep any logic in protocol.vala. I want to keep the models untouched. This will also help with Autogenerate LSP definitions #27 later.
3. I'm going to split up main.vala into multiple files (Waiting for this PR to merge because it's large). Can you put the completion stuff in completion.vala?

[Prince781]

1. There are more changes needed in valac. There is a feature to continue semantic analysis after syntax failures, but the grammar needs to be changed to facilitate this. I haven't worked on this yet.
2. Seeing as Autogenerate LSP definitions #27 is very far off, for simplicity I'd like to keep it (there's very little logic - most is just setting default values). We can change this later.
3. Sure, but I'd prefer to do that after the merge.

[benwaffle]

1. what are these grammar changes
2. ill do it once this is merged
3. Ok

[Prince781]

The latest commit fails because I'm relying on my version of Vala with LSP mode changes.

[Prince781]

Here's basically the status of where I am on this PR w.r.t. completion:

Namespace.$                             (done)
    - complete member if we're not completing a class

Expression.$                            (done)
    - complete member of Expression

Function($                              (signature help)
    - complete local/global variables in 0'th position of function argument

Function(Expression,$                   (signature help)
    - complete in i'th position of function argument

new [ObjectCreationExpression] ([arguments]) { $
    - look for members of [Object]

When every case is marked (done) or something like (signature help) and my commits to vala are accepted, then this PR is ready.

edit: These other cases are context-sensitive so they'll be reserved for Milestone 2:

Namespace.[member] = $
Expression.[member] = $
    - look for local variables in scope with same type

Expression.[member] = new $
    - look for constructors with same type

[Prince781]

I also added some basic hover support, which will need to be improved later in a different PR. There are also some performance issues I'll need to work on in another PR.

[Prince781]

It's actually a bit hard to do completion for symbol<$ because of ambiguity with binary expressions with '<'. I'll leave that for a later date.

[Prince781]

How to test out this branch in three five easy steps:

1. clone https://gitlab.gnome.org/Prince781/vala
2. switch to wip/lsp, build it, and install in /usr/local (this is by default, so you won't have to configure anything, just run ./autogen.sh and make)
3. in vala-language-server, run rm -rf build/ and then configure the meson build with the libvala in /usr/local as follows:

env PKG_CONFIG_PATH="/usr/local/lib/pkgconfig:/usr/lib/pkgconfig" meson build

4. Build it with ninja -C build and create a wrapper in the main directory called vls-wrapper:

#!/bin/sh

export LD_LIBRARY_PATH=/usr/local/lib
exec $(dirname $0)/build/vala-language-server "$@"

5. Back in vala-code, change line 21 in client.ts to:

let serverModule = context.asAbsolutePath(path.join('vala-language-server', 'vls-wrapper'/*'build', 'vala-language-server'*/))

[Prince781]

Obviously I've taken some inspiration from philippejer in the latest commit.

[Prince781]

I've left dependency resolution in the build system rewrite for another time.

[Prince781]

Yes. Just fyi, I mentioned this once already, but I really just took this bit from @philippejer's repo, since it was already implemented well. On Jan 9, 2020 1:15 AM, gavr123456789 <notifications@github.com> wrote:@gavr123456789 commented on this pull request. In main.vala:

HashTable<string, NotificationHandler> notif_handlers;

HashTable<string, CallHandler> call_handlers; InitializeParams init_params; + const uint check_update_context_period_ms = 200; + const int64 update_context_delay_inc_us = check_update_context_period_ms * 50; + const int64 update_context_delay_max_us = 1000 * 1000; + const uint wait_for_context_update_delay_ms = 500; Do I understand correctly that now this is now done as in Gtk.SearchEntry: "To make filtering appear more reactive, it is a good idea to not react to every change in the entry text immediately, but only after a short delay. To support this, GtkSearchEntry emits the “search-changed” signal which can be used instead of the “changed” signal." —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[Prince781]

It looks like this is broken in libvala-0.48. I'll see what I can do later.

[Prince781]

I will merge this commit only after the language server changes in upstream Vala have been finalized.

[benwaffle]

Lit