mdebray/tvl-depot
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
tvl-depot/emacs/default.nix

159 lines
3.9 KiB
Nix
Raw Normal View History

Remove default values for Nix expression parameters I'm not sure if this commit breaks everything in my monorepo. I think it will. Why am I doing this? Perhaps it's a bad idea. I don't fully understand how readTree works. My ignorance is costing me hours of time spent debugging. In an effort to better understand readTree, I'm removing the default values for my Nix expression parameters, which I believe have preventing errors from surfacing.
2020-02-23 23:29:32 +01:00
{ pkgs, depot, ... }:
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
let
Remove default values for Nix expression parameters I'm not sure if this commit breaks everything in my monorepo. I think it will. Why am I doing this? Perhaps it's a bad idea. I don't fully understand how readTree works. My ignorance is costing me hours of time spent debugging. In an effort to better understand readTree, I'm removing the default values for my Nix expression parameters, which I believe have preventing errors from surfacing.
2020-02-23 23:29:32 +01:00
utils = import <briefcase/utils>;
Add bin dependencies to wpcarros-emacs I removed most of the packages that I install with `nix-env`. You can view these with `nix-env --query`. This is one small step in a grander project to migrate entirely to a declarative config managed by Nix.
2020-02-06 23:23:09 +01:00
# NOTE: I'm trying to keep the list of dependencies herein constrained to a
# list of generic dependencies (i.e. not project or language specific). For
# language-specific tooling, I'm intending to use shell.nix alongside lorri
# and direnv.
Remove assertions that prelude/executable-exists? I'm in the midst of transitioning onto a few new tools. My previous workflow just used `nix-env` to install *some* packages. I didn't have a prescribed methodology for which packages I would install using `nix-env` and which ones I would install using `sudo apt-get install`. Sometimes if a package would be available in my aptitude repositories, I'd use that; other times when it wasn't available I'd use `nix-env`. One complication about being on gLinux intead of NixOS is that some packages (e.g. nixpkgs.terminator) is available via `nix-env -iA nixpkgs.terminator`, but the installation won't actually run on my gLinux. In these instances, I would install terminator from the aptitude repositories. Then @tazjin introduced me to his Emacs configuration that he builds using Nix. What appealed to me about his built Emacs is that it worked as expected on either a NixOS machine and on gLinux (and presumably on other non-NixOS machines as well). A setup towards which I'm working is to own one or a few NixOS machines whose configurations are entirely managed with Nix. On devices like my work machines, which cannot run NixOS, I can build as much of the software that I need using Nix and attempt to minimize the ad hoc configuration either with shell scripts, python, golang, or more Nix code... it's clear that I still don't have a clear idea of how that part will work. For now, I'm adopting nix, nix-env, lorri, direnv, and weening off of aptitude as much as I can. Things are a bit messy, but my general trend feels positive. Stay tuned for more updates.
2020-02-06 22:44:26 +01:00
emacsBinPath = pkgs.lib.strings.makeBinPath (with pkgs; [
Add bin dependencies to wpcarros-emacs I removed most of the packages that I install with `nix-env`. You can view these with `nix-env --query`. This is one small step in a grander project to migrate entirely to a declarative config managed by Nix.
2020-02-06 23:23:09 +01:00
tdesktop # native telegram client
ripgrep
gitAndTools.hub
kubectl
google-cloud-sdk
xsv
Remove assertions that prelude/executable-exists? I'm in the midst of transitioning onto a few new tools. My previous workflow just used `nix-env` to install *some* packages. I didn't have a prescribed methodology for which packages I would install using `nix-env` and which ones I would install using `sudo apt-get install`. Sometimes if a package would be available in my aptitude repositories, I'd use that; other times when it wasn't available I'd use `nix-env`. One complication about being on gLinux intead of NixOS is that some packages (e.g. nixpkgs.terminator) is available via `nix-env -iA nixpkgs.terminator`, but the installation won't actually run on my gLinux. In these instances, I would install terminator from the aptitude repositories. Then @tazjin introduced me to his Emacs configuration that he builds using Nix. What appealed to me about his built Emacs is that it worked as expected on either a NixOS machine and on gLinux (and presumably on other non-NixOS machines as well). A setup towards which I'm working is to own one or a few NixOS machines whose configurations are entirely managed with Nix. On devices like my work machines, which cannot run NixOS, I can build as much of the software that I need using Nix and attempt to minimize the ad hoc configuration either with shell scripts, python, golang, or more Nix code... it's clear that I still don't have a clear idea of how that part will work. For now, I'm adopting nix, nix-env, lorri, direnv, and weening off of aptitude as much as I can. Things are a bit messy, but my general trend feels positive. Stay tuned for more updates.
2020-02-06 22:44:26 +01:00
scrot
clipmenu
]);
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
emacsWithPackages = (pkgs.emacsPackagesNgGen pkgs.emacs26).emacsWithPackages;
wpcarrosEmacs = emacsWithPackages (epkgs:
(with epkgs.elpaPackages; [
exwm
]) ++
(with epkgs.melpaPackages; [
Add ts.el to emacs/default.nix I ran `M-x package-autoremove` that deleted `ts.el`, which wasn't listed in my default.nix. Adding it...
2020-02-10 12:34:19 +01:00
ts
Support vterm-mgt.el I enjoyed using term-switcher so much that I ended up adopting vterm as my primary terminal. After reaching for vterm as often as I did, I realized that I would enjoy supporting cycling through instances, creating new instances, deleting existing instances, renaming instances. Thus spawned vterm-mgt.el. I'm particularly excited about the KBD to toggle between vterm instances and source code buffers.
2020-02-08 17:00:31 +01:00
vterm
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
base16-theme
ivy-pass
clipmon # TODO: Prefer an Emacs client for clipmenud.
protobuf-mode # TODO: Determine if this is coming from google-emacs.
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
# docker
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
evil
evil-collection
evil-magit
evil-commentary
evil-surround
key-chord
add-node-modules-path # TODO: Assess whether or not I need this with Nix.
web-mode
rjsx-mode
tide
prettier-js
flycheck
diminish
doom-themes
Use doom-modeline Cleaning up my modeline by using the beautiful doom-modeline package.
2020-02-27 12:42:45 +01:00
doom-modeline
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
neotree # TODO: Remove this dependency from my config.
which-key
ivy
Support building wpcarros-emacs I'm using a Makefile until I can remember the command: ```shell > nix-env -f . -i ``` This will install (i.e. `-i`) any derivations instantiated from the Nix expression resolvable by `-f`. Ideally the incantation will look something like this: ```shell > nix-env -f '<universe>' -iA emacs ``` Informing `nix-env` to install all of the derivations created by the expression at attribute `emacs` in my `<universe>` repository. For now two things are preventing this: 1. `emacs` isn't an attribute in my top-level expression defined in the `default.nix`. 2. If I do add `emacs` as an attribute and call the above command, my usage of `readTree` results in `pkgs` missing `.lib` and a few other stdlib commands that are available in `(import <nixpkgs> {})`. A fix for both of these should be forthcoming.
2020-01-31 13:45:48 +01:00
restclient
package-lint
parsec
magit-popup
direnv
emr
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
ivy-prescient
all-the-icons
all-the-icons-ivy
alert
nix-mode
racer
rust-mode
rainbow-delimiters
racket-mode
lispyville
elisp-slime-nav
py-yapf
reason-mode
elixir-mode
Further configure Go tooling - Prefer goimports to gofmt. goimports calls gofmt; it also adds and removes dependencies. - Assert the presence of goimports, godoc, godef - KBD godef to M-. - Support the M-x compile command for calling `go build -v`
2020-02-05 18:55:38 +01:00
go-mode
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
company
markdown-mode
refine
deferred
magit
request
pcre2el
helpful
exec-path-from-shell # TODO: Determine if Nix solves this problem.
yasnippet
projectile
deadgrep
counsel
counsel-projectile
engine-mode # TODO: Learn what this is.
eglot
dap-mode
lsp-ui
company-lsp
suggest
paradox
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
# emr
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
flymake-shellcheck
fish-mode
tuareg
haskell-mode
lsp-haskell
use-package
general
clojure-mode
cider
f
dash
company
counsel
flycheck
ivy
magit
]) ++
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
(with depot.tools.emacs-pkgs; [
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
dottime
]));
# TODO: Do I need `pkgs.lib.fix`?
in pkgs.lib.fix(self: l: f: pkgs.writeShellScriptBin "wpcarros-emacs" ''
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
# TODO: Is this the best way to handle environment variables using Nix?
export BRIEFCASE=$HOME/briefcase
export DEPOT=$HOME/depot
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
export PATH="${emacsBinPath}:$PATH"
exec ${wpcarrosEmacs}/bin/emacs \
--debug-init \
--no-site-file \
--no-site-lisp \
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
--directory ${ ./.emacs.d/vendor } \
--directory ${ ./.emacs.d/wpc } \
--load ${ ./.emacs.d/wpc/wpc-package.el } \
--load ${ ./.emacs.d/init.el } \
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
--no-init-file $@
'' // {
# TODO: Ascertain whether I need this.
overrideEmacs = f': self l f';
# Call with a local.el file containing local system configuration.
withLocalConfig = confDir: self confDir f;
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
# This accepts the path to an Emacs binary outside of /nix/store. On gLinux,
# this will ensure that X and GL linkage behaves as expected.
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
withLocalEmacs = emacsBin: pkgs.writeShellScriptBin "wpcarros-emacs" ''
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
# TODO: Is this the best way to handle environment variables using Nix?
export BRIEFCASE=$HOME/briefcase
export DEPOT=$HOME/depot
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
export PATH="${emacsBinPath}:$PATH"
export EMACSLOADPATH="${wpcarrosEmacs.deps}/share/emacs/site-lisp:"
exec ${emacsBin} \
--debug-init \
--no-site-file \
--no-site-lisp \
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
--directory ${ ./.emacs.d/vendor } \
--directory ${ ./.emacs.d/wpc } \
--load ${ ./.emacs.d/wpc/wpc-package.el } \
--load ${ ./.emacs.d/init.el } \
WIP: Nixify Emacs setup The things that I dislike about this setup are: 1. `xref-find-definitions` takes me to `/nix/store`, which is a read-only version of the source code, so I cannot edit it, which doesn't feel lispy. 2. I need to rebuild the derivation when I change something, which also doesn't feel lispy. There are ways to circumvent both of these drawbacks, but for now, I'm checking this in only to later revert it.
2020-01-06 15:58:22 +01:00
--no-init-file $@
'';
Move move .emacs.d out of configs/shared Moving all of my Emacs-related files into their own directory at the root of this repository.
2020-01-30 17:00:29 +01:00
}) null utils.identity
Reference in a new issue Copy permalink