Offset seems off by 3

[seanfarley]

I'm hitting an odd error with the offset being off by the beginning of the word. For instance,

import AVFoundation|
                   ^

is reported as

[company-sourcekit] prefix: `AVFoundation`, file: /var/folders/8b/5vz4t2yd5x7116mq280krw4r0000gn/T/sourcekitten56925ebh, offset: 7

It seems that it is subtracting the prefix? I wrote a tiny lisp function to test this:

(defun foo-bar (&optional prefix)
  (interactive)
  (message "FOOBAR: %d" (- (point) (length prefix) (point-min))))

And it reports the position as FOOBAR: 19. This causes problems for things such as:

let r = GCR|
           ^

because this will sent the X-Offset as 29 (as my other issue shows) causing a 400k+ buffer to fill up with JSON.

Should the length of the prefix be added to current offset (or rather not subtracted as is currently)?

[nathankot]

From what I remember, there are two reasons for subtracting the prefix:

• Edit: actually this is more of a reason why we need to compute a prefix rather than why we need to subtract the prefix offset. company-mode requires a prefix if we want to use it's internal caching mechanism, it's possible to not compute a prefix and just send every completion request to sourcekittend but it makes it slower. Excerpts from the doc:

‘prefix’: The backend should return the text to be completed. It must be text immediately before point. Returning nil from this command passes control to the next backend. The function should return ‘stop’ if it should complete but cannot (e.g. if it is in the middle of a string). Instead of a string, the backend may return a cons (PREFIX . LENGTH) where LENGTH is a number used in place of PREFIX’s length when comparing against ‘company-minimum-prefix-length’. LENGTH can also be just t, and in the latter case the test automatically succeeds.

Non-prefix matches are also supported (candidates that don’t start with the prefix, but match it in some backend-defined way). Backends that use this feature must disable cache (return t to ‘no-cache’) and might also want to respond to ‘match’.

• Sourcekit didn't support completions that began halfway in a keyword until 7.3 (I think,) this is the relevant text from the 7.3 changelog:

Code completion enhancements in the Xcode source editor help you enter symbols, methods, and property names with less typing. Code completion now provides more intelligent suggestions by using partial matches and the first letter of each word, in addition to prefix matching.

---

Could you try removing (length prefix) and see if it works better? e.g

(defun foo-bar (&optional prefix)
  (interactive)
  (message "FOOBAR: %d" (- (point) (point-min))))

I just tried this myself and it doesn't seem to have any negative impact, but completions like CGRe| still don't work:

[seanfarley]

I agree about computing a prefix (I do the same in one of my company backends) but I'm unsure about the subtraction of the offset.

After playing around with just the command line (leaving emacs out of the equation) I can't seem to get any partial word to give back a completion. The only thing that completes is when the offset is set to after the import word or the let = (in my demo project).

[nathankot]

@seanfarley sorry for the late response!

I've been playing around with different prefixes and this is what I have so far: cb5868d Its on the fix-prefix branch, if you try it out let me know how it goes :)

I've added some line notes on issues with this setup. It avoids the 400k+ problem, but is unable to do mid-symbol completions.

[seanfarley]

Cool! I'll try to test it out this week when I get a little more time.

[seanfarley]

Finally got some time today to test this out and it works exactly as you said. I really like that emacs doesn't grind to a halt with the 450k+ results 😄

[nathankot]

Hehe nice! I will get this released.