mhartington/formatter.nvim

Expose Lua API

Opened this issue · 6 comments

aspeddro commented

Following a practice in most plugins:

  1. Expose the Lua API and its documentation
  2. Remove the commands plugin Format, FormatWrite...
  3. Let the user create their commands
haras-unicorn commented

I don't know whate is there to expose really.
Removing the commands would break a lot of users configs.
Users are always welcome to create their own commands.

aspeddro commented

What I say is to have a lua function documented to format.

Example: lua require("formatter.format").format() raise a error.

E5108: Error executing lua ...ack/packer/start/formatter.nvim/lua/formatter/format.lua:20: attempt to perf
orm arithmetic on local 'start_line' (a nil value)
stack traceback:
        ...ack/packer/start/formatter.nvim/lua/formatter/format.lua:20: in function 'format'
        [string ":lua"]:1: in main chunk
haras-unicorn commented

Yeah there is already an issue to improve documentation but I wasn't able to get around to doing it.

I'll link this issue over there so I know what else needs to be documented.

mhartington commented

Just curious, why? You don't really get anything better by exposing those APIs. The commands just simplify the arguments needed for internal APIs.

aspeddro commented

Users are configuring using lua, because it's easier, so yes, it's an improvement. For example pass the format function as a callback.

Note: I removed the second point because it break a lot of users configs.

calops commented

I second this. I think it's more idiomatic in a lua configuration to call something like require("formatter").format_write() instead of vim.cmd("FormatWrite"). It also plays better with how lazy.nvim (for example) handles lazy loading without requiring the user to specify an exhaustive list of commands (which can change).

Of course, it's still la good thing to keep the commands available.

  • 👍3