Comments (9)
Whatever approach we use, config will be installed to
environment.etc.*
on NixOS andxdg.configFile.*
on home-manager. If there's an equivalent for nix-darwin we should consider installing there too.Anything in the wrapper (such as
-u
or exporting variables) would be in addition to that.So I'm trying to think if there's any downsides to doing this universally, without a wrapRc option 🤔
I'm not aware of any side effects, if neovim is ran with -u /home/user/.config/nvim/init.lua
(standard XDG_CONFIG_HOME along with all other neovim configs) and $MYVIMRC
is set to it's path.
from nixvim.
Potentially we can manage rtp partially with wrapper args, in that case we can even drop
wrapRc
completely and just place init.lua to filesPlugin.
We may be able to do that with the -c
option, which allows specifying additional vim commands from the CLI.
There's also --cmd
, which is like -c
except it is run before the init file.
However this wouldn't allow us to drop wrapRc
, since that is mainly intended for specifying the init
file to use via -u
.
But this is debatable, maybe managing rtp paths as the first lines in init.lua is enough plus allow users to add paths with raw lua.
I think there's value in the rtp changes being shown transparently in nixvim-print-init
.
Or it can mixed approach: user config path is added with command line args (so that the directory with init.lua is known to neovim), other paths are managed in init.lua.
Not sure what you mean by "directory with init file is known to neovim"?
My understanding is neovim computes this dir internally using APP_NAME
, and using -u
to specify the init file essentially means this dir is not used anyway?
But I'm not confident I fully understand this.
I think I need to read https://neovim.io/doc/user/starting.html#initialization a few times 😂
In particular, under point 7:
If Nvim was started with "-u {file}" then {file} is used as the config
and all initializations until 8. are skipped. $MYVIMRC is not set.
"nvim -u NORC" can be used to skip these initializations without
reading a file. "nvim -u NONE" also skips plugins and syntax
highlighting.
from nixvim.
We may be able to do that with the
-c
option, which allows specifying additional vim commands from the CLI.There's also
--cmd
, which is like-c
except it is run before the init file.However this wouldn't allow us to drop
wrapRc
, since that is mainly intended for specifying theinit
file to use via-u
.
Year, I was completely wrong about it. I thought that since --cmd is run before init.lua, I can set rtp there, and Nvim will find init.lua in rtp, but that's not the case. In that case wrapRc is unavoidable (or $VIMRUNTIME can be set manually in wrapper args, but it's basically the same thing).
With this information fourth point is invalid. There is not a single reason to use --cmd args for rtp, only -u for init.lua. Settings rtp and packpath in extraConfigLuPre with mkBefore is perfectly OK. Fourth point can be changed to similar issue as filesPlugin, but with home-manager. Nixpkgs by default is adding plugin dir to rtp with set rtp^=/nix/store/xxx-vim-pack-dir
. In this case plugins are first in rtp, user configs only after. My suggestion to modify rtp by default should fix that too.
from nixvim.
I'm also trying to wrap my head around whether there's ever a good reason to have a user-configured wrapRc
option at all?
The only time I can think of where specifying the vimrc via -u
isn't needed would be when installing via home-manager, since we install to xdg config.
Even in that scenario, I don't think setting the vimrc with -u
really does any harm though?
Historical context
The wrapRc
option is basically a copy of pkgs.wrapNeovimUnstable
's argument of the same name. Although we implement it slightly differently to position parts of the initial file correctly.
The rtp modification to get an "isolated" config is a more recent change (c359761), that is not part of the nixpkgs implementation.
IMO the isolated rtp doesn't conceptually relate to specifying the vimrc via the wrapper, so this may also benefit from either being a separate option or not being configurable at all.
Simple option:
Can we just remove the wrapRc
option entirely and always isolate the config, use -u
in the wrapper, etc?
Is anyone aware of a legitimate use case for setting wrapRc = false
?
from nixvim.
None comes to mind, but maybe someone relies on it and will explain their use case if we do something with it
from nixvim.
Is anyone aware of a legitimate use case for setting
wrapRc = false
?
When -u
is used $MYVIMRC
is not set and it is hard to get init.lua path from inside nvim. I personally don't want -u
to be used in home-manager. LuaSnip for example by default loads paths relative to $MYVIMRC
(maybe it fixed now, don't know), some other plugins can use it too.
from nixvim.
When
-u
is used$MYVIMRC
is not set
True, but we could export that ourselves in the wrapper
from nixvim.
True, but we could export that ourselves in the wrapper
Still I think it's better to put init.lua in xdg_config_home to better emulate regular, non-nix neovim. So I'd say to make this option internal/readonly and set it to true by default. Home-manager wrapper can override it to false. In other cases it's unavoidable (unless maybe settings XDG_CONFIG_HOME in the wrapper? But it's worse than setting -u
, because XDG_CONFIG_HOME will be needed in internal terminal and other subprocesses). I don't think this is a big burden.
If -u
would be set, I think I would want to circumvent it somehow to undo it in my config.
from nixvim.
Whatever approach we use, config will be installed to environment.etc.*
on NixOS and xdg.configFile.*
on home-manager. If there's an equivalent for nix-darwin we should consider installing there too.
Anything in the wrapper (such as -u
or exporting variables) would be in addition to that.
So I'm trying to think if there's any downsides to doing this universally, without a wrapRc option 🤔
from nixvim.
Related Issues (20)
- [BUG] Enabling blackd & isortd in none-ls causes problems when saving
- [BUG] derivations cause infinite recursion in `toLuaObject` HOT 4
- [BUG] `Bufferline` `diagnostics_update_in_insert` is deprecated
- [BUG] `error: attribute 'propagatedBuildInputs' missing` in pylsp support HOT 11
- Update which-key keybind spec HOT 8
- [PLUGIN REQUEST] telescope-live-grep-args.nvim
- [BUG] Treesitter syntax highlighting broken for Elixir HOT 1
- [BUG] Can't unset Incremental selection keymaps with `<action_name>=false` HOT 1
- [PLUGIN REQUEST] zellij-nav.nvim
- Cannot find word list "fr.utf-8.spl" or "fr.ascii.spl"
- [BUG] Svelte syntax highlighting broken HOT 2
- Adding plugins gives an error with the module not being found HOT 3
- [PLUGIN REQUEST] nvim-dbee
- Example in README.md: Lightline.vim could not load colorscheme gruvbox. (While running without `sudo`) HOT 9
- Deprecate `helpers.mkRaw` in favour of `lib.generators.mkLuaInline` HOT 5
- [BUG] LSP `volar` requires additional configuration
- [BUG] Hydra as a dependency to multicursors throws warning HOT 1
- [BUG] format: no formatter for path: .editorconfig
- [BUG] Standalone nixvim fails to build when included in package list in cross-compile HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nixvim.