Plugin incorrectly assumes that it is running in an environment where a "browser" is available, making enrollment impossible

[whisperity]

It seems that the GitHub Copilot Vim plug-in was developed with the assumption that it is running in a fully graphical desktop environment where tools such as "a browser" and xdg-open are available, making the use of the plug-in impossible unless these (otherwise not mentioned in the README!) features are satisfied.

System version(s):

❯ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.3 LTS
Release:        24.04
Codename:       noble

❯ nvim -v
NVIM v0.9.5
Build type: Release
LuaJIT 2.1.1703358377

 77 ──────────────────────────────────────────────────────────────────────────────
 78 vim.lsp: require("vim.lsp.health").check()
 79
 80 - LSP log level : WARN
 81 - Log path: /home/whisperity/.local/state/nvim/lsp.log
 82 - Log size: 4 KB
 83
 84 vim.lsp: Active Clients
 85 - GitHub Copilot (id=1, root_dir=nil)

After installing the plug-in and executing :Copilot setup, the following happens:

Error detected while processing function copilot#Command[33]..function copilot#Command[25]..17[35]..<SNR>174_RequestWait:
line    2:
Error executing vim.schedule lua callback: /usr/share/nvim/runtime/lua/vim/lsp.lua:76: Vim:LSP[GitHub Copilot]: Error SERVER_REQUEST_HANDLER_ERROR: "Vim:E475: Invalid value for argument cmd:
'xdg-open' is not executable"
stack traceback:
        [C]: in function 'nvim_command'
        /usr/share/nvim/runtime/lua/vim/lsp.lua:76: in function 'err_message'
        /usr/share/nvim/runtime/lua/vim/lsp.lua:1086: in function 'cb'
        vim/_editor.lua:263: in function <vim/_editor.lua:262>
Press ENTER or type command to continue

Other tools, such as the gh cli shows an alternate flow to authenticate:

! First copy your one-time code: XXXX-YYYY
Press Enter to open https://github.com/login/device in your browser...

Opening this page and pasting the token and then running :Copilot status thankfully reports Ready, so the solution here would be to detect the failure of calling xdg-open or the browser and then creating an interactive message that leads the developer to open the browser on whatever other device they have and do the authentication flow there.