xplr v0.10 ditched yaml and goes the Neovim way with its own "init.lua" #183
Replies: 3 comments 5 replies
-
This is awesome! I've upgraded
This is when I'm disabling all icons like so: xplr.config.node_types.directory.meta.icon = ''
xplr.config.node_types.file.meta.icon = ''
xplr.config.node_types.symlink.meta.icon = ''
key = xplr.config.modes.builtin.default.key_bindings.on_key
key.a = key['ctrl-a']
key['ctrl-a'] = nil However there are two annoying things which I think we could easily fix with one change: there is still a notion of "remaps" in xplr, I suggest we get rid of it entirely. Example one: search is bound to key['/'] = key['ctrl-f']
key['ctrl-f'] = nil Similarly, next visited path is bound both to key = xplr.config.modes.builtin.default.key_bindings.remaps
key['tab'] = nil I'll go back now to continue migrating my config, and will let you know if I spot more things 😉 |
Beta Was this translation helpful? Give feedback.
-
Wrote a basic documentation of the Lua API here: https://github.com/sayanarijit/xplr/wiki/Lua-API |
Beta Was this translation helpful? Give feedback.
-
is there a way to get lsp integration like including libs? it would be great to have some sort of code completion or/and api documentation built in an editor |
Beta Was this translation helpful? Give feedback.
-
Taking inspiration from Neovim, xplr v0.10 has embraced embedded luajit to enable better hackability.
But why Lua?
Portability & distribution
With only bash and YAML, we are limited to what interpreters, vms or shells are installed in the users system.
For e.g. we can't write a hack that executes a Python script and claim that it will work the same on any machine. Some system doesn't even come with
bash
installed. Or even if installed, we still need to worry about the version.Lua on the other hand, can be shipped with
xplr
natively, because it's really tiny. That means, we can write a lua script and claim that it should work fine on any system. Even if there's no lua installed.This lets us distribute our customizations for other users to use via a plugin system.
Safety
Writing a safe bash script is really difficult. We need to escape or quote file paths properly, deal with unset and empty variables, handle errors and returncodes properly. A simple whitespace or special character in a filename can do devastating damage to our important files. With embedded lua, we can expose many utility functions that helps overcome these safety pitfalls.
Scriptability
With only bash and YAML, we are also limited to what's being exposed via the output pipes. Exposing the whole app state via pipes will be really inefficient. Although, it's possible to dump the app state as yaml, we still need
yq
to parse it which is again a portability issue. With lua, we get the whole app state passed as input. We also get inputs passed by the user when executing the plugin (thinklua require'foo'.do_something(input=bar)
in neovim). Also, we can avoid exporting global variablese.g. $OPENER
and define it in the plugin config (thinklua require'foo'.setup(config=bar)
).Speed
Speed will be a bonus since we won't need to read files or write to pipe files. The input and returned outputs will be converted directly by the binding logic. Also, we can surely expect lua scripts to execute faster than bash scripts.
Community
Ever since neovim started embedding Lua, there's been an explosion of plugins from the community. With embedded Lua support, xplr can become part of this awesome ecosystem too.
Neovim reasoning
For further reasoning, read the Neovim explaination: https://github.com/neovim/neovim/wiki/FAQ#why-embed-lua-instead-of-x
How to migrate
See https://github.com/sayanarijit/xplr/wiki/Upgrade-Guide#v091---v0101
API documentation
https://github.com/sayanarijit/xplr/wiki/Lua-API
Beta Was this translation helpful? Give feedback.
All reactions