improve coverage

[randy3k]

close #195

• completion_reply
• formatting_reply and on_type_formatting_reply
• document_highlight_reply
• hover_reply
• document_link_reply
• document_symbol_reply
• document_color_reply

[renkun-ken]

I'm also interested in writing the test cases. Would you mind I push to this branch directly?

[randy3k]

No problem. I don’t have time to work on it lately.

[renkun-ken]

I tried adding test cases for code section symbols but I'm not sure where to specify client capabilities to make the testing language client to support hierarchicalDocumentSymbolSupport. I tried the following

    client <- language_client()
    client$ClientCapabilities <- list(
        textDocument = list(
            documentSymbol = list(
                hierarchicalDocumentSymbolSupport = TRUE
            )
        )
    )

but it does not seem to work as document_symbol_reply still gets self$ClientCapabilities = NULL.

[randy3k]

The information for ClientCapabilities is sent when language_client is executed. You will need to set ClientCapabilities in the initialize function at

languageserver/R/languageclient.R

Line 20 in 38122ca

self$diagnostics <- collections::Dict()

[randy3k]

My bad, the code was already there

languageserver/R/languageclient.R

Line 104 in 38122ca

self$ClientCapabilities <- capabilities

[renkun-ken]

Thanks! Now new test cases are added to all providers listed.

[randy3k]

Wow, amazing job. With the tests, I guess we are already for the next release.

[renkun-ken]

Test cases for Rmarkdown are divided into handler test scripts and many test cases now have their Rmd version added.

[randy3k]

👍

By the way, I don't understand why travis/push fails but travis/pr does not. Each time it fails at the same test.

[randy3k]

This test fails on travis/push as well as my local computer. I don't understand how we get the indented f and data.

I keep getting

handling request:  textDocument/onTypeFormatting
formatting error: <text>:1:1: unexpected '}'
1: }
    ^

[randy3k]

I also don't understand how github actions tests pass...

[randy3k]

Oh, actually the tests in github actions actually failed, but the error was not correctly thrown.

[randy3k]

8f0bdcf fixed the github actions tests

[renkun-ken]

Just notice that the coverage branch is behind #209. We may rebase to latest master to resolve this?

[randy3k]

I have rebased the branch onto master.

[randy3k]

Good catch @renkun-ken. That also explains why travis/push failed but travis/pr didn't

[randy3k]

Looks like some code is reverted?

language_client <- function(working_dir = getwd(), debug = FALSE, diagnostics = FALSE)

where the capabilities argument is gone?

I guess I have accidentally removed the diff when I was resolving the conflicts.

[randy3k]

Looks like there is a path related issue in Document link provider on Windows.

[renkun-ken]

Can't see the error details except for those expect lines. Do we have a way to know more details?

[randy3k]

Perhaps we could always enable the debug setting https://github.com/REditorSupport/languageserver/blob/master/tests/testthat/helper-utils.R#L14
and dump the file if there are any errors.

[renkun-ken]

Maybe I should install a Windows virtual machine to have a look at this. 😂

[randy3k]

@renkun-ken see if the dumped log for windows would help
https://github.com/REditorSupport/languageserver/actions/runs/41699817

[randy3k]

It doesn't have much information in the log as document_link_reply doesn't have any debug log.

[renkun-ken]

I've set up a Windows virtual box and am looking into this.😂

[renkun-ken]

It looks like there's something inconsistent in slash between path and uris. According to https://microsoft.github.io/language-server-protocol/specifications/specification-current/#uri, uri should only use /. However, under Windows, normalizePath() uses \\ by default while file.path() uses /, and path_to_uri does not ensure / so the resulted URI may become something like

"file:///C:%5CUsers%5CRUNNER~1%5CAppData%5CLocal%5CTemp%5CRtmpakDrf8/working_dir%5CRtmpC2WiHu%5Cfile16401a762f8e.R"

if the input path uses \\ since it is URL encoded.

[renkun-ken]

On my Windows 10 VM, I tried to run the tests but link test always timeout, and the logging added to both document_link_reply and the tests are not triggered at all.

[renkun-ken]

After some painful debugging on Windows 10 VM, the cause is found:

The link test cases write the following code to the temp file:

source('C:\Users\ken\AppData\Local\Temp\Rtmp6HblZk\file1b5448882fd4.R')
source('file1b5448882fd4.R')
source('non_exist_file.R')

The Windows slash in the file makes it not parse-able.