jmbuhr / otter.nvim

Just ask an otter! 🦦
MIT License
428 stars 11 forks source link

Can I use this the otter way around? #63

Closed georgeguimaraes closed 8 months ago

georgeguimaraes commented 8 months ago

Hi, wanted to attach markdown LSPs (markdownlint and vale) into markdown that is embedded into Elixir files, like this:

defmodule Foo do

  @doc """
  Greets someone

  ## Examples

      iex> Foo.hello("George)"
      Hello, George

  """
  def hello(name) do
    IO.puts "Hello, #{name}"
  end
end

Markdown inside Elixir is already injected through https://github.com/nvim-treesitter/nvim-treesitter/blob/4199be485cd85662d8ff1dc8c4cc78d819fad6cd/queries/elixir/injections.scm#L5-L14

Is this possible? Tried it and it didn't work.

georgeguimaraes commented 8 months ago

Turns out you can!

My mistake is that I was doing lua require('otter').activate({'elixir'}) instead of lua require('otter').activate({'markdown'})

jmbuhr commented 8 months ago

Big up for the issue title! 🦦

georgeguimaraes commented 8 months ago

Sorry to bump this again,

My markdown files are using ltex-ls and vale-ls.

In the markdown inside Elixir files, I got ltex-ls working, but only because it works with plaintext files (and then it gives me a lot of diagnostics that doesn't make sense in Markdown):

[ERROR][2023-10-24 18:24:23] .../vim/lsp/rpc.lua:675    "rpc"   "ltex-ls"       "stderr"        "Oct 24, 2023 6:24:23 PM org.bsplines.ltexls.parsing.CodeFragmentizer$Companion create\nWARNING: Unsupported code language ID '', treating text as plaintext\n"

So it seems to me that otter is generating buffers with no filetype set. How can I debug it further? (I'm using Neovim nightly, btw)

jmbuhr commented 8 months ago

Indeed, for performance reasons I don't set the ft of the otter buffer: https://github.com/jmbuhr/otter.nvim/blob/374fcce9941fc15016e7992fb07f9cc96593a04a/lua/otter/keeper.lua#L238-L249

jmbuhr commented 8 months ago

So any languageserver configured to attach to the would-be-filtetype of the otter buffer should still be attached because lspconfig creates the autocommand whose callback we call here.

georgeguimaraes commented 8 months ago

So any languageserver configured to attach to the would-be-filtetype of the otter buffer should still be attached because lspconfig creates the autocommand whose callback we call here.

interesting!

I added some vim.inpects to see what's going on:

main_nr: 1
lang: "markdown"
otter_nr: 3
autocommands: { {
    buflocal = false,
    callback = <function 1>,
    command = "",
    desc = "Checks whether server marksman should start a new instance or attach to an existing one.",
    event = "FileType",
    group = 26,
    group_name = "lspconfig",
    id = 62,
    once = false,
    pattern = "markdown"
  }, {
    buflocal = false,
    callback = <function 2>,
    command = "",
    desc = "Checks whether server vale_ls should start a new instance or attach to an existing one.",
    event = "FileType",
    group = 26,
    group_name = "lspconfig",
    id = 64,
    once = false,
    pattern = "markdown"
  }, {
    buflocal = false,
    callback = <function 3>,
    command = "",
    desc = "Checks whether server ltex should start a new instance or attach to an existing one.",
    event = "FileType",
    group = 26,
    group_name = "lspconfig",
    id = 77,
    once = false,
    pattern = "markdown"
  } }
diagnostics: true

But no luck with marksman and vale attaching to the otter buffer yet. Still investigating. If you have any pointers, please let me know.

jmbuhr commented 8 months ago

I guessing they are being attached and immediately quit because they require a filetype? Does the lsp log show something?

Maybe I can revert to setting the filetype instead of manually calling the callbacks. I believe I have since made other performance improvements that may make this "hack" obsolete.

Can you try this?

    -- local autocommands = api.nvim_get_autocmds({ group = "lspconfig", pattern = lang })
    -- for _, command in ipairs(autocommands) do
    --   local opt = { buf = otter_nr }
    --   command.callback(opt)
    -- end
    api.nvim_buf_set_option(otter_nr, "filetype", lang)
georgeguimaraes commented 8 months ago

Can you try this?

    -- local autocommands = api.nvim_get_autocmds({ group = "lspconfig", pattern = lang })
    -- for _, command in ipairs(autocommands) do
    --   local opt = { buf = otter_nr }
    --   command.callback(opt)
    -- end
    api.nvim_buf_set_option(otter_nr, "filetype", lang)

That worked for ltex-ls, which was already attaching to the otter buffer. Now ltex-ls parses it as a Markdown code correctly: CleanShot 2023-10-25 at 12 44 28

This is great already!

Now, I still wonder why the other LSPs are not attaching. In particular, I'm interested in vale-ls, but the lsp logs show nothing.

jmbuhr commented 8 months ago

Does vale attach correctly to regular markdown buffers?

jmbuhr commented 8 months ago

You can also directly open the otter buffer (:ls! to see which number it has, then :b<number>) and experiment in it.

georgeguimaraes commented 8 months ago

Does vale attach correctly to regular markdown buffers?

It does. But I managed to get everything working. My problem is that I had installed (through Mason) both vale and vale-ls. As soon as I uninstalled vale, it worked as expected:

CleanShot 2023-10-25 at 15 46 25

Now, I still need to set filetype for ltex-ls in order to ignore some errors that don't make sense for Markdown, so that the final result is:

CleanShot 2023-10-25 at 15 48 48

georgeguimaraes commented 8 months ago

Thanks a lot for helping me through it! I didn't know about ls!, that was really helpful.

Are you going to reenable filetype? I guess it would only benefit users of ltex on embedded markdown, so, not sure if you want to go that path, although I'd be glad if you did :)

jmbuhr commented 8 months ago

I haven't found performance degradation from re-enabling filetypes on otter bufffers in my config so far, so I might. But I am wary about people's filetype plugins doing weird things to the otter buffers or running a lot more code than they have to. You know what, we can just leave both options in and make it configurable.

jmbuhr commented 8 months ago

the release bot misunderstood my refs, was not supposed to close this. Let me know how this change works for you.

georgeguimaraes commented 8 months ago

Just need a small fix here: https://github.com/jmbuhr/otter.nvim/commit/e30200211aed45cb3daf1c458f23f2645f9abba9#r130924812

georgeguimaraes commented 8 months ago

Everything working perfectly (saw the new release)! Thanks again so much. And I apologize for all the trouble in helping me

jmbuhr commented 8 months ago

I thank you for your contribution! :)

georgeguimaraes commented 8 months ago

Wrote about otter in Elixir Forum: https://elixirforum.com/t/grammar-style-check-and-markdown-linter-for-code-documentation-in-neovim/59248