Justin M. Keyes

> `gs` for `vim.lsp.buf.document_symbol()` That is already mapped to `gO`, which is the intended purpose of `gO` for all filetypes. > `gS` for `vim.lsp.buf.workspace_symbol()` That likely fits in `gr/`, but...

> How do keymaps help with discoverability? Weakly, via `:map gq` and the `lsp-defaults` docs. And via "which-key" style plugins. https://github.com/neovim/neovim/issues/31745#issuecomment-2564383401 > usercommands would be even better suited True. Until...

`gO` exists already for that purpose. Not going to claim another mapping when `gO` already exists and is intended for that purpose. Also "s" as a mnemonic does not fit...

> (which I remind was strongly required to be "minimal"). None of this conflicts with that.

> which means we send empty root to the server instead of pwd. how is that related to the use of schedule? in this PR, schedule is sending the `root_dir`...

Avoiding the extra BufNewFile handlers is an argument in favor of @glepnir's solution (or at least makes them ~equivalent). Also @glepnir's solution seems clearer because it's contained in the `single_file_support`...

to unblock this, i suggest: - move the "buf valid" check to the `try_x` functions - we can try the schedule() approach again - @glepnir can send an improvement later,...

> `FileType` does not trigger at all (for any pattern including `*`) when running, for instance, `:e foo.txt`. it triggers in that case because filetype=text. though it doesn't trigger for...

> I don't know how important it is to preserve autostart/autoattach for these files It might actually be a bug if lsp is activated for unknown buffers. > servers with...

My last comment was question(s) for @glepnir . Main question is, can we try this out, or is there an obvious, serious risk that I'm missing?