noib3 / nvim-completion

:zap: An async autocompletion framework for Neovim
MIT License
505 stars 13 forks source link

Add project roadmap #16

Open n-shift opened 2 years ago

n-shift commented 2 years ago

The title says it

kuator commented 2 years ago

The title says Add project roadmap

n-shift commented 1 year ago

The issue still remains opened 😞. If the roadmap is impossible to do, the simple tasklist would be nice anyways.

max397574 commented 1 year ago

@noib3

noib3 commented 1 year ago

I've been wanting to write an update on this project for a while but kept putting it off, so I guess this is it.

Sorry for the long response, there are other similar issues/discussions that are relevant to this and I'd rather give a complete overview here rather that scattering it into n different places.

Current status

The general framework that nvim-completion tries to provide is mostly complete. The plugin is composed of 3 different parts:

Each completion source has to provide an associated type called Config which implements Deserialize. This is used to allow end-users to configure each source independently. For example:

local completion = require("nvim_completion")

completion.setup({
  sources = {
    lipsum = {
      -- The `enable` key is automatically added to every source.
      enable = function(buf)
        -- Only enable this source in Lua files.
        return vim.api.nvim_buf_get_option(buf, "filetype") == "lua"
      end,

      -- Other fields specified in `Lipsum::Config` would go here..
    },

    lsp = { enable = true },
  },
})

Roadmap for a 0.1.0 release

The next steps would be to

a) implement the lsp module in nvim-oxi: for the lsp source to work we need to have Rust bindings to the vim.lsp table, and those should be exposed under nvim_oxi::lsp, b) implement keybindings in the client for selecting and accepting completion results, c) better UI: right now the only UI is a floating window showing the completion results sent from the core and the corresponding matched characters for each result:

https://user-images.githubusercontent.com/59321248/202851036-c80977f1-3c1d-4519-9058-95486e61f7a2.mov

Future

With all this being said, the reason I put off writing this update for this long is that I've started to work on a new modal editor written in Rust and I'd like to focus on that rather than Neovim.

If anyone wants to pick up this project I'd be happy to give a more detailed tour of the current codebase (which is still pretty small tbh), but I don't think I'll keep working on this, at least not in the near future.

dsully commented 1 year ago

This is a bummer to hear.. I had hoped this project would provide a viable alternative to the questionable architectural choices made in nvim-cmp.

Regarding a modal editor, I assume you've seen https://github.com/helix-editor/helix ?

n-shift commented 1 year ago

This is honestly said to hear, but thanks for response. I'd suggest you to post on reddit about looking for a maintainer on nvim-oxi and nvim-completion projects. You can also move them into some github organization so you won't have to transfer ownership completely and allowing more people to collaborate on those!

noib3 commented 1 year ago

@dsully I have. I feel like, at least in the beginning, Helix provides a much nicer experience compared to Neovim since most functionalities are built in instead of relying on third party plugins. However I don't think it introduces any significant innovations, and for people that already have a nicely configured Neovim setup (like me and many others) there's no real reason to switch.

@n-shift I don't think openly asking for "maintainers" for half-complete projects like nvim-completion makes sense. On the other hand I consider nvim-oxi mostly complete and I'll keep maintaining that myself.

turboladen commented 1 year ago

FWIW, the main impetus for my starting overkill_nvim was to eventually build something like nvim-completion. I'm just starting to use nvim-oxi, but I could see myself getting an itch to contribute to both -oxi and -completion, but probably not for some time. Frankly, like @noib3 said, it's easy to get your nvim env setup to some capacity, then just have to spend time doing "real work", which sorta implies that--at least for me--the shoddy state my dotfiles live in a lot of the time is "good enough" (as much as I hate to admit that), leaving it tough to justify spending big chunks of time on nvim+Rust stuff. I digress... I just wanted to chime in to let you know I have some interest here.

kuator commented 1 year ago

@dsully I have. I feel like, at least in the beginning, Helix provides a much nicer experience compared to Neovim since most functionalities are built in instead of relying on third party plugins. However I don't think it introduces any significant innovations, and for people that already have a nicely configured Neovim setup (like me and many others) there's no real reason to switch.

@n-shift I don't think openly asking for "maintainers" for half-complete projects like nvim-completion makes sense. On the other hand I consider nvim-oxi mostly complete and I'll keep maintaining that myself.

Regarding your new editor, is it gonna take inspiration from Kakoune like Helix where the text gets selected whenever your move, i.e Subject-Object-Verb model. Or is it gonna follow the Verb-Object model like Vim and Neovim do. I am myself a big fan of Verb-Object model as it enables the dot-repeat functionality. Also what are the other values you're gonna prioritize when building this editor? If you plan on building it for personal use only, you can disregard this question altogether