Is there a plan to support asynchronous？

[yyy33]

I'm using a standard hard drive, and then every time I insert data vim lags a bit

[kkharji]

hmmm no async support, but you can use callbacks. For example you can vim.schedule

vim.schedule({callback})                                      *vim.schedule()*
    Schedules {callback} to be invoked soon by the main event-loop. Useful
    to avoid |textlock| or other temporary restrictions.

for example

vim.schedule(function() 
    local todos = todos:get { where = { id = 1 } }
    myFunctionThatProcessTodos(todos)
end)

I'm sure there is something wrong you are doing not sure what. I'd suggest looking at existing applications likes

• https://github.com/jghauser/papis.nvim/
• https://github.com/AckslD/nvim-neoclip.lua

[yyy33]

vim.schedule(function() 
    local todos = todos:get { where = { id = 1 } }
    myFunctionThatProcessTodos(todos)
end)

Thanks, I found out today that neovim supports multi-threading via luv, then I tried to open a new thread and get sqlite.lua to work in the new thread, but it failed and I got the following error, can you give me some advice? where sqlite_path is the path to sqlite.lua, and file is the database file,and i execute luafile /tmp/t.lua

/tmp/t.lua

local function work_callback()
    local sqlite_path = '/mnt/64d0d217-1a4c-4258-860b-02fbc3ade743/note/nvim/config/nvim/pack/packer/start/sqlite.lua/lua/?.lua;'
    local file = '/mnt/64d0d217-1a4c-4258-860b-02fbc3ade743/note/nvim/config/nvim/data/translate/help.db'

    package.path = sqlite_path .. package.path
    local sqlite= require('sqlite.db')
    local db = sqlite.new(file):open()
    ok = db:exists('sentence')
    db:close()

    return ok
end

local function after_work_callback(arg1)
    print(arg1)
end

local work = vim.loop.new_work(work_callback, after_work_callback)
work:queue()

error message

nil
Error in luv thread:
/tmp/t.lua:6: loop or previous error loading module 'sqlite.db'

[kkharji]

I tested:

local function work_callback()
  local sqlite = require "sqlite.db"
  local db = sqlite.new("/tmp/test.db"):open()
  ok = db:exists "sentence"
  db:close()

  return ok
end

local function after_work_callback(arg1)
  print(arg1)
end

local work = vim.loop.new_work(work_callback, after_work_callback)
work:queue()

luafile %

In make case, the error I get

...im/site/pack/packer/start/sqlite.lua/lua/sqlite/defs.lua:11: attempt to index field 'g' (a nil value)

Then after few runs,

Error in luv thread:
test.lua:2: loop or previous error loading module 'sqlite.db'

@Conni2461 any thoughts why vim.g. is nill.

The loop or previous error loading might be because of require_on_index hack?

--- taken from https://github.com/tjdevries/lazy.nvim/blob/master/lua/lazy.lua

M.require_on_index = function(require_path)
  return setmetatable({}, {
    __index = function(_, key)
      return require(require_path)[key]
    end,

    __newindex = function(_, key, value)
      require(require_path)[key] = value
    end,
  })
end

[yyy33]

#

@Conni2461 any thoughts why vim.g. is nill.

i think this is the reson, :help lua-loop-threading

Multithreading                                            *lua-loop-threading*

Plugins can perform work in separate (os-level) threads using the threading
APIs in luv, for instance `vim.loop.new_thread`. Note that every thread
gets its own separate lua interpreter state, with no access to lua globals
in the main thread. Neither can the state of the editor (buffers, windows,
etc) be directly accessed from threads.

A subset of the `vim.*` API is available in threads. This includes:

- `vim.loop` with a separate event loop per thread.
- `vim.mpack` and `vim.json` (useful for serializing messages between threads)
- `require` in threads can use lua packages from the global |package.path|
- `print()` and `vim.inspect`
- `vim.diff`
- most utility functions in `vim.*` for working with pure lua values
  like `vim.split`, `vim.tbl_*`, `vim.list_*`, and so on.
- `vim.is_thread()` returns true from a non-main thread.

[yyy33]

@Conni2461 any thoughts why vim.g. is nill.

The loop or previous error loading might be because of require_on_index hack?

Can you use vim.loop.new_work in sqlite.lua to implement asynchronous