Feel free to use it experimentally.

Completions should be working now. You should see completions in your active workspace, which is the value of `cody–workspace-root’, typically the repo root for that workspace.

Cody currently supports one active workspace at a time. Files in the currently active workspace have a color Cody icon, and others are monochrome. You can also see the active workspace in `M-x cody-dashboard’.

Cody uses a distributed copy of the Cody agent as compressed javascript, but you can override this by specifying the location of the agent binary, e.g.:

(setq cody--agent-binary "/path/to/eg/cody/agent/dist/agent-macos-arm64")

Add to your ~/.authinfo.gpg something that looks like

machine `cody--sourcegraph-host' login apikey password sgp_SECRET

You can bypass this check by setting your access token directly, though this is less secure

(setq cody--access-token "sgp_etc")

To try it out, evaluate the buffer and `M-x cody-login`.

You can create a Sourcegraph access token at https://sourcegraph.com/users/yourname/settings/tokens.

;; Tell `use-package' where to find your clone of `cody.el'.
(add-to-list 'load-path (expand-file-name "~/my/path/to/emacs-cody"))

(use-package cody
  :commands (cody-login cody-restart cody-chat cody-mode)
  ;; Some common key bindings.
  :bind (("C-M-n" . cody-completion-cycle-next-key-dispatch)
         ("C-M-p" . cody-completion-cycle-prev-key-dispatch)
         ("M-TAB" . cody-completion-accept-key-dispatch)
         ("C-M-g" . cody-quit-key-dispatch))
  :init
  (setq cody--sourcegraph-host "sourcegraph.com") ; for clarity; this is the default.
  (setq cody--access-token "sgp_asldkfjalsdkjfaslkdjfalsdkfj")
  (setopt cody-workspace-root "/your/path/to/some/project/dir") ; optional
  :config
  (defalias 'cody-start 'cody-login))

Autocompletion is the main use case for now. Chat is just a stub.

• `M-x cody-login` will start Cody up and apply it to applicable buffers.
• `M-x cody-logout` shuts Cody down.
• `M-x cody-mode` toggles Cody on and off in a given buffer.

We have an experimental backend for gptel.

(require 'gptel-cody)

;; Set Cody as the default backend
(setq gptel-backend
      (gptel-make-cody "Cody"
        :key "sgp_ADD_DOTCOM_TOKEN_HERE"))

;; Or use against enterprise instance
(setq gptel-backend
      (gptel-make-cody "Cody"
        :host "sourcegraph.sourcegraph.com"
        :key "sgp_TOKEN_HERE"))

;; Specify models to avoid request against server to fetch list of models
(setq gptel-backend (gptel-make-cody "Cody"
                    :host "sourcegraph.sourcegraph.com"
                    :key "sgp_TOKEN_HERE"
                    :models '("anthropic::2023-06-01::claude-3.5-sonnet")))

You can have multiple cody accounts by giving the backends different names. IE replace the word “Cody” with the name you want to refer to it by.

Right now I think I am just hardcoding it at request time.

As follow-up need to handle errors querying the backend to find out which models are allowed by the logged in user.

I think we have this sort of functionality, but I do see a lot of hardcoding in the cody client.

This should be possible, since I just tried with a random model on my free account and got this response from the backend

the requested chat model is not available ("openai/gpt-4o", onProTier=false, hasFeatureFlags=false)

query ViewerPrompts($query: String!) {
    prompts(query: $query, first: 100, viewerIsAffiliated: true, orderBy: PROMPT_NAME_WITH_OWNER) {
        nodes {
            id
            name
            nameWithOwner
            owner {
                namespaceName
            }
            description
            draft
            definition {
                text
            }
            url
        }
        totalCount
        pageInfo {
            hasNextPage
            endCursor
        }
    }
}

I don’t know if this is a bug in gptel or strictness on Cody’s side. But I set a directive without having inline prose, and we ended up having a final bit of the transcript being

{
  "speaker": "human",
  "text": ""
}

This lead to a failure from the server.

Maybe also parse vscode state? Right now it is all in a sqlite file.

context-discussions.md