3 ms·

> but can understand the reason why they went with LuaJIT instead. why is that? For a text editor I don't see how ludicrous speed would help... Especially wh

> but can understand the reason why they went with LuaJIT instead. why is that? For a text editor I don't see how ludicrous speed would help... Especially when considering that luajit doesn't compile string operations well; which is what I imagine text editors do a lot of.

deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
petre 10y ago
Probably just because its faster than PUC Lua, enables FFI calls w/ less overhead, easy to interface with the existing C code? They are aiming at reimplementing the current C VimScript runtime (suffering from code rot and filled with preprocessor declarations for dead platforms) in Lua w/o degrading performance too much.
- justinmk 10y ago
  > reimplementing the current C VimScript runtime See the updated FAQ[1]. We are punting on the VimL-to-Lua translator. We think it will be more valuable to instead ship Lua as a first-class alternative to VimL. > (suffering from code rot and filled with preprocessor declarations for dead platforms) in Lua w/o degrading performance too much eval.c is being refactored in PR 5119[2]. 1: https://github.com/neovim/neovim/wiki/FAQ https://github.com/neovim/neovim/wiki/FAQ 2: https://github.com/neovim/neovim/pull/5119 https://github.com/neovim/neovim/pull/5119