See db236e588d "steam: Do $PATH lookup in steam.desktop [...]".
tl;dr: Otherwise widget/panel/desktop icons in DEs like KDE break.
Simply stop adding the full derivation path for neovim and stick with
how upstream uses no path at all.
While here, take care of gnvim.desktop as well by adjusting the sed(1)
expression (and simplifying it in one go); I do not use gnvim.desktop
but built it and confirmed the resulting files to contain no full paths
any longer.
Current nixpkgs always wraps neovim with the "-u" which has sideeffects as explained in https://github.com/NixOS/nixpkgs/issues/55376 :
1. vim won't set the variable $MYVIMRC as explained #34215
2. vim skips loading folder-specific .vimrc / .nvimrc
I wanted to provide a way for users to better control what flags are used to wrap neovim. This is achived by introducing wrapNeovimUnstable et neovimUtils, utilities to help with that. We provide a compatibility layer so that wrapNeovim still works and to let us experiment with wrapNeovimUnstable to better control neovim configuration, plugin dependencies, haskell environment etc so that it becomes easier to generate per-project neovim config.
With this commit, it's possible for instance for home-manager to wrap neovim without the `-u` and just write the config in the
expected $XDG_CONFIG_HOME/nvim/init.vim .
Expect wrapNeovimUnstable interface to evolve in the upcoming months.
first will register the config under the name init.vim which is more
appropriate for neovim.
Pass the generated config to passthru so that one can easily pass the
current config to a
raw/unwrapped neovim (helps with development).
For instance, home-manager can reference the config in $XDG_CONFIG_HOME/nvim/init.vim
without the need to wrap nvim with its config.
Cleanups:
- Removed unneeded neovim.meta.description reset.
- Remove unnecessary -x checks in `postBuild`.
- Use a ${placeholder "out"} if needed.
Changes:
- Switch to symlinkJoin, so e.g manpages link to the environment (#87929).
- Use nvim-node from $out/bin/ just like all other providers.
- Compute all arguments to makeWrapper in pure Nix "before" `postBuild`.
- Prevent double wrapping in case `configure != {}` and rplugin.vim
needs to be generated.
Co-authored-by: Silvan Mosberger <contact@infinisil.com>
When running the default builder for Rust, the artifacts would be stored
in `target/<arch>/<profile>`, however the `install`-target expects the
default structure (`target/<profile>`) of `cargo`-builds.
When using the Makefile for building as well, the expected structure is
created instead.
Changes the default fetcher in the Rust Platform to be the newer
`fetchCargoTarball`, and changes every application using the current default to
instead opt out.
This commit does not change any hashes or cause any rebuilds. Once integrated,
we will start deleting the opt-outs and recomputing hashes.
See #79975 for details.
Idea shamelessly stolen from 4e60b0efae.
I realized that I don't really know anymore where I'm listed as maintainer and what
I'm actually (co)-maintaining which means that I can't proactively take
care of packages I officially maintain.
As I don't have the time, energy and motivation to take care of stuff I
was interested in 1 or 2 years ago (or packaged for someone else in the
past), I decided that I make this explicit by removing myself from several
packages and adding myself in some other stuff I'm now interested in.
I've seen it several times now that people remove themselves from a
package without removing the package if it's unmaintained after that
which is why I figured that it's fine in my case as the affected pkgs
are rather low-prio and were pretty easy to maintain.
There ver very many conflicts, basically all due to
name -> pname+version. Fortunately, almost everything was auto-resolved
by kdiff3, and for now I just fixed up a couple evaluation problems,
as verified by the tarball job. There might be some fallback to these
conflicts, but I believe it should be minimal.
Hydra nixpkgs: ?compare=1538299
Vim Terraform expects the `filetypedetect` group to exist. However, since we were enabling the filetype and the syntax *after* loading the plugins, it was exiting with an error preventing us from generating the remote plugins manifest with the plugin enabled. See #65894 for context.
