Age | Commit message (Collapse) | Author | Files | Lines |
|
- Add Version, URL, Package-Requires sections
|
|
- change flycheck.el to wpc-flycheck.el
- add Version, URL, Package-Requires sections
|
|
- change wpc-ocaml.el to wpc-golang.el
- Add Version, URL, Package-Requires sections
|
|
- Add Version, URL, Package-Requires, Commentary sections
- Prefer `wpc-lisp-` prefix to `wpc/`
|
|
- Add Version, URL, Package-Requires sections
- Prefer `wpc-javascript-` prefix to `wpc/`
|
|
- add Version, URL, Package-Requires sections
- change haskell.el to wpc-haskell.el
- prefer `wpc-haskell-` prefix to `haskell/`
|
|
- prefer user-emacs-directory
- prefer wpc-misc- prefix
|
|
- add "Code:" header
- replace forward-slash with dash
- prefer wpc-nix- prefix to nix/
|
|
- Prefer `user-emacs-directory` to literal path.
|
|
After I wrote zle.el, it seems that I forgot about it. Attempting to revive it
by using it during sh-mode.
|
|
- Prefer dash instead of forward-slash
- Remove stale TODOs
- Add Version, Package-Requires
|
|
CI is reporting a false negative because $@ is empty. This change should cause
elisp-lint to run on all of the Elisp in the wpc/ directory.
|
|
1. I don't use this.
2. This is breaking CI because google-java-format cannot be found.
|
|
While I would like my CI build to closely resemble a non-CI build, supporting
the `all-the-icons-install-fonts` call is a low priority with a medium amount of
work required.
|
|
I'd like to stabilize on using solarized-light.
|
|
This prevents the prompt, which blocks my CI build.
|
|
I don't use neotree anymore.
|
|
For two reasons:
1. I don't use these keybindings.
2. I'm trying to centralize all keybinding logic in keybindings.el.
|
|
Create a top-level flag encoding whether or not Emacs is running in CI.
|
|
After my CI build for Emacs failed because the .local/share/wallpaper directory
was missing I had two options:
A. include .local/share/wallpaper in default.nix, which is cumbersome
B. drop support for managing system wallpaper from Emacs
I chose option B.
|
|
My CI failed after a call to xset resulted in a "file-missing Searching for
program" error.
|
|
I'm starting to prefer the `inherit (builtins) path` pattern in my Nix
expressions. I know this is idiomatic, so even if I don't like it, I am trying
to learn to like it.
|
|
Cleaning things up...
|
|
These were hard-coded as $HOME/BRIEFCASE, which won't work in CI, since CI runs
as the user buildkite-agent-socrates, whose $HOME directory doesn't exist.
|
|
For more information, see here:
https://github.com/buildkite/agent/issues/584
|
|
vterm.el has a bug because it uses `(window-body-height)` to compute the number
of lines it can render, but it doesn't account for `line-spacing`.
|
|
This wasn't a bug; it's just good practice.
|
|
Instead of manually maintaining the list of directories that I expose to
readTree, I'm using `builtins.readDir` to get a list of all non-hidden top-level
directories.
|
|
Remap "l" -> "L"
|
|
TL;DR:
- Define runEmacsScript to emacs/default.nix for ci/pipelines/post-receive
- Write script.el to call (load init.el) and catch any errors
- Lint Elisp with gonewest818/elisp-lint
Also nice how Buildkite supports :gnu: emojis!
|
|
- Prefer prepending wpcDir, vendorDir to EMACSLOADPATH instead of using the
--directory flag
- Remove --load ${wpcPackageEl} because init.el calls (require 'wpc-package)
- Surround $@ in 2x-quotes
|
|
wpcarros-emacs no longer depends on this being set.
|
|
Following the advice of Domen's nix.dev anti-patterns, I'm preferring something
like...
```nix
builtins.path { path = /path/to/some.where; name = "some.where"; }
```
...to
```nix
/path/to/some/where
```
While the former is more verbose, it will fail to build when the path doesn't
exist, which I prefer.
|
|
Trimming more fat.
|
|
Since depot now support cs.tvl.fyi, I don't need this, and that is a *massive*
upgrade.
|
|
I would prefer to define constants/briefcase in terms of `(getenv "BRIEFCASE")`
and assert that `(f-exists? (getenv "BRIEFCASE"))`, in one location:
constants.el
|
|
Feels more natural...
|
|
I'm trying to tidy things up, so I'm trying to apply some of the principles from
"Essentialism" to my Emacs configuration.
|
|
The Nix expression that builds `wpcarros-emacs` sets BRIEFCASE, so the .envrc
isn't relied on.
|
|
TL;DR:
- Prefer `(getenv "BRIEFCASE")` to `(f-expand "~/briefcase")`. I should audit my
Emacs for references to ~/briefcase and replace those calls with `getenv`.
- Remove calls setting <nixpkgs> and <depot> and rely exclusively on <briefcase>
- Prefer ~/nixpkgs-channels to ~/nixpkgs.
Notes:
- I need a better way of calling `home-manager switch` that resides within my
briefcase
|
|
This version avoids installed all of the custom `cl-defmethods` for a
`'monorepo` type and instead uses the existing `'transient`.
|
|
I wanted Gitea to call Buildkite's pre-receive pipeline and either accept or
reject the incoming code depending on the outcome. The problem is that I can
only *create* builds from Gitea's pre-receive hook.
Now I'm left with two options:
1. run the lint-secrets step in post-receive
2. run `/nix/store/<hash>/git-secrets --scan-history $REPO_PATH` in Gitea
As far as I can tell, I cannot define Gitea hooks in Nix, which is unfortunate;
otherwise, option 2 would appeal more.
I'm doing option one for now.
|
|
I think maintaining a 1:1 correspondence with the git server hook makes sense
right now. Let's try it out!
|
|
This way, if the lint step fails, the build step doesn't run. Nice!
|
|
So it turns out that I was wrong and that .git/config is stateful. Multiple
calls to --add-provider will append the same provider each time...
Instead I'm defining secret-patterns.txt and version-controlling it.
Then:
- dev-side: I'm adding `providers = cat ci/secret-patterns.txt` to .git/config
- ci-side: I'm adding `providers = cat ci/secret-patterns.txt` to .git/config
Unfortunately this is ad-hoc configuration ci-side, which I would like to
avoid. The good news is that my pre-commit hooks and failures from git-secrets
should now align with my CI, since they're both reading from
secret-patterns.txt. One step backwards... two steps forwards?
|
|
I'm also `cat .git/config` because I think the Buildkite destroys the
.git/config file for each build, but I want to verify that. If it does, I prefer
that because it seems to share the spirit of the "Destroy Your Darlings" essay.
|
|
I would like to find out what the state of the repo is during pre-receive hook.
|
|
Changed pipelines = new badge.
|
|
Buildkite support language extensions as emojis!
|
|
Y'know... the important stuff
|