Gregory Anders

I see. Unfortunately I don't think this is something that is trivial to address. AFAIK Vim (and thus Neovim) draws signs from left to right and truncates from the left,...

> EDIT: seems it was intentional? https://github.com/neovim/neovim/pull/26618/files#r1429248469 That particular instance was intentional, because the backtrace there doesn't provide any useful information. It's not a call site of a specific function,...

> So I think backtrace information could be still useful for this particular case as well as for user configs? For `vim.diagnostic.disable()` and `vim.diagnostic.is_disabled()` I agree. I don't know why...

IMO we should match vim-commentary's behavior here. This is a common use case that we should support out of the box.

>It works in a sense of "does not break editing", but not necessarily in a sense "aligns with how comments are treated by the language" (as those might require having...

@echasnovski Your patch looks good to me and gives the behavior I would expect.

I've opened a PR with Vim to change the default https://github.com/vim/vim/pull/14820.

> I find this defaulting to a split strange, given the fact you can prefix the term with mods for a split direction (i.e vert term and hor term), Until...

Aside from any performance issues, we can limit `vim.validate` to top-level/"public" functions. Imo there's no reason to use `vim.validate` over `assert` for internal/private/`local` functions. `assert` will always be faster.

Considering this resolved by https://github.com/neovim/neovim/pull/28977. We can convert many existing instances of `vim.validate` to the new form introduced in that PR. The old form is still slow, but should only...