@bfredl are you able to describe the conditions that determine whether a function can be allowed/disallowed from running in fast events? Is it just textlock?

(doesn't have to be in this PR) but I was wondering if it made sense to create a new table on vim (something like vim.fast_fn) for any of the vim functions that are available in fast?

I'm not sure if it's a good idea or if it exposes too much confusion, but the reason I suggest that is because then vim.fast_fn will always error when someone tries to call something that isn't fast, as opposed to vim.fn sometimes errors depending on how the function is called.

Haven't thought this through a ton yet though, so I could be completely wrong about the idea.

vim.fast_fn will always error when someone tries to call something that isn't fast, as opposed to vim.fn sometimes errors depending on how the function is called.

We need to be a lot less willing to add random modules. Let's try to make vim.fn do the right thing (even if that currently just means an error).

I'm saying, the error can be confusing for users because it sometimes errors.

I'm totally fine w/ us not adding another module, I just wanted to at least surface the issue and at least make sure we had considered it (since I didn't see it mentioned)

To begin with vim.fn in fast will be the exception rather than the norm, but as the list grows we need to make sure this is properly documented. It's similar to how some API functions will error if textlock is active.

One thing I like about vim.fast_fn is it allows doing something like :lua =vim.fast_fn to quickly see all functions which can run in fast. However, I don't think we should go that route since it is just creating duplication since the original versions in vim.fn will need to remain. Maybe adding this into something like nvim_get_api_info or similar (probably the latter) might be better.

I suspect calling these are being pretty niche, and not something most lua plugins are going to need consider (you can write many a nice lua plugin without going into the fast event loop at all, or schedule_wrap all callbacks). So a separate module would be overkill.

Sounds good to me :)

To begin with vim.fn in fast will be the exception rather than the norm, but as the list grows we need to make sure this is properly documented.

I think we can get that, and treesitter-based checks, and auto-completion, by annotation/flags. Even if that just means our docstring API: #12040

Anything else required here?

(1) confirm that the test correctly fails

Can confirm test fails locally if fast=false in eval.lua

@bfredl @justinmk : ok to merge?

lgtm as before :) but still would like @bfredl signoff. Maybe mark a few more functions as fast?

I want to hold off adding more functions until I understand what properties a function must have for it to be safe to run in fast.

Referencing an earlier comment:

@bfredl are you able to describe the conditions that determine whether a function can be allowed/disallowed from running in fast events? Is it just textlock?

@bfredl any advice before I start randomly adding functions to the list?

I'd rather starting at the end at solving some problem (from either built-in or plugin Lua code), like iconv did.

My main motivation here is to reduce the risk of Github issues that simply just involveE5560: vimL function must not be called in a lua loop callback, for some particular code path I forgot to schedule onto the main event. When you have a good async module, it becomes very easy to hit these.

I would rather we just mark all the functions we can to mitigate the potential of these issues. If a function really needs to run on the main event, then fine, but otherwise (so far) this has felt like death by a thousand paper cuts.