I have some plugins that it's config use vim-script how can I config plugins that use vim-script with lua for neovim.
for example gruvbox use vim-script I look in docs for lua config but I didn't find any thing, I have to use vim-script to configure it.
While writing your nvim stuff in lua, the vim object is automatically injected into your code by Neovim.
It allows getting and setting vim, plugins and variable related options in lua.
The gruvbox theme requires setting variables in the global scope. You can access the global scope using the vim.g field.
For example to set g:gruvbox_bold to 1, which is true in lua, you need to write
vim.g.gruvbox_bold = true
in your init.lua file.
I recommend you to take a look at this article.
https://www.notonlycode.org/neovim-lua-config/.
It is short and teaches the basics of using lua in Neovim.
Related
I want to set vim plugin options that have the vimscript format let some#option = option inside my NeoVim init.lua file, but I can't figure out how to set these options in a format that NeoVim respects.
I've tried using vim.cmd("let some#option = option") but this doesn't seem to work. Any advice? Thanks!
From nanotee/nvim-lua-guide, the section on Managing vim internal variables shows various API calls, including
Global variables (g:):
vim.api.nvim_set_var()
vim.api.nvim_get_var()
vim.api.nvim_del_var()
In practice, setting a global variable looks like
vim.api.nvim_set_var('some#var', 'value')
You can also use the meta-accessors, such as vim.g:
vim.g['some#var'] = 'value'
The method with vmd.cmd can work, although using the more structured API shown above is advised.
Note that in vim.cmd("let some#option = option") the right-hand side of the assignment operator is an expression. This means the plain token option would be evaluated as an identifier.
Depending on what you are trying to do, you may need to add additional quotes to create a string.
vim.cmd("let some#var = 'value'")
I would like to separate init.lua script used in Hammerspoon to enhance the readability and maintainance.
So it looks like the following:
init.lua
AppWatcher.lua
WiFiWatcher.lua
KeyRemap.lua
And then from within init.lua I would read these files and make the watcher activate.
However, it seems that there is no such function defined (maybe I may be missing it, though). Is it possible to separate the logic like that in Hammerspoon?
Yes, you can do this using require.
If you put your Lua files in ~/.hammerspoon/, you can then load them using require('modulename'). For example, if you have the following modules:
~/.hammerspoon/AppWatcher.lua
~/.hammerspoon/WiFiWatcher.lua
~/.hammerspoon/KeyRemap.lua
Then you can load them from ~/.hammerspoon/init.lua like this:
local AppWatcher = require('AppWatcher')
local WiFiWatcher = require('WiFiWatcher')
local KeyRemap = require('KeyRemap')
You can load any Lua modules, as long as they appear in package.path. To see the directories you can use, take a look at HammerSpoon's package.path setup file. This references the default Lua package.path, which is defined in luaconf.h.
If you want to put your Lua modules in a directory not included in package.path, you can do it by adding them to the LUA_PATH_5_3 or LUA_PATH environment variables.
I'm trying to embed Lua 5.2 into my C program.
I want to let the Lua script to be able to require and load another script. How to do it?
Suppose the Lua part has such file structure:
lua_script
- main.lua
+ utils
- custom_loader.lua
+ globals
- scene_globals.lua
- scene_levels.lua
The main.lua will try to require and import functions from custom_loader.lua, and so on...
Is it possible to do this without writing a kind-of wrapper in C?
Can the Lua script automagically just load everything it needs?
(Ps. I don't really need sandboxing for now, so it's okay for the script to do what it want.)
As decribed by the Lua require man page, it searches for the file in a path.
This path can be defined in C.
Have a look to this post : "Setting the global LUA_PATH variable from C++/C"
The require function is very pratical to load modules and libraries defined in .lua files.
I've been wondering, if there is an environment variable to set the search path for #use and #load for the ocaml toplevel.
What I think I know so far:
I can use findlib instead of "raw" #use and #load. findlib looks at some environment variables for the search path.
I can set a search path with -I.
Experiments seem to indicate that CAML_LD_LIBRARY_PATH does not influence #use (script loading) and #load (byte code file loading).
(updated) I can use #directory to add the desired path - but unfortunately this only takes a string literal, so i can't pass something I read from the environment at run time. (Update: I forgot to mention #directory originally and why it doesn't fit my use case).
What I want to do:
Run ocaml programs as scripts
Point ocaml to script libraries and script fragments with an environment variable
Avoid, in some scenarios, to create a full findlib library.
Presently I'm not using ocaml as interpreter, but a wrapper that adds a path to the invocation. I want to avoid the wrapper.
(I hope the questions makes sense now, after you know my use case)
So: Is there an environment variable to set the search path for #use and #load without resorting to a wrapper?
More Details
What I'm currently doing:
#!/usr/bin/env oscript2
#use "MyScript"
#load "SomeModule.cmo"
(* ... more ocaml *)
oscript2 is a wrapper around ocaml that basically sets the search paths for #use and #load, but finally executes the toplevel ocaml withe something like
exec ocaml -I .... ...some-byte-code-modules... "$#"
MyScript and SomeModule.cmo live outside of the "normal" Ocaml search path. The actual location might change, but after login (and working through the profie scripts) there is an environment variable (today it's OSCRIPTLOAD_PATH) that tells me, where alle loadable byte code and ocaml script files might live.
This works well, a variant of that setup has been in use for years (at least 7).
The one thing that bothers me there, is: The wrapper, the simple fact of it's presence, looks homebrew, so I'd like to avoid it, to make a better impression on potential future users of the script collection. What I'd like to do
#!/usr/bin/env ocaml
#use "MyScript"
#load "SomeModule.cmo"
(* ... more ocaml *)
and have ocaml itself pick up the search path from some environment variable (I'm free to change the variable name, that is under my control, but I don't want to install script and byte code libs into the default search path, and, as already stated, I' asking if I can do that without findlib).
Basically (as already stated at the very beginning) I'm looking for an environment variable that controls the search path for #use and #load. I'm not looking for toplevel directives and not for wrappers that retrofit this feature. (Thanks everyone for those suggestions, but unfortunately I've already gone that road, it's feasible, but here I'm looking for an alternative purely for cosmetic reasons).
Recent research didn't bring up that such a variable exists, but I thought I'd be asking here, before giving up on it.
From inside the OCaml toplevel you can use the #directory "foo";; primitive to add an include directory.
Here's a shell script that runs the OCaml toplevel while adding a directory to the search path taken from an environment variable named EXTRA_OCAML_DIR.
#!/bin/sh
ocaml -I "$EXTRA_OCAML_DIR" "$#"
If you run this instead of ocaml, you will have a directory in the load path specified by an environment variable.
It seems a little obvious, but maybe it will spark an idea that is more helpful.
I'm using a closed-source application that loads Lua scripts and allows some customization through modifying these scripts. Unfortunately that application is not very good at generating useful log output (all I get is 'script failed') if something goes wrong in one of the Lua scripts.
I realize that dynamic languages are pretty much resistant to static code analysis in the way C++ code can be analyzed for example.
I was hoping though, there would be a tool that runs through a Lua script and e.g. warns about variables that have not been defined in the context of a particular script.
Essentially what I'm looking for is a tool that for a script:
local a
print b
would output:
warning: script.lua(1): local 'a' is not used'
warning: script.lua(2): 'b' may not be defined'
It can only really be warnings for most things but that would still be useful! Does such a tool exist? Or maybe a Lua IDE with a feature like that build in?
Thanks, Chris
Automated static code analysis for Lua is not an easy task in general. However, for a limited set of practical problems it is quite doable.
Quick googling for "lua lint" yields these two tools: lua-checker and Lua lint.
You may want to roll your own tool for your specific needs however.
Metalua is one of the most powerful tools for static Lua code analysis. For example, please see metalint, the tool for global variable usage analysis.
Please do not hesitate to post your question on Metalua mailing list. People there are usually very helpful.
There is also lua-inspect, which is based on metalua that was already mentioned. I've integrated it into ZeroBrane Studio IDE, which generates an output very similar to what you'd expect. See this SO answer for details: https://stackoverflow.com/a/11789348/1442917.
For checking globals, see this lua-l posting. Checking locals is harder.
You need to find a parser for lua (should be available as open source) and use it to parse the script into a proper AST tree. Use that tree and a simple variable visibility tracker to find out when a variable is or isn't defined.
Usually the scoping rules are simple:
start with the top AST node and an empty scope
item look at the child statements for that node. Every variable declaration should be added in the current scope.
if a new scope is starting (for example via a { operator) create a new variable scope inheriting the variables in the current scope).
when a scope is ending (for example via } ) remove the current child variable scope and return to the parent.
Iterate carefully.
This will provide you with what variables are visible where inside the AST. You can use this information and if you also inspect the expressions AST nodes (read/write of variables) you can find out your information.
I just started using luacheck and it is excellent!
The first release was from 2015.