[vim/vim] Discuss - Integrate QuickJS in Vim ? (Discussion #12748)
Linwei
At present, comprehending Bram's plan to progress with vim9script in the same direction he did is a challenging task, and it is also a significant endeavor to become proficient in that aspect of Vim 9.
Therefore, I propose to integrate QuickJS, a small and embeddable Javascript engine, to enable JavaScript and TypeScript in Vim.
What about the existing if_ interfaces?
If everything I remembered is correct, the if_ interfaces have already been in existence for 9 or 10 years, but are still not very popular.
Due to the additional setup procedures required for all if_ interfaces and their limited availability on every machine, plugin authors often choose not to use them in order to attract a wider user base. Additionally, users tend to prefer pure Vimscript plugins over those that rely on +python and +lua capabilities.
Perhaps there are other reasons, but after years of experimentation, it has ultimately proven to be unsuccessful.
Why not statically link against the Lua library?
Actually, it has already been disscussed before and got rejected by Bram:
Given the reasons mentioned above, let’s revisit the discussion. This solution can align with nvim’s Lua integration, and it seems promising.
However, it is still not a perfect solution because Lua is not considered a modern language and is primarily designed for small scripts or configuration purposes. Maintaining complex projects written in Lua could be a nightmare.
I will explain this below.
Lua is not a good language
Lua is not well-suited for complex projects due to the following reasons:
- Variable scope and function scope default to global, which make it appear like a outdated programming language from before the 1980s.
- A dereference on a non-existing key returns nil instead of an error.
- No way to impose constraints on function arguments. 'Safe' Lua functions are a mess of type-checking code.
- Lack of object model. Can simulated by table, but it leads to some inconsistencies.
- Lack of unicode support, string is more or less an alias to bytes.
- Lack of switch/case statement, and instead relies on numerous if/else statements to simulate it.
- Indexing starts from 1, requiring additional conversion when extending it in the C languag.
nilis everywhere, you always had to handle them throughout your code.- At least 5 ways to define a module, 3 ways to define a class.
- Lacks standard library, every project has to invent its own stdlibs, which cause your code hard to reuse across projects.
- One piece of code from project1 always can't be directly reused in project2 without modification.
- More choices mean more confusion.
- Lacks proper tooling.
- Too many choices can actually be a pain, start to hinder our decision-making ability.
Despite being invented in the 1990s, Lua exudes a nostalgic 60-70s vibe.
Even with the integration of the static Lua library, code from nvim may still not be reusable in vim due to the completely different APIs underlying them. Nvim utilizes libuv and dedicated nvim_ functions, whereas vim relies on traditional interfaces.
The division already exists and will not be eliminated simply because vim integrates Lua.
QuickJS advantages
- QuickJS is also small in size, requiring only 210 KB of extra binary size to run a "hello world" program..
- ES2020 compliance: passes nearly 100% of the ECMAScript Test Suite tests when selecting the ES2020 features.
- Consists of just a few C files with no external dependencies.
- The JS-based technology stack has a wealth of previous achievements for you to utilize, making it a better ecosystem.
- Less typing:
{ }vsbegin/end. - Simple tasks can be written in JavaScript, while complex tasks can be written in TypeScript, the most modern and elegant scripting language.
- There are many programmers who are skilled in using both JavaScript and TypeScript, which will make contributing to Vim's ecosystem much more easy.
- Among numerous JS virtual machine implementations, QuickJS has relatively good performance, second only to V8.
- Lua has only got over 10k projects on GitHub, while the number for JavaScript and TypeScript stands at 380k and 130k, respectively.
- Plenty of development tools and resources.
QuickJS is being widely used in game development nowadays. Additionally, it is also being utilized in mobile apps as an alternative to the big V8 engine.
The cost of integrating QuickJS into Vim is minimal, as it will only increase the binary size by approximately 210KB. However, the benefits are huge, since adopting the JavaScript/TypeScript ecosystem can greatly contribute to Vim's enhancement and success.
Side-by-side comparison
Declaring a class in TypeScript is very straightforward.:
Creating an instance is also clear and easy:
var p = new Person("skywind", 18, 1800) console.log(p.toString())
Isn’t this how a program should be written?
In Lua, the concept of "less is more" means that it doesn’t provide a built-in class construct. Instead, it suggests using tables and the setmetatable function to simulate classes:
Person = {} Person.__index = Person function Person:create(name, age, salary) local obj = {} setmetatable(obj, Person) obj.name = name obj.age = age obj.salary = salary return obj end function Person:toString() return self.name .. ' (' .. self.age .. ') (' .. self.salary .. ')' end local p = Person:create('skywind', 18, 1800) print(p:toString())
Honestly, tell me which kind of code you would prefer to write? Lua’s approach to class definition can indeed appear messy at first glance, and it becomes even more challenging when dealing with inheritance. The use of the ":" symbol in Lua is also unconventional compared to mainstream languages.
Writing this type of program can easily become a tangled mess when it grows larger. It’s prone to mistakes, and you may not even realize that you forgot to write a line like Person.__index = Person, which could lead to unpredictable outcomes. Many new technologies aim to simplify existing ones, but often end up adding more complexity. In other languages, defining a basic class is a simple task, but in Lua, it becomes quite frustrating.
In some projects, to simplify this matter, they have implemented a function called `"class"`` that allows you to define a class like this:
Account = class(function(acc,balance) acc.balance = balance end) function Account:withdraw(amount) self.balance = self.balance - amount end -- can create an Account using call notation! acc = Account(1000) acc:withdraw(100)
Does it look good? Not really, but it helps you handle the tedious tasks like setmetatable and inheritance, avoiding any omissions. However, the "class" implementation in this project is not compatible with classes implemented in other projects. They cannot inherit from each other, and even the instantiation process can have multiple approaches:
p = Person:create("project1", 18, 1800) p = Person:new("project2", 18, 1800) p = Person("project3", 18, 1800)
The instantiation functions in Project 1 and Project 2 have different names. Project 3 has its own implementation of a class, where you directly call the class name. The classes implemented in the first project cannot be called using the approach used in the second project.
Without a standard, collaboration becomes difficult. Even the external editor/IDE finds it challenging to understand what kind of class you have defined or what members it contains. As a result, you don’t receive much assistance and support during development.
After writing code in this way for a while, you may find yourself questioning why you are wasting so much time on the seemingly unnecessary task of ensuring compatibility in class definitions. Why can’t we have a unified approach like in TypeScript/JavaScript, where all projects use the new keyword for instantiation and the class keyword for declaration?
At this point, Lua gurus would tell you, "This is called the Less is more principle, and you don’t understand it." Doesn’t that make you feel like smashing your keyboard?
It is precisely because of Lua’s shortcomings that language fragmentation has occurred. Each project has to come up with its own set of fundamental things, making it difficult for code to be reused between projects and knowledge to accumulate. Most Lua code is difficult to exist independently from the project it belongs to, resulting in a lack of knowledge accumulation. The consequence is that, although Lua is 21 years older than TypeScript, the number of open source projects using Lua is less than 1/10 of those using TypeScript.
Comparing with TypeScript mentioned earlier, who is more beautiful and who is uglier? Who is better and who is worse? It is clear at a glance.
Error indentification
TypeScript has a well-designed compiler and linter that can help you identify errors in the editor during the compilation or editing phase.
With Lua, you have to run the code to find out where the error occurred. This is Lua’s so-called "Less is more" approach, where it doesn’t tell you where the mistake is and instead lets you step on the landmine during runtime. In the end, you spend more time paying the price for its shortcomings.
Therefore, Lua is not suitable for writing large programs. When the program becomes large, Lua code tends to become fragmented and loses maintainability.
Lua has a confusing rhetoric, which goes like, "Lua’s positioning has always been small and refined, not like Python/Java." If you truly only use Lua to write small code snippets or configurations of one or two hundred lines, I have no objections.
However, when it comes to complex plugin development, where Lua is often used to write 10k+ of lines of new plugins/modules, it is no longer appropriate to use the "small and refined positioning" as an excuse for its syntactic shortcomings in the face of complexity and maintainability.
Existing attempt in Vim
I am not the only one who endorse JavaScript/TypeScript; there are several famous projects that allow writing plugins in JS/TS:
- CoC: Nodejs extension host for vim & neovim, load extensions like VSCode and host language servers. There are 323 CoC packages written in JavaScript or TypeScript.
- denops.vim: created by vim-jp, allows developers to write plugins in TypeScript/Deno.
It can be seen from this that many programmers hope to use TS/JS to extend Vim. We can't simply ignore that there are 323 npm packages powered by CoC.
These two projects have already proven the feasibility of using JavaScript/TypeScript in Vim. But both of them require a big and separated Node/Deno runtime.
Summary
Introducing TypeScript/JavaScript to Vim does not mean replacing vim9script. Just provide more possibilities.
It could also be a significant opportunity to rejuvenate and enhance Vim’s greatness once again.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
For people down voting me, could you at least provide some reason, don't just have emotions.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
For people down voting me, could you at least provide some reason, don't just have emotions.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Clason
Oh, I have a lot more than "just emotions". But the predominant emotion is that this post, at this time, is in rather poor taste (besides containing arguments that would make a strawman blush with shame). I think most people have very different priorities right now and do not want to deal with this kind of unnecessary proposal.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
That's a reasonable point, I have also hesitated about whether posting this idea would seem disrespectful to Bram’s wishes.
But I saw someone have already posted related point here:
So I thought the discussion may have already begun. The problem lies here: someone other than me has also spotted it out. We will face it sooner or later.
I have asked many ignorant questions in the issues, and every time Bram responded to me with wisdom and patience. I greatly appreciated that and felt ashamed every time he corrected me. I also hope that the community can have the same broad-mindedness and magnanimity as Bram did. If there are any technical errors in my arguments, I wish someone can help point them out to me, if this is not the right moment, feel free to replay it at the right time.
I have been contemplating this issue for over a year. If vim9script could continue to evolve, I would never publish this post. However, now there have been some changes in the situation. Today, I dedicated 5 hours to preparing this post not because I enjoy arguing with others (nor attract attention), but solely with the purpose of making Vim more appealing to new users.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
Yinzuo Jiang
I have some questions:
After integrating QuickJS, what benefits can plugins based on the Node.js and npm ecosystem (such as coc.nvim) obtain? Can plugins like coc.nvim break free from the dependence on Node.js and npm packages? If most of the existing JS/TS-based text editor plugins (not limited to vim, but also including vscode) are built on the Node.js ecosystem, what are the benefits of integrating QuickJS into vim?
These questions might be of interest to JS/TS-based plugin developers.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ii14
Lua 5.1 has two implementations, the standard PUC Lua and the faster LuaJIT. On platforms and architectures that LuaJIT doesn't support, you can fall back to a more portable PUC Lua implementation. Lua specification includes C API, so swapping out the implementation is just a matter of changing the shared library (at worst recompiling), as LuaJIT should be fully ABI compatible with PUC Lua.
You're welcome to prove me wrong, but to the best of my knowledge, Javascript/ECMAScript doesn't have any standard API for Javascript engines. So you'd be boxing yourself into this specific implementation, with no easy way of replacing it to a faster, JIT compiled engine like V8 without making changes to the source code.
Lua's stable C API/ABI has another advantage in that you can easily write native Lua modules in other languages (C, C++, D, Rust, Zig etc.).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jgb
Introducing JS/Typescript would be a mistake.
Because they're awful languages firstly, but more importantly because this would again cause more fracturing in the vim/neovim ecosystem.
On top of that, now is not the time to discuss any radical changes to vim.
Neovim is the fork for "move fast and break things".
Vim is the voice of reason, stability and maturity.
Let's focus on continuing the stewardship of this beautiful project, fixing bugs, and making slow but steady improvements.
And if you ask me, I would refocus efforts on python extensibility of vim. It exists already, many popular plugins are written in python, and it's a much more pleasant language than Lua.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
For python, I think that @ychin's stable ABI support is useful. #12032
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
Adding another if_xx might not be a good idea.
Bram's idea was to use jobs & channels and/or vim9script.
Also, there is already a system to create plugins in Deno: https://github.com/vim-denops/denops.vim
We can already use JS/TS.
If we still need to add a new if_xx, WASM might be an option? #4604
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
-
Plugins based on Node.js (such as coc/deno) run in a separate process and cannot directly benefit from QuickJS. However, they can share some code between the Vim process and the Node.js/deno process. The main purpose of QuickJS is to write TypeScript plugins without Node.js/Deno, people who want to write plugins in TS/JS is the beneficiary, most of time, they don't need to setup a separated Node/Deno environment.
-
Some CoC packages can live without Node.js and npm packages after some modification: most standard APIs defined in ES2020 spec can be used directly. But other Node.js dedicated APIs are not available in QuickJS (mostly OS related, like file system and process management), they must be changed to the equivalent APIs provided in the
:h function-listand:h if_pyth. Existing node_modules packages are not available too, becasuse QuickJS is just a embedded javascript engine, like lua. -
They are totally different, other editors builton Electron or something are just not vim, the only thing they can do is just simulating vim keymaps, they can't define text objects and can't load any vim plugin.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
You are definitely right, it is impossible to reuse QuickJS integration code for V8, and can't switch to V8 without any modification.
This proposal is under the condition that small binary size increment may be acceptable (like around 200KB), which is discussed in vim/vim-win32-installer#182
If we integrate V8, it will significantly increase the size of the Vim installer since V8 is too large. However, if a 10MB binary increment is acceptable, I would suggest integrating Python's DLL.
Python is much better than Lua and JavaScript from a language perspective.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
TANIGUCHI Masaya
I agree with this proposal excepting the choice of implementation.
I think we can all agree that backward compatibility is important for the plug-in mechanism. There are many ways to ensure compatibility (e.g., thorough testing), but the easiest way to gain user understanding is to have a written specification.
The current state of Vim9script is that the implementation itself is the specification, and although it is said that the functionality was frozen with the official release of Vim9, there are still some functions that have not been implemented. I am sure you understand that vim9script is not widely used.
Lua is a stable implementation with multiple implementations, but the specification itself has a bad reputation for being changed every time it is upgraded, breaking backward compatibility. In fact, there is a situation in which the version cannot be upgraded from the Lua 5.1 specification.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
TANIGUCHI Masaya
TL;DR: Implementing the vim9script and bundling Lua is not good direction, and bundling JS-engine is relatively better option.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shougo
Hi, I am one of the denops.vim developers.
I know plugin developers issues.
Vim script is not so good programming language.
Few tools, few functions, few libraries, and you cannot use the knowledge in the work.
But I know why Vim script is chosen as Vim's plugin language.
Of course, it's not to annoy plugin developers.
Vim script is very stable and well maintained by Vim developers.
It will continue to be the case as long as Vim development continues.
If Vim uses other languages as script language?
For example, LuaJIT is not maintained well and neovim cannot upgrade Lua version.
QuickJS's last release is over 2 years ago... Vim must maintain the project?
I don't say "what language is the best script language?". It is not problem.
The biggest problem is "what language exists the after 20 years?". The answer is "Vim script".
Text editors have a very long lifespan.
I have written Vim plugins for 15 years.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
TANIGUCHI Masaya
At long term viewpoint, the exsiting multiple implementation is better (sound) than the only single implementation isn't it? JS community has many js implementation but we could not see other implementation of vim9script.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
USAMI Kenta
Be aware that not only has QuickJS been unmaintained for a long time, but CVE-2023-31922 is left unfixed.
Someone needs to take responsibility and take over maintenance if you intend to use this.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ii14
LuaJIT is not maintained well and neovim cannot upgrade Lua version.
One thing about that, LuaJIT is maintained. You're probably referring to Lua 5.1, 5.2, 5.3 etc. This is closer to something like C or C++ standards, where a new spec is released once in a while. Just because you're not on the latest version doesn't mean that the older versions are not supported, maintained, used by anyone anymore or that you shouldn't use them in new projects. People write ANSI C and C99 to this day, even though there have been newer standards released since then, and there is nothing particularly wrong about it. Lua 5.1 specification is fixed, it won't ever change, and that's by design.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ii14
That's exactly my point here, with Javascript you have to pick between the performance and portability or binary size. With Lua you don't have to make that commitment. I'd also look into various Python interpreters and see if maybe some of their interpreters have some stable or at least similarly looking APIs.
On what language is better, all of that is subjective. You can make your own standard functions that provide classes with inheritance and everything, if you really want to. I don't find that to be a problem with how extensible Lua is. On static typing - the language is fixed, but the ecosystem is not, you can always evolve that. I haven't really used any of that, but you have languages that compile to Lua, just like TS compiles to JS.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shougo
At long term viewpoint, the exsiting multiple implementation is better
(sound) than the only single implementation isn't it? JS community has many
js implementation but we could not see other implementation of vim9script.
From general programming language viewpoint, it is the right.
But Vim script is DSL for Vim.
It doesn't have to be a general purpose programming language.
And second problem is breaking changes from programming language.
For example, Python2 to Python3.
It cannot be controled from Vim development.
Shouldn't Vim have to stay compatible?
One thing about that, LuaJIT is maintained. You're probably referring to Lua 5.1, 5.2, 5.3 etc.
Yes. It is right.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Clason
I'm getting flashbacks from the tree-sitter issue here... (coincidence?)
Again, it's perfectly ok to make different choices for Vim based on the (objectively) different priorities, but it is important to argue in good faith having actually done research, instead of pulling out the first half-remembered "fact" as argument against Neovim's choice.
- Lua 5.2 is not an "upgrade" from Lua 5.1, it's in effect a different language (similar to Python2 vs. Python3, but without the former being deprecated; Lua is meant to be an embedded scripting host for a certain application, not a general purpose ecosystem language like Python -- and the lack of a comparable ecosystem is in fact a valid argument against it, if you are actually making use of that ecosystem). Actually, @ii14's comparison to C/C++ standards is very apt (and I don't see Vim "upgrading" to newer C standards all the time...)
- LuaJIT is a very stringently maintained implementation of the Lua 5.1 language (plus some extensions). Like Bram, Mike Pall uses a... not very common development model and is very strict about what to include, so sparse activity and infrequent releases are not a good indicator of maintenance quality.
- In fact, the existence of a strict and fixed Lua 5.1 standard allows Neovim to switch out implementations whenever wanted -- either LuaJIT for the reference implementation on platforms supported by the former, or against a future runtime that is better/faster/more widely available. (In fact, this is frequently done by distro packagers.)
- Touching on point 1, ask yourself whether plugins use CoC or Denops because of the language or the runtime and package ecosystem. If it's (predominantly) the latter, embedding QuickJS will not get you much.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
USAMI Kenta
Another thread mentions Lua and LuaJIT, but QuickJS is just an ES2020 version of the JavaScript runtime, so the problem could be worse. When ES20XX is released in the future, Vim with QuickJS integrated will remain a fossil unless someone rewrites QuickJS.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shougo
Oh, I get. It seems Perl5 and Perl6.
Lua 5.2 is breaking changes fork from Lua 5.1?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Clason
Not quite fork, but meant as a new iteration (without deprecating the old iteration). Again, the different C/C++ standards are a very good mental model (which I will now steal and use every time someone brings up Lua 5.1 vs 5.4).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shougo
To use general programming language as Vim's script language is very risky.
The development cannot be controlled from Vim developers.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
USAMI Kenta
At long term viewpoint, the exsiting multiple implementation is better (sound) than the only single implementation isn't it? JS community has many js implementation but we could not see other implementation of vim9script.
Editor plugins rely on the runtime functionality of the editor, so having multiple implementations of the programming language is not very useful. Just like JavaScript code written for browser APIs won't work in Node.js. It's useful for dependency-free generic library interoperability, but that doesn't seem to be the point of Shougo's comment.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shougo
A good example of how difficult it is to use a general-purpose programming language as a scripting language is the problem with Vim's external interface support.
In my very personal opinion, Vim should remove the external interfaces and focus on improving Vim scripts.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
fcpg
The external interfaces can stay, but I agree that the main plugin language should be a DSL controlled by the Vim core team, as Bram intended. Vim9script is already half-way there if not more, so it would be pretty weird to flip-flop now.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
smekkley
Nice, looks like we have a conclusion. Let's close the discussion.
No more language bindings and let vim side stay simple and dumb as possible.
Bram wanted to encourage channel API usage, which would eliminate the chance of blocking vim's main thread and that's also beneficial for the users.
Plugins like deno sounds already enough as well for plugin writers who don't want to deal with vim(9)script.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
Closed #12748 as resolved.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
voidlinux is maintaining quickjs right now and CVE-2023-31922 has been fixed
void-linux/void-packages#44173
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
if the release of next ES202X will make QuickJS and fossil, then Lua 5.1 and Luajit have long become fossils.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
It's already a pity that a lot of colorschemes and plugins these days are neovim only because they are written in Lua.
Which colorscheme author doesn’t want their work to be used by more people? the problem is not Lua but treesitter, they want to use semantic annotation produced by treesitter to provide more precise highlighting, and treesitter is neovim only, translate these colorschemes into legacy vimscript will not make them available in Vim.
And if you ask me, I would refocus efforts on python extensibility of vim. It exists already, many popular plugins are written in python, and it's a much more pleasant language than Lua.
"Many popular plugins are written in python" ?
I have 120+ plugins installed in my Vim, only 4 of them are using python, why ?
if_python was introduced nearly 20 years ago in 7.0:
071d427
There are 600+ nvim lua plugins created in last 3 years:
Honestly speaking, how many python plugins are you using ? far less than nvim's lua plugins.
So I will not say if_python is not used, but after 20 years, I would say if_python is not successful.
The most important reason is that python DLL cannot be shipped with vim, if_python requires an extra setup step.
And many new users I met (selling them ycm) found difficult to setup them right python environment for vim,
especially for who are not familiar with python (both Windows, Linux and macOS users).
So plugin authors are asking to ship if_xx language runtime DLL with vim.
I agree that python is more pleasant than lua and JavaScript,
if vim can ship with either a python dll or a lua static/dynamic library, I will not post this.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
Linwei
@k-takata I remember, 7 years ago, you and mattn helped me address some very challenging Win32 job issues in #1184, that's very appreciated, You have my respect.
I also found you have PR to include lua DLL in #6143 .
Apparently, you know where is problem is and I believe you will agree with my reply to jgb here , at least a part of it.
If future Vim releases can directly include a Lua or Python DLL, I will never propose JavaScript/TypeScript-related things.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
perhaps we should revisit: vim/vim-win32-installer#182 then?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
I believe it is a good idea.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Linwei
+wasm looks promising
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shougo
voidlinux is maintaining quickjs right now and GHSA-rc5m-84qg-fpjg has been fixed
void-linux/void-packages#44173
But it is not fixed in upstream.
if the release of next ES202X will make ES2020/QuickJS fossil, then Lua 5.1 and Luajit have long become fossils.
The old language specification is not the problem.
The important is it is maintained or not for long time.
Lua 5.1 and luajit is maintained. But QuickJS is not.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Prabir Shrestha
I had sent a PR to add native Ecmascript (aka Javascript) support in vim at #5198 but used ducktape instead of quickjs. It was a controversial topic. Having written multiple plugins in vimscript one thing I have always found lacking is the ecosystem more than the language. I need to keep creating basic util function instead of taking advantage of the language ecosystem. Introducing Javascript would allow me to take advantage for 2million+ packages written by others. If I want to create a markdown linter, there is probably some markdown parser in js that I could use, I want to create a base64, or sha256 of a string there is probably a package for it. With vimscript or vim9script, I'm on my own, I need to write my own or use a job channel and spawn an executable and make sure it works in mac/linux/windows. It is a nightmare as a plugin author since focusing on my goals I need to create a ton of time on the core foundation instead of taking advantage of the open source ecosystem given there are very few vim plugin authors. This is one of the other reason why lua/vim9script is not fascinating to me due to lack of libraries although the speed does mean it is lot better than vimscript if you need something fast.
There will always be someone pushing their favorite language to be added in vim so they can be productive. I really thing WASM is the future and vim should invest in first class support here. This ay anyone can use their favorite language to code. I have been able to write in c, compile to WASM and load it in vim and get output via WASM3 which is easy to embed. You can find my work here. What I have noticed overtime is that WASM runtime written in rust such as wasmer and wasmtime seems to be popular, feature rich and is more active (This does means we need to get rust compiling in vim. But might be that is ok given that even linux supports compiling rust). I'm also excited about GC support in WASM that is currently being implemented by multiple WASM runtimes as this would allow us to easily work with existing vimscript runtime without serialiation/deserialization. There is also WASI which can be a huge benefit as it provides tons of apis such as filesystem, clocks, random, sockets (more proposed apis can be found at https://github.com/WebAssembly/WASI/blob/main/Proposals.md) can be used and this would reduce the cost for vim mantainers as they don't need to keep porting these feature to vim.
Here is the neovim tracking issue for WASM - neovim/neovim#23579.
I really think WASM should be the last language extension to be added to vim. Would love to hear more thoughts on WASM on Vim at #4604.
—
Reply to this email directly, view it on GitHub,.
You are receiving this because you are subscribed to this thread.
fcpg
WASM is definitely more interesting than a JS interface, to me; it's the old JVM dream coming true, a VM running everywhere that can run code compiled from any of the languages that can target it.
However, the same criteria for consideration should apply: is it 1) free, open-source, 2) stable, and 3) sustainable in the very long term.
In other words, will we have a stable, open-source, production-grade WASM runtime with a maintained ecosystem in 10 years? Or could it just be another iteration of the cycle "language/ecosystem X is popular right now (millions of packages!), make an interface for it, few people actually use the interface, in the meantime language X slowly falls out of fashion, repos are archived, developers move to the next cool language, hey how cool would it be if we got a Vim interface for it" ? TypeScript looks very risky to me in that regard (some will disagree), WASM a bit less so, but I don't know.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
I think one key decision point here is whether we just want (if we want one at all, which is still an open question) a new language for core scripting functionality, or just writing plugins.
For example, Lua is the only scripting language in Neovim that runs in the main process. It means you don't have to spawn another process (with all the complexity that comes with it), and Lua can completely replace Vimscript in Neovim for even things like writing your own vimrc etc. If we are going down the jobs/channels route these are relatively heavy options mostly for writing "proper" plugins that have a heavy task to do. What Bram was trying to do, I believe, is to just have vim9script in that blessed mode, where other people write Node.js/Deno/etc plugins in another process, whereas in Neovim, Lua has that blessed bundled status.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
Lua is a stable implementation with multiple implementations, but the specification itself has a bad reputation for being changed every time it is upgraded, breaking backward compatibility. In fact, there is a situation in which the version cannot be upgraded from the Lua 5.1 specification.
I believe Neovim is currently permanently pinned to Lua 5.1, with no plans to upgrade, ever, for compatibility reasons. Extensions need to be done via libraries, not upgrades to the language. See https://neovim.io/doc/user/lua.html#lua-compat
In general Vim is used across a very large cross section of ecosystem (I would argue larger than Neovim) so backwards compatibility is quite important. To be fair sometimes you could write plugins that require certain features (e.g. virtual text) that require new Vim versions anyway.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yee Cheng Chin
I don't think we should do it now (as others have already said, short-term to even medium-term should be to figure out how to maintain Vim past Bram), but I do support wasm as a better alternative than JS using something like QuickJS. Given that it's a proper web standard, I think the probability of it just dropping dead in 10 years is low considering that web browsers will need to keep support for it to be able to render old web pages (to be fair, a counterpoint is that a lot of old web pages using Flash did essentially get deprecated). It's also more agnostic to short-term language fashion.
One issue is that of backwards compatibility. WASM is a living standard and deciding on how to support newer versions while providing backwards compatibility can be quite complicated unless the runtimes we use have ability to switch on the fly (I'm not familiar enough to know if they can do that).
One thing I need to point out is that WASM is not a replacement for vim9script / vimscript. Remember, the vast majority of people writing vimscript are just doing it in their vimrc, writing colorschemes, and whatnot. No one (ok, some of you will) will write a Rust (compiled to wasm) vimrc you know? So, we will still need to decide on the future of vim9script regardless of what we do with say WASM because there are probably already people writing vim9script vimrc or color schemes or small scripts.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dragan Simic
> One thing I need to point out is that WASM is not a replacement for
> vim9script / vimscript. Remember, the vast majority of people writing
> vimscript are just doing it in their vimrc, writing colorschemes, and
> whatnot. No one (ok, some of you will) will write a Rust (compiled to
> wasm) vimrc you know? So, we will still need to decide on the future
> of vim9script regardless of what we do with say WASM because there are
> probably already people writing vim9script vimrc or color schemes or
> small scripts.
inside people's ~/.vimrc files.
Phạm Bình An
LuaJIT is well maintained by Mike Pall, and even if he stops maintaining it, we can use LuaJIT 2 by OpenResty instead, it is also fully Lua51-compatible
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Phạm Bình An
This is a project that transpile TypeScript code to Lua https://github.com/TypeScriptToLua/TypeScriptToLua
Both Vim and Neovim have Lua interfaces, so with this transpiler, you can write Vim plugin in TypeScript without adding another bloat to the C core.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Phạm Bình An
Correction. Only LuaJIT is maintained. Not Lua 5.1, it has stopped at Lua 5.1.5 in 2012
However Lua 5.1 has a few other maintaining implementations such as Luau by Roblox, LuaJIT2 by OpenResty (which is a fork of LuaJIT by Mike Pall)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.