Version 3

This version is going to be done all in the new native LUA scripting used by neovim version v0.5.0. Since this is such a big change, other than common defaults found in the earlier config files, this should be rewritten from a mostly blank canvas rather than peice by peice rewritting each configuration file till most of it is in lua. No this will start from LUA, when something irritates me, I'll file an issue and work on it. However, here is some pre-planning to make sure key features are implemented either by handwritten code (something I want to focus on more this time around) or by downloading plugins for really complicated functionality.

Getting things done right from the beginning is going to be very important here because I already VIM which I've gotten to a got state of configuration where there's minimal dependencies and the customizations are minimal to make sure I always have a stable minimal terminal editor I'm happy with. Then there's also VSCode which is nice and fully featured with the plugins but is too bloated and frustrating to configure sometimes, so the goal now is to make this version of my neovim dotfiles my main IDE and that requires getting as much right as early as possible so the requires some values to prioritize.

1. Write my own native, testable LUA first, before seeking plugins.
2. Take my time - when you carelessly configure something as important as your editor technical debt tends to make the program more fragile and frustrating to use and maintain.
3. If you need a proper IDE before this configuration is done, use the alternatives like VSCode or Vim till it's ready rather than rushing configurations.
4. Focus on good defaults that make sense in other editors (ie for :Files & for searching runners)
5. Get key IDE features that will never be put into the more minimalist Vim configurations first like LSP, autocompletion, linters, runners (especially for TDD), DAP, etc.
6. KISS - Keep It Simple Stupid - Previous dotfile versions exploded in complexity when simpler solutions existed, really understand the problem space around new features and try to minimize the number of features.
7. The Unix philosophy - Trying to keep IDEs simple is difficult, but staying with the unix philosophy of having this be only an editor helps. Other than having configurations for neovim launching its own terminal internally, external programs should be minimized but still preferred when you need to do something that isn't explicitly editing text. Think FZF & FD to select a file, or an LSP server to analyze source code, prettifiers etc.

The Plan

Defaults

The first part is to port over the default settings for the native editor itself in LUA. This includes things like set number, set smartcase, shiftwidth=4, language specific settings like shiftwidth=2 for JS, TS, JSX, Svelte, YAML, JSON. These are easy to define and a good template already exists, your previous version 2 configurations. Just remember to be more careful about making cross-compatible configurations to make swapping between editors easier. Things like: <C-p> searching for file in VSCode and Sublime, <C-/> toggling comments, etc. This site is a good place to look for good key binding defaults.

LSP

This is the big feature that makes an IDE really nice to use over minimalist editors. Thankfully NeoVim has standardised its API for dealing with language servers and clients. Ideally, NeovVim would develop their own LSP client that's native to the editor to simplify configurations, but several good options exist. Evaluate pluggins like neovim/nvim-lspconfig, hrsh7th/nvim-compe and ms-jpq/coq_nvim which is very interesting for its speed and use of C implemented in-memory btrees and SQL lookup table.

Bottom Bar Terminal and LSP Info

The bottom bar is good place to have a toggleable terminal/pane to temporarily display things like the shell obviously but also information about your code taken from the LSP (think function prototype, data structure, definition, linter errors, etc). Needs more thought

Project Tree Sidebar

Sidebars are nice to have in editors because it can show peripheral information, most importantly a project directory tree. This is a good place to write your own plugin in native LUA. There aren't that many features involed, a buffer that displays the results of external shell commands (ls, tree, etc), and watching for keys that let you create, open, move, delete new files and folders and toggle the tree view by parent directory. Keep the logic as simple as possible and do as much as possible to rely on GNU coreutils to make it function and focus more on the UI code to present it. The sidebar should also be easily toggled in and out of view to keep the focus on the editor as much as possible.

There's work in telescope to integrate core fzf functionality into telescope using an embedded C implementation of fzf. This will speed it up, make it have more useful features like its better fuzzy matching system and better integrate it into neovim. It might still be experimental so experiment first. This code section of the repo covers it.

To help outline things to build. Here's a list of things to implement. And some notes on how to do it. Here is a guide on how to implement things in lua. And here is awesome neovim for plugin and implementation ideas. Here is a unicode table

• Git operations, especially commit messages and patch/line staging
• Defaults like these
• Comment toggling, like comment-toggle
• Fzf
  • Consider the lua implemented fzf-lua
• Rg
• LSP
  • coq
• Filetree
  • Like this nvim-tree
• Statusline like lualine
• preview telescope
• Toggled terminal
  • like this plugin?
• Indent lines, like this
• Devicons
• Treesitter
  • the neovim client
  • the rust program
• Autopair like this
• Test running
• Notetaking
  • Consider neuron
  • Home rolled client potentially one that works with your indexing project
  • vimwiki
  • telescope as the searcher
• Git UI
  • Like the gutter
  • Or the simple & community supported lsp-config
  • magit clone neogit