Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect "Closes ..." returned by textDocument/hover #400

Closed
non-Jedi opened this issue Oct 14, 2019 · 1 comment
Closed

Incorrect "Closes ..." returned by textDocument/hover #400

non-Jedi opened this issue Oct 14, 2019 · 1 comment
Assignees
Labels
Milestone

Comments

@non-Jedi
Copy link
Member

non-Jedi commented Oct 14, 2019

Save the following in a file:

import Base: size

abstract type Container end

size(a::Container) = size(a.content)

When associating a language server with the file and hovering over the
first character in line 5 (the "s" in "size"), one sees the following:

client-request (id:21) Mon Oct 14 16:13:13 2019:
(:jsonrpc "2.0" :id 21 :method "textDocument/hover" :params
          (:textDocument
           (:uri "file:///home/adam/tmp/test.jl")
           :position
           (:line 4 :character 0)))

server-reply (id:21) Mon Oct 14 16:13:13 2019:
(:id 21 :jsonrpc "2.0" :result
     (:contents
      [(:language "julia" :value "Closes Abstract expression.")]))

This seems like an off-by-one error possibly caused by using 1-based indexing instead of 0. Note that the language-server specification says that offset (0-based) should be used for "line" and "character":

A position inside a document (see Position definition below) is expressed as a zero-based line and character offset. The offsets are based on a UTF-16 string representation. So a string of the form a𐐀b the character offset of the character a is 0, the character offset of 𐐀 is 1 and the character offset of b is 3 since 𐐀 is represented using two code units in UTF-16.

#394 is related but this is slightly different since a hover is being returned for two lines above at the end of the line rather than no hover being returned at all.

@ZacLN
Copy link
Contributor

ZacLN commented Dec 3, 2019

This is a result of out considering white space as being associated with the preceding token rather than an off by one error. In the above example we'd consider the position (4,0) to be that between the second \n and s below and the hover request handler associates it with the token to the left (including the trailing white space). It probably should ignore the white space aspect of the token (it's a trivial change, #426).

...end\n\nsize(...
          ^

@ZacLN ZacLN closed this as completed Dec 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants