init.lua as an alternative to init.vim
justinmk opened this issue · comments
If init.lua is found in the usual places, that should be used as the user config instead of init.vim.
What should happen if both init.lua and init.vim are found?
- Should it be an error? Most deterministic, avoids users needing to understand load order.
- Should we silently ignore it, and choose only one? (But warn about this in
:checkhealth) - Should we load both, in a particular order?
Also the -u and -S flags should evaluate *.lua files automatically:
nvim -u foo.lua
nvim -S foo.lua
should work like lua foo.lua .
What happens if 2x init.vim is found in the usual places? First in path wins? First in path is loaded first? No matter what, I'd make 2 init files a hard error and refuse to start, unless given one explicitely via -u.
What happens if 2x init.vim is found in the usual places?
There's a defined load order. But one of the things we intentionally did when adding XDG support was to remove support for the dozens of different variations. So that's why I think (1) or (2) from the list is probably best.
I vote informative and actionable error, with a link to a help section describing rationale / solutions.
I vote for loading init.lua first and falling back on init.vim. Someone with an init.lua should know a priori what he is doing:
- either he is a neovim adept and he would know what do to whatever happens, he can source his init.vim if need be
- either he is a newbie and he wouldn't have an init.vim in the first place.
It also depends how easy converting init.vim to init.lua would be. What would the init.lua look like ?
Should we silently ignore it, and choose only one?
This is what Vim already does. There's a defined set (and order) of rc files that it looks for. The first one that is found is used and the rest are ignored.
It also depends how easy converting init.vim to init.lua would be.
I don't think that actually matters. Support for init.vim isn't being removed. init.lua is just being added as an alternative. As you suggest, once she has created an init.lua, she can do whatever from there including sourcing an init.vim.
I would not suggest going with init.lua name: it has a set semantics in lua, ~/.config/nvim with sole init.lua (not an unlikely thing given that plugins are supposed to be installed into ~/.local/share/nvim) looks like some kind of misplaced nvim lua package, and with a bunch of other files it would look like misplaced part of some unknown lua package.
As for -u file.lua: don’t like this. It immediately raises a question what -u is supposed to do with file that has no extension, better have another set of switches complementing -u/-U.
I would not suggest going with init.lua name: it has a set semantics in lua, ~/.config/nvim with sole init.lua (not an unlikely thing given that plugins are supposed to be installed into ~/.local/share/nvim) looks like some kind of misplaced nvim lua package,
Confusion is not a high risk given that this file name will be established as a well-known convention.
What do you suggest instead?
As for -u file.lua: don’t like this. It immediately raises a question what -u is supposed to do with file that has no extension, better have another set of switches complementing -u/-U.
What is -U?
Would prefer to avoid new arguments for users to learn, I don't think the question about missing extensions is important: anything without .lua will be sourced as VimL.
What is
-U?
-U is used in GVim. But it is not used in neovim.
Hm...
What do you suggest instead?
startup.lua. Though anybody remembers why rc.vim was turned down?
Would prefer to avoid new arguments for users to learn, I don't think the question about missing extensions is important: anything without .lua will be sourced as VimL.
Leaving a user without an option to use nvim -I <(echo some lua code for testing). Do not like any kind of filename-based detection I can’t bypass and this is exactly a thing, -l and -L as most obvious choices for this kind of task are already taken.
Though anybody remembers why rc.vim was turned down?
I would much prefer this to work as in @justinmk's original proposal than behind a different flag. If there will be a default init.lua, and it might override init.vim, then it would be necessary to have the equivalent of -u NORC and -u NONE, and that seems like overkill. If someone wants to bypass the file extension, just make the thing read the modeline, like vim itself does to detect filetypes in some cases.
EDIT: Also, if strictly necessary, why not use
nvim -u NORC -c "luafile myfile" (although the file would be loaded quite later in the startup sequence in this case).
Having a defined order of looking for init.lua in preference to init.vim is completely orthogonal to what is expected of the file provided to -u or -S. I don't think that the behavior of those switches should be changed to rely on file naming.
That just adds indeterminism, especially since there's currently no requirement that the argument to those switches ends in .vim.
(although the file would be loaded quite later in the startup sequence in this case).
Which is significant for an init script. -c "luafile myfile" would be better expressed as some equivalent of -S myfile.
I don't think that the behavior of those switches should be changed to rely on file naming.
The command-line switches are for convenience, not rigor. No one will be surprised if a .lua file is interpreted as Lua, and it is a usability gain. real gain + negligible cost = worth doing.
Leaving a user without an option to use nvim -I <(echo some lua code for testing). Do not like any kind of filename-based detection I can’t bypass and this is exactly a thing, -l and -L as most obvious choices for this kind of task are already taken.
For that case we can still implement a new switch, but for the common case -u and -S should DWIM.
Will this handle folders like plugin and ftplugin? Will it be possible to make ftplugin/javascript.lua? It would be awesome to write files there other than vimscript.
Would it be better to have those in the same folder or in something like lua/ftplugin/javascript.lua
@tjdevries Lua should be first-class citizen thus keeping them in the same folder would make more sense for people who want to write their whole nvim configuration in lua instead of vimscript.
Would it be better to have those in the same folder or in something like
lua/ftplugin/javascript.lua
I think that would conflict with the existing mechanism of having lua/ automatically part of the lua package path.
Cool, that makes sense to me. As a first pass, I would say getting just init.lua to work seems best, and then we could extend that to all the other ways to automatically load files (with probably the same precedence ordering between all of them -- although some, like in ftplugin/* might just load all the ones that exist).
However, I'm not familiar w/ the C code to load all of the files, so I'd definitely defer to someone who has better knowledge of that area of the code base.
Guys, what do you think about how we should reference "init.lua" in the docs along with "init.vim"?
Should it be some generic name like init-file/config-file/init-vim?
Or should we just add something like this "throughout the docs, init.vim is used to describe the initialization config file. If you have an init.lua, that will take the place of init.vim."?
I am fine with init-file/config-file. I suppose we should have init-lua and init-vim / init-file / config-file point at the same paragraph and only htne explain their relation.
So perhaps init-file init-vim init-lua all explained in one paragraph, with their ordering and relationships? That seems good to me. Going forward we should use init-file as the general purpose marker, but I'm not sure we 100% need to find every place of init-vim at this point? @teto what do you think of that?
I just noticed that along with the init.vim tag there is the config tag. So we could just use that one. Replacing |init.vim| by |config| is also more readable in the case I've seen (e.g. to your |init.vim| file.)
Works for me. I have no strong preference, just wanted to make sure that we all agreed on it. 😄
Do the above two comments count as consensus? Excited to kick the tyres...
Guys, what do you think about how we should reference "init.lua" in the docs along with "init.vim"?
:help config mentions "vimrc" and "config" as the generic names. I think we should stick with those. We could settle on "config", if someone wants to scrub "vimrc" from the docs, but that might be more cost than benefit.
Wow. Great. Any documentation on that?
you mean :help init.lua ? or something more specific?
@rofrol You can add a file named init.lua in ~/.config/nvim/ directory and Neovim will pick that instead of init.vim. If you have both the files (init.lua and init.vim) in that directory, I think init.lua is given preference and init.vim is completely ignored.
it will show an error also if you have both.
What about plugin/ and such folders? Does plugin/file.lua work?
Apparently there was a created issue about this located at #12670.
@kutsan Not yet. Right now, only nvim/init.lua works.
Using this query https://github.com/search?o=desc&p=2&q=filename%3Ainit.lua&s=indexed&type=Code I have found these configs:
I converted my init file to lua too https://github.com/mukeshsoni/config/blob/master/.config/nvim/init.lua
But i failed to do simple things like
- Define a vimscript function and assign it to autocmd
- set mapleader to space
I don't know if vimpeccable will help there but i couldn't find any helper function to run arbitrary vimscript code from lua. vim.api.nvim_exec didn't do what i assumed it will.
@mukeshsoni You can have a look at my dotfiles. I recently converted mine from init.vim to init.lua.
https://github.com/numToStr/dotfiles/tree/master/neovim