sqlite.lua VS nvim-highlite

I have been working on restructuring telescope-frecency.nvim. One of the biggest changes is removing dependency for sqlite.lua.

I'd like to share my first real attempt at a Neovim plugin and hopefully get feedback and help on how whether this is something others would be interested in and how to improve it. annotate.nvim is a plugin that allows you set/edit brief notes that are tied to lines in your code. It uses Neovim's extended marks for tracking the location of your notes and kkharji's sqlite.lua plugin to allow you to restore the annotations when you restart Neovim. I'd been experimenting with using scratch buffers to hold notes while working to avoid my habit of cluttering code with comments, but this felt limited. When I saw this plugin I wanted to see if I could combine the ideas to get something more on-demand.

I'm currently working on a plugin that, it appears, is going to require the sqlite.lua package. According to its own README, it would require a couple of sqlite system packages (at least for linux) in order for it to run. However I've also come across some packages that have sqlite.lua as a dependency, but they don't inform the user in the readme about setting up sqlite on the system.

If you need to persist a lot of files, you could use sqlite3 as database through something like sqlite.lua

legendary.nvim v2.5.0 now supports frecency sorting! It will be enabled by default if kkharji/sqlite.lua is also installed.

I think it is. Some neovim plugins such as Telescope which is widely used and praised use SQLite[1]

[1] https://github.com/kkharji/sqlite.lua#-powered-by-sqlitelua

nivm-highlite boasts ease of configuration, but I haven't tried it yet. It shows only dark themes, but most of the themes support `background=light`. However they are kinda low contrast out of the box.

My plugin and mini.colors can also do it.

tl;dr: export your favorite themes to new formats (e.g. wezterm theme), generate new colorschemes from only a palette of colors, update old colorschemes to automatically include support for new plugins (it sometimes makes them faster too). Repo link

Wow. I just spent like an hour the other day converting colortrans to Lua because I wanted my colorscheme generator to work with all systems, but with this I can just remove built-in support for cterm and suggest mini.color for that purpose.

Mine, nvim-highlite

I do wish there was a builtin way to partially link highlight groups. In my colorscheme I opted for this syntax, which resolves self into the batch of groups being defined recursively unwraps highlight links to fetch the true highlight group being referenced.

Shameless self-plug, but nvim-highlite and all of its inheritors support everything from 8-bit to 256-bt and is written using the Neovim API.

Haven't tried newer color schemes on the block, but I have tried a lot and all of them add 100s of ms to startup time. Eventually settled on a copy of https://github.com/Iron-E/nvim-highlite. Another culprit tends to be all the fancy statusline.

Not to self advertise (regulars here know I do that enough), but my colorscheme is made to work in any range of color. If you don't like it, look under the usage section— all of the colorschemes others have made with it also work without termguicolors.

I'm a little puzzled as to why they'd do that. It's completely possible to use the :colorscheme command.