Add project roadmap

[n-shift]

The title says it

[kuator]

The title says Add project roadmap

[n-shift]

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

[max397574]

@noib3

[noib3]

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:

• completion-core: this is the core of the completion engine which is responsible for filtering, sorting and sending completions to the client (more on the client later). It runs an event loop in a tokio runtime separate from the main thread, listening to messages from the client and sending messages back, and it's designed to be Neovim-agnostic;
• completion-client: the client runs on the main thread. It's responsible for the initial loading and setup of the plugin, it reacts to user input by sending the appropriate messages to the core and it displays the completions provided by the core on the screen;
• completion-sources: the different completion sources that the core queries to provide completions. A completion source is just a type implementing the CompletionSource trait. You can check out the code for a very simple source like lipsum to get an idea of what those look like.

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:

Screen.Recording.2022-11-19.at.1.30.46.PM.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]

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]

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]

@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]

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]

@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