If I'm running an Emacs executable from emacsWithPackages as my main
programming environment, and I'm hacking on Emacs, or the Emacs
packaging in Nixpkgs, or whatever, I don't want the Emacs packages
from the wrapper to show up in the load path of that child Emacs. It
results in differing behaviour depending on whether the child Emacs is
run from Emacs or from, for example, an external terminal emulator,
which is very surprising.
To avoid this, pass another environment variable containing the
wrapper site-lisp path, and use that value to remove the corresponding
entry in EMACSLOADPATH, so it won't be propagated to child Emacsen.
siteVersionDir isn't a full path, it's just the name of the version
directory entry in $out/share/emacs, e.g. "27.1", so since
d1b0eef9b5 ("emacs: Don't use interpolation for version"), we've been
trying to remove a non-existent directory. This would have been
caught if we hadn't been giving -f to rm unnecessarily, because -f
suppresses errors. As well as fixing the path, I've removed the -f
from rm. Doing this to the line above as well revealed that rm-ing
$out/var was no longer necessary, since nothing has been put there
since ac23a7c459 ("emacs: 25.3 → 26.1") -- it would now only be
created if we set the --with-gameuser configure option, which we
don't.
Spacevim is a fully loaded vim/neovim installation in the spirit
of https://www.spacemacs.org/
It's configured with a TOML file rather than vimscript and includes
a wide array of configuration found at https://spacevim.org/
Update pkgs/applications/editors/spacevim/default.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Update pkgs/applications/editors/spacevim/init.nix
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Update pkgs/applications/editors/spacevim/default.nix
Co-authored-by: risson <18313093+rissson@users.noreply.github.com>
When building MacVim with nix-daemon it tries to place the derived data
into a path rooted in `/var/empty`, which fails. Specifying the derived
data path ourselves fixes this problem.
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.
Unfortunately this package doesn't contain the version number in the URL
so it might break easily again, but it is just a matter of updating the
sha256
So, kakoune takes the documentation shown for `:doc` from
`$KAKOUNE_RUNTIME/share/kak/doc`. Unfortunately, it seems
that it will ignore files that are symlinks. This is arguably
a bug in kakoune, we workaround it for now by copying the
content of the docfiles.
The previous implementation of plugin-support for the kakoune derivation
was based on generating, at build time, a `plugins.kak` file that would
source all .kak files in the list of plugins, and wrap the `kak` binary
in a script that would add some command-line arguments so that this
file gets loaded on start-up. The main problem with this approach
is that the plugins' code get executed *after* the user's configuration
file is loaded, so effectively one cannot automatically activate/configure
these plugins.
The idiomatic way of loading plugins is ensuring they end up installed
somwhere under `share/kak/autoload`. Because plugins are already being
packaged to have their code in `share/kak/autoload/plugins/<name-of-plugin>`,
we can obtain a derivation that includes the plugins simply by doing a
`symlinkJoin` of `kakoune-unwrapped` and all the requested plugins.
For this to work, we need to fix two issues:
1. By default, kakoune makes `share/kak/autoload` a symbolic link to
`share/kak/rc`, which contains all builtin definitions. We need
to patch this to put the symlink under `share/kak/autoload/rc`, so that
the join works.
2. By default kakoune expects the `autoload` directory to be in
`../share/kak/autoload` relative to the location of the `kak` binary.
We need to set the `KAKOUNE_RUNTIME` to point the symlinked
share/kak for this to work.
Emacs 27 doesn't use ImageMagick by default to display images [1]:
** Emacs no longer defaults to using ImageMagick to display images.
This is due to security and stability concerns with ImageMagick. To
override the default, use 'configure --with-imagemagick'.
[1] https://github.com/emacs-mirror/emacs/blob/emacs-27.1/etc/NEWS#L96-L98
Use `buildInputs` instead of `propagatedBuildInputs` - should reduce
closure size a bit. Don't wrap executables twice. Move `kdoctools` to
native. Use libsForQt5 - default version (works).
Co-authored-by: Frederik Rietdijk <fridh@fridh.nl>
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.
vim_configurable and neovim have both supported a mechanism to build
them with a custom vimrc that supports plugins from Nix. This updates
MacVim to support the same sort of configuration using an expression
like
macvim.configure {
customRC = ''
# custom configuration goes here
'';
packages.myVimPackage = with pkgs.vimPlugins; {
start = [ youcompleteme fugitive ];
opt = [ phpCompletion elm-vim ];
}
}
Once configured, .override will allow for editing the configuration.
Like vim_configurable and neovim, configuring macvim does not require
rebuilding it. Also like them, configuring macvim turns off the user
vimrc file.
Since we're not using the Nix compiler, our buildInputs aren't
automatically exposed to the compiler, which means it was actually
compiling against system libncurses instead of Nix libncurses.
Also remove the `-Wno-error` from the make flags (and the unnecessary
`PREFIX` definition) in favor of using a much more targeted error
suppression at the configure flags. This works around an issue where
implicit function definitions are considered an error and the configure
script was trying to compile a file tht invoked an ncurses function
without including the relevant header.
The given paths gives rise to errors such as,
```
x86_64-unknown-linux-gnu-gcc-9.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
compilation terminated.
```
in the `*Async-native-compile-log*` buffer.
Fixes <https://github.com/nix-community/emacs-overlay/issues/69>
