This is needed for the docker-language-server, which is just submitted a fix for in yegappan/lsp
Having a dockercompose filetype would make the language server configuration much easier
let docker_ls = \ #{name: 'docker-language-server', \ path: 'docker-language-server', \ args: ['start', '--stdio'], \ filetype: ['dockerfile', 'dockercompose'], \ debug: 'v:true' \ }
Not sure if this is the right way though. Syntax should stay yaml. Only the extra filetype is needed to not start the server in all yaml files.
https://github.com/vim/vim/pull/19200
(2 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
so why do we need an extra filetype if the filetype and syntax is effectively yaml?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Because the LSP client starts servers when it detects certain filetypes. If I put 'yaml' as filetype, it would start the language server for all yaml files.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@jclsn pushed 1 commit.
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Well, I am not sure about this. Just because you want to use a specific language server for a common filetype sounds like a bad excuse to duplicate filetype and syntax plugins.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I admit that it's not easy in this case. The file being a yaml, should also still trigger language servers for yaml as well. I think Neovim solved this by having subtypes for filetypes like yaml.dockercompose. This would need a bigger patch of course.
Another way would be to have the lsp client trigger not only on filetypes, but also filenames.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
It's rather Yaml which can be linted by the yaml-language-server with
workspaceConfig: {
yaml: {
"schemas": {
"https://raw.githubusercontent.com/compose-spec/compose-spec/master/schema/compose-spec.json": [
"**/*docker-compose*.yaml",
"**/*docker-compose*.yml",
"**/compose.yaml",
"**/compose.yml"
],
}
}
}
There is in :help 'filetype'
> doc/options.txt (lines 3872-3877)
When a dot appears in the value then this separates two filetype
names, it should therefore not be used for a filetype. Example:
/* vim: set filetype=c.doxygen : */ ~
This will use the "c" filetype first, then the "doxygen" filetype.
This works both for filetype plugins and for syntax files. More than
one dot may appear.
and
au BufNewFile,BufRead docker-compose.yaml,docker-compose.yml set filetype=dockercompose.yaml
with
filetype: ['dockercompose.yaml', 'dockerfile'],
worked, but I found in the end the Yaml LS to understand the YAML file better
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
found in the end the Yaml LS to understand the YAML file better
I'm saddened to hear that as the intent is to provide a great experience for editing Compose files. If you have the time, we would appreciate it if you could let us know of any bugs or missing features with the Compose support in the Docker Language Server. Thank you!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@Konfekt Unfortunately your proposal does not work. The language server starts, but thinks the file is a dockerfile for some reason.
This works as intended:
au BufNewFile,BufRead docker-compose.yaml,docker-compose.yml set filetype=dockercompose au BufNewFile,BufRead docker-compose.yaml,docker-compose.yml set syntax=yaml
let docker_ls = \ #{name: 'docker-language-server', \ path: 'docker-language-server', \ args: ['start', '--stdio'], \ filetype: ['dockerfile', 'dockercompose'], \ }
@rcjsuen I don't think that this is an issue with the server.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I don't think that this is an issue with the server, although triggering the
dockercomposemode ondockercompose.yamloryaml.dockercompose, would be a workaround. I am not sure if a server should work around different clients. The right place to implement this would probably be in the client or by making it possible in vim to assign multiple filetypes to a file.nvim-lsp seems to be able to use a function to send a different filetype to the server.
Unfortunately, the specification doesn't state how to handle these cases to my knowledge. You want to support a generic format like JSON or YAML but you don't want to prematurely activate. We can also see that clients are handling subtypes differently with your example here with Vim doing dockercompose.yaml and Neovim having it be yaml.docker-compose. The specification doesn't talk about subtypes so there is no standardized naming convention from what I can tell.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@rcjsuen Well, it doesn't have to be a concern of the spec. I think the cleanest way would be to add a filetype override in the client. This way it could handle similar cases for other servers as well.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@rcjsuen I am sorry, I apparently mixed up docker LSs here and it detects it fine. What I now find with lsp when changing to invalid syntax, like a missing final colon is
Error detected while processing function <SNR>412_Output_cb[5]..lsp#handlers#ProcessMessages[32]..lsp#handlers#ProcessNotif[63]..<SNR>413_ProcessDiagNotif[2]..lsp#diag#DiagNotification[71]..lsp#diag#ProcessNewDiags[20]..lsp#diag#DiagsRefresh:
line 93:
E474: Invalid argument
which is maybe rather an issue of the used plug-in, the same @jclsn is referring to and working on integrating with docker-language-server
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
I'm confused. @jclsn is using 'docker-language-server' which seems to refer to the Go executable available at https://github.com/docker/docker-language-server whereas indeed I was using https://github.com/rcjsuen/dockerfile-language-server installing docker-langserv`.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
So with
name: 'docker-langserver',
filetype: ['dockerfile', 'dockercompose'],
path: 'docker-langserver', args: ['--stdio'],
the docker-compose.yml is not recognized as such but rather docker file despite @jclsn 's suggestion
au BufNewFile,BufRead docker-compose.yaml,docker-compose.yml set filetype=dockercompose
au BufNewFile,BufRead docker-compose.yaml,docker-compose.yml set syntax=yaml
whereas above errors occur with docker-language-server.
In the end, I found the yaml language server with the corresponding spec to work well enough
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@chrisbra Would you be cool with adding
au BufNewFile,BufRead docker-compose.yaml,docker-compose.yml set filetype=dockercompose.yaml
to https://github.com/vim/vim/blob/master/runtime/filetype.vim?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@Konfekt I found an easy fix yegappan/lsp#746
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
To help clarify:
docker-langserver (in hindsight this was named incorrectly and been named dockerfile-langserver)docker-language-serverThe two language servers address different use cases at the moment.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()