Christian Clason

True, but as far as I can tell, all other changes are transparent _in the output_. This is the only one that can actually break a file (which is how...

(At the risk of beating a dead horse, but just to make it clear: I'm not saying that all other options _should_ be enabled by default; I'm just adding a...

Sure, and that's fine -- my point is just that unlike black (and other code formatters), blacktex also makes changes that affect the _output_. This is something I do not...

> this only affects snippets from lsp server, right? > no need to change anything if I'm using ultisnips. Yes.

There was also talk on Gitter about exposing neovim's internal `mbyte` functions to Lua. This might be the best option since disagreement between vim's C core and Lua functions about...

> I think there's enough interest from you and @clason that we should think about how these should be defined. I don't think a detailed set of criteria is required;...

> I wonder if 3 would make sense as a separate plugin that uses the library? Because if we're going for something like a magit equivalent (but better, of course...

To recap the current state: 1. a base git library (e.g., in https://github.com/nvim-lua/plenary.nvim) is still missing (basically, waiting on https://github.com/libgit2/luagit2 to make a release); 2. a very good signify-style plugin...

I don't think you need to worry about backwards compatibility yet -- both neovim LSP and this plugin are in early access, so "here there be dragons" and all that......

Note that this is slightly different (and easier?) than #4 (or https://github.com/tjdevries/nlua.nvim/issues/1), which is about a general-purpose run-time Lua profiler.